{"id":14244,"date":"2018-02-01T15:08:29","date_gmt":"2018-02-01T15:08:29","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=14244"},"modified":"2020-08-12T18:05:58","modified_gmt":"2020-08-12T17:05:58","slug":"joel-califa-makes-design-leadership-work","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/joel-califa-makes-design-leadership-work\/","title":{"rendered":"Joel Califa On What Makes Design Leadership Work"},"content":{"rendered":"

At Marvel, we love speaking to designers from across the world, working at leading companies and driving the future of design. We caught up with Joel Califa<\/a>, Senior Product Designer at GitHub, and discussed how his career took shape, got some advice on how to lead design teams and picked his brain on where he thinks the future of design is going. <\/em><\/p>\n

Tell me a little bit about your current role and the work that you're doing right now...<\/h2>\n

I\u2019m currently a Senior Product Designer at GitHub and I love it. The people I get to work with are all super smart, talented, and humble, and getting to work on a product that\u2019s so crucial to our industry (and used regularly by 20 million developers) is so much more satisfying than I expected it to be.<\/p>\n

My product team is called CODE, which basically means we are responsible for most things related to code on GitHub: pull requests, code review, etc. My role includes a bit of everything. In my 6 months here I\u2019ve done high-level product strategy, detail work on interfaces, redesigned flows, implemented things in code, conducted large research projects, etc. Product Design as a field has fuzzy borders to begin with. I think as you get more experienced, they only become fuzzier. I kind of like that\u2014it lets me work at various fidelities and scopes, so I get to never be bored.<\/p>\n

<\/div>
<\/svg><\/div>

\"Product Design as a field has fuzzy borders to begin with. I think as you get more experienced, they only become fuzzier.\"<\/p><\/span><\/blockquote>\n

In your role right now, what would you say are the most challenging aspects of what you're doing?<\/h2>\n

Since GitHub is so ubiquitous, we see such a range of different workflows and states. There are many ways to structure code repositories. There are many approaches to reviewing code. Many ways to manage projects. Many methods individual developers use to stay productive. Many different local development environments. Many different styles and languages. The list goes on and on, and there\u2019s always more. Each of these is a new, and often highly technical thing to learn, and when we design new feature and products, we have to account for all of it.<\/p>\n

On top of that, a developer is often the definition of a power user\u2014which means they\u2019ve learned your product inside and out, they\u2019ve found ways to become more efficient at using it, and they absolutely hate when you change it. Navigating the cost of improvement is also super interesting.<\/p>\n

Why did you choose design as a career? What was the path to becoming a product design leader?<\/h2>\n

I was extremely lucky in that I kind of fell into design and development. I was a nerd as a kid, and all my friends were nerds, so we picked up QBasic, Visual Basic, and C++ early on. It was fun and empowering in a way similar to Lego. You get to think creatively and actually materialize your vision, and that was exciting. When I was 13 or so, I learned Corel Draw and Photoshop to make Counter Strike posters and Star Wars art. I picked up HTML to make Neopets sites.<\/p>\n

All of this kind of snowballed into freelance work designing album covers and building websites. When I was 15 or so I was hired to design an intranet for a tech company. By the time I was in a position to decide what to do with my future, I already had something I was passionate about and decent at. It was a no-brainer. See? Lucky. This skillset that I acquired accidentally because it was fun ended up positioning me for roles like the ones at Amicus, DigitalOcean, and now at GitHub.<\/p>\n

\"The path to leadership wasn\u2019t really intentional either. We didn\u2019t have a good design hiring process at DigitalOcean<\/a>, so I talked to design leaders and built one. We didn\u2019t have a design system, so I built one. We didn\u2019t have formal design principles, so I articulated them. Sooner or later I realized that someone needed to be doing this type of work full-time, and that it could be me. I was lucky to come in so early and get the opportunity to grow in that way. All the industry leadership stuff (the writing and speaking) is just me wanting to share that experience with the community.\"<\/span><\/p>\n

You worked for DigitalOcean in their early days, how did your role change as they grew?<\/h2>\n

When I started at DO, we were 60 people with one product, a virtual private server called a Droplet. When I left, we were 300 and had a much wider array of products\u2014from security to storage\u2014with more on the way. They say that every time a company doubles in size it needs to relearn how to communicate, because it\u2019s essentially an entirely new company. I saw shifts like this a few times throughout my tenure.<\/p>\n

<\/div>
<\/svg><\/div>

\"They say that every time a company doubles in size it needs to relearn how to communicate.\"<\/p><\/span><\/blockquote>\n

For those who\u2019ve never heard about it, DigitalOcean is a cloud platform for developers. It\u2019s known primarily for its intuitive workflows and interfaces in relation to other tools on the market. From the get go, a big part of my role was nurturing this and building on it. That\u2019s easier to do with one product than it is with ten. As we built out more of this functionality, I transitioned to leadership and built out a team capable of maintaining the product\u2019s clarity as it grew in scale and complexity.<\/p>\n

What that meant was that I stopped opening Sketch and Atom and switched focus to hiring great people and making sure they were empowered to do great work. Most of my work started getting done in meetings. Hiring is hard, keeping people engaged is hard, steering a team and keeping an entire company aligned around design is very hard.<\/p>\n

\"These were different challenges than the ones I tackled as an individual contributor, but I loved them. Seeing a designer grow as a leader and knowing that you made that happen is one of the most rewarding things I\u2019ve experienced.\"<\/span><\/p>\n

How I measured success also changed. Managers don\u2019t have as many obvious \u201cwins\u201d because they don\u2019t usually ship things. Instead it became about my team\u2019s general health, productivity, quality, ambition, etc. The work in a role like this is less hands on, but it has the potential to be so much more impactful.<\/p>\n

Are there any common takeaways you've experienced from leading different design teams that apply to all of them?<\/h2>\n

I think the most important thing you can do is to hire good people and help them to do good work in whichever ways you can. This means creating and nurturing an environment within which they can flourish. I\u2019ve written a bit about this in the past<\/a>.<\/p>\n

The specific processes that work for one team might not work for another, but I think that, regardless of implementation, there are certain things that every Product Design org needs. Every team needs a way to stay aligned on a larger vision and consistent in their output (often roadmaps, design systems, design principles), a way to stay ambitious and keep the bar high (regular critique sessions, collaboration sessions), a way to conduct research and make sure the product is serving its users (an interview pipeline and process, a way to document findings), a way to build trust within their company (communication methods, update channels), a way to stay productive and accountable (planning meetings, retros), and so forth.<\/p>\n

These things aren\u2019t necessarily different than what an Engineering or Product Management team might need, but the right balance of processes with these goals in mind can help any team ship great products regularly.<\/p>\n

Do you have any advice or guidelines for providing feedback to designers?<\/h2>\n

The first thing you want to do on your team is to build a culture of critique and trust, so designers learn to give candid feedback regularly, and not to take things personally. Hiring people who make it about the work and not about themselves is also key here, and you can get at that with the right behavioral interview questions.<\/p>\n

At DigitalOcean, our design reviews started with the presenter giving the other designers enough context for their feedback to be relevant and valuable. Then they specify what type of feedback was most useful at that point. Early in the process, they usually want feedback about product direction and strategy, and how it fits into the big picture. Later they might prefer feedback about information architecture and flows. Then specific interfaces, and finally aesthetics.<\/p>\n

Giving feedback out of sync isn\u2019t usually practical. It\u2019s counter-productive to nitpick a button size when you\u2019re discussing wireframes, as it is to go back and finally criticize product strategy when you\u2019re only weeks away from shipping.<\/p>\n

The other thing the makes feedback effective its constructiveness and specificity. Good feedback can be positive or negative, but it\u2019s always actionable. I find the card suit framework cute and useful to separate different kinds of feedback:<\/p>\n

\u2663\ufe0f Club: \u201cThis is bad.\u201d This is blunt negative feedback. You aren\u2019t given any insight into how you could improve. This kind of feedback only serves to demoralize.
\n\u2665\ufe0f Heart: \u201cThis is good.\u201d This is blunt positive feedback. You aren\u2019t given any insight into what about the thing you did was good, so you can\u2019t learn from it. You feel good, but on the whole it\u2019s not super useful.<\/p>\n

\u2660\ufe0f Spade: \u201cThis isn\u2019t great because\u2026\u201d \u201cThis could be better if\u2026\u201d This is sharp negative feedback. It explains why something isn\u2019t great and how it could be better. This makes it actionable. Note that this doesn\u2019t mean you\u2019re \u201csolutioning\u201d for the presenter (which is almost always counter-productive in reviews)\u2014you could be giving them potential areas to explore.
\n\u2666\ufe0f Diamond: \u201cThis is awesome because\u2026\u201d This is sharp positive feedback. It lets you feel good while learning what to keep or continue doing.<\/p>\n

You don\u2019t want clubs and hearts. You do want diamonds and spades. Good feedback is relevant, timely, constructive, and specific.<\/p>\n

When it comes to hiring new design talent, what do you look for?<\/h2>\n

This depends entirely on the role I\u2019m hiring for. So far, the kind of roles I\u2019ve looked to fill have been similar: generalist Product Designers at developer tool companies. Honestly, I worry sometimes that I\u2019m typecasting myself.<\/p>\n

The generalist aspect was always more important to me than the \u201cdeveloper tools\u201d part. This might be counter-intuitive, but coding experience wasn\u2019t very high up on my list. Having context for developer workflows was a leg up for sure, but it was never a requirement. I mean, I wouldn\u2019t exclusively hire doctor\/designer hybrids for a med-tech startup or accountant\/designer hybrids to work on tax software, right? Prior context helps, but you can build that.<\/p>\n

I actually think the skillsets between these areas are really similar. It\u2019s the curiosity to dive deep into an industry and learn it quickly, the ability to intuit complex (and often technical) systems, and the instinct for how to simplify them. This is the meat of our work on professional workflows, and it\u2019s far and beyond the most important skill for a designer in this space to have. So systems thinking and the ability to learn is #1 on my list of skills.<\/p>\n

Then it\u2019s their ability to effect change within an organization. What successes have they had in the past? How do they deal with crisis? How do they rally people around an idea? Startups can get messy. Designers often wear a ton of hats, and I want to know that they\u2019ll wear these effectively.<\/p>\n

After these, I look at their \u201chard\u201d skills in this order of importance:<\/p>\n

    \n
  1. Are they good at putting together intuitive user flows and interfaces? Do they back their decisions up with good reasons?<\/li>\n
  2. Are they experienced at user research? Can they validate their designs?<\/li>\n
  3. Do they have an eye for typography and space? Can they make things look nice and professional? Can they consistently apply a design system without help?<\/li>\n
  4. Can they code? HTML\/CSS first and then JS or an understanding of frameworks. These help when you need to jump into the codebase to fix a visual bug or help your engineers polish a design. Things can go much faster when a designer is semi-competent at this stuff. It\u2019s optional, but becomes way more important when you don\u2019t have access to engineering resources.<\/li>\n<\/ol>\n

    \"Those are the skills, but more important is hiring someone who is humble, kind, and shares your team\u2019s values. This explicitly does not mean someone you want to hang out with after work, but it\u2019s someone who will mesh with your team in productive and healthy ways.\"<\/span><\/p>\n

    I\u2019ve been lucky to manage teams at a scale where we could make a unanimous decision\u2014if anyone says \u201cno\u201d and can\u2019t be convinced otherwise, it\u2019s always been a no, even if many others were interested. I\u2019ve never overridden one of my designers, and we built a team I\u2019m still extremely proud of.<\/p>\n

    Product design seems to have made leaps and bounds in the past 2-3 years with tools, processes, knowledge-sharing and communities maturing - where does it go next?<\/h2>\n

    I definitely feel that we\u2019re in somewhat of a golden age for design and prototyping tools. I think we\u2019ve come a long way, and it\u2019s amazing to see so many players and such a range of ideas in the space. That said, I think there\u2019s still a ton of room for innovation, and probably a long way to go until designer workflows feel right. I recently spoke at a conference with Josh Brewer, one of Abstract\u2019s founders. His talk<\/a> discussed how young and fragmented design tools still were. I think the next step is figuring out how all of these various tools fit together into a cohesive, efficient, and natural workflow. It sounds like a super interesting challenge.<\/p>\n

    \"These tools and practices are also going to change the kinds of skillsets that designers need. I\u2019m guessing that with the rise of straightforward design systems, visual design won\u2019t be as essential for Product Designers to master, and might shift over to design systems folks. It could also mean that coding will be less important, since engineers will be able to easily implement designs to a tee. Or, it could mean that the responsibility of implementing designs will fall more formally on designers\u2019 shoulders. It\u2019s hard to say what the effects will be, but our industry is always changing, and I only see that accelerating.\"<\/span><\/p>\n

    I also agree that there\u2019s more internal dialogue in the community than ever. As much as we like to make fun of it, Medium and Twitter are probably the biggest catalysts for this. One result of this is a lot more noise (and a ton of useless hot takes), but overall I think it\u2019s been useful for our industry to introspect and grow. Something I\u2019ve enjoyed recently is seeing this dialogue mature from \u201chere\u2019s why you should do user research\u201d to \u201cwhat are we doing, and should we?\u201d<\/p>\n

    <\/div>
    <\/svg><\/div>

    \"I think the most important questions we have to ask ourselves aren\u2019t the ones that relate to bettering our craft, but rather the ones that better our industry.\"<\/p><\/span><\/blockquote>\n

    I think the most important questions we have to ask ourselves aren\u2019t the ones that relate to bettering our craft, but rather the ones that better our industry<\/a>. I\u2019ve been seeing more and more designers grappling with this and showing a willingness to grow, and I genuinely believe we have so much potential to do better.<\/p>\n

    What it means to be a designer has changed so much since I got started. There\u2019s no doubt in my mind that it\u2019s going to change so much more, and I\u2019m very excited to see where it goes.<\/p>\n","protected":false},"excerpt":{"rendered":"

    At Marvel, we love speaking to designers from across the world, working at leading companies and driving the future of design. We caught up with Joel Califa, Senior Product Designer at GitHub, and discussed how his career took shape, got some advice on how to lead design teams and picked his brain on where he thinks the future of design… Read More ￫<\/a><\/p>\n","protected":false},"author":12,"featured_media":14251,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[362],"tags":[480],"class_list":["post-14244","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-spilling-tea","tag-designers-spilling-tea"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n