Joel Califa On What Makes Design Leadership Work

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 is going.

Tell me a little bit about your current role and the work that you're doing right now...

I’m 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’s so crucial to our industry (and used regularly by 20 million developers) is so much more satisfying than I expected it to be.

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’ve 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—it lets me work at various fidelities and scopes, so I get to never be bored.

"Product Design as a field has fuzzy borders to begin with. I think as you get more experienced, they only become fuzzier."

In your role right now, what would you say are the most challenging aspects of what you're doing?

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’s 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.

On top of that, a developer is often the definition of a power user—which means they’ve learned your product inside and out, they’ve 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.

Why did you choose design as a career? What was the path to becoming a product design leader?

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.

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.

"The path to leadership wasn’t really intentional either. We didn’t have a good design hiring process at DigitalOcean, so I talked to design leaders and built one. We didn’t have a design system, so I built one. We didn’t 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."

You worked for DigitalOcean in their early days, how did your role change as they grew?

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—from security to storage—with more on the way. They say that every time a company doubles in size it needs to relearn how to communicate, because it’s essentially an entirely new company. I saw shifts like this a few times throughout my tenure.

"They say that every time a company doubles in size it needs to relearn how to communicate."

For those who’ve never heard about it, DigitalOcean is a cloud platform for developers. It’s 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’s 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’s clarity as it grew in scale and complexity.

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.

"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’ve experienced."

How I measured success also changed. Managers don’t have as many obvious “wins” because they don’t usually ship things. Instead it became about my team’s 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.

Are there any common takeaways you've experienced from leading different design teams that apply to all of them?

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’ve written a bit about this in the past.

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.

These things aren’t 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.

Do you have any advice or guidelines for providing feedback to designers?

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.

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.

Giving feedback out of sync isn’t usually practical. It’s counter-productive to nitpick a button size when you’re discussing wireframes, as it is to go back and finally criticize product strategy when you’re only weeks away from shipping.

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

♣️ Club: “This is bad.” This is blunt negative feedback. You aren’t given any insight into how you could improve. This kind of feedback only serves to demoralize.
♥️ Heart: “This is good.” This is blunt positive feedback. You aren’t given any insight into what about the thing you did was good, so you can’t learn from it. You feel good, but on the whole it’s not super useful.

♠️ Spade: “This isn’t great because…” “This could be better if…” This is sharp negative feedback. It explains why something isn’t great and how it could be better. This makes it actionable. Note that this doesn’t mean you’re “solutioning” for the presenter (which is almost always counter-productive in reviews)—you could be giving them potential areas to explore.
♦️ Diamond: “This is awesome because…” This is sharp positive feedback. It lets you feel good while learning what to keep or continue doing.

You don’t want clubs and hearts. You do want diamonds and spades. Good feedback is relevant, timely, constructive, and specific.

When it comes to hiring new design talent, what do you look for?

This depends entirely on the role I’m hiring for. So far, the kind of roles I’ve looked to fill have been similar: generalist Product Designers at developer tool companies. Honestly, I worry sometimes that I’m typecasting myself.

The generalist aspect was always more important to me than the “developer tools” part. This might be counter-intuitive, but coding experience wasn’t 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’t 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.

I actually think the skillsets between these areas are really similar. It’s 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’s 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.

Then it’s 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’ll wear these effectively.

After these, I look at their “hard” skills in this order of importance:

1. Are they good at putting together intuitive user flows and interfaces? Do they back their decisions up with good reasons?
2. Are they experienced at user research? Can they validate their designs?
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?
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’s optional, but becomes way more important when you don’t have access to engineering resources.

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

I’ve been lucky to manage teams at a scale where we could make a unanimous decision—if anyone says “no” and can’t be convinced otherwise, it’s always been a no, even if many others were interested. I’ve never overridden one of my designers, and we built a team I’m still extremely proud of.

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?

I definitely feel that we’re in somewhat of a golden age for design and prototyping tools. I think we’ve come a long way, and it’s amazing to see so many players and such a range of ideas in the space. That said, I think there’s 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’s founders. His talk 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.

"These tools and practices are also going to change the kinds of skillsets that designers need. I’m guessing that with the rise of straightforward design systems, visual design won’t 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’ shoulders. It’s hard to say what the effects will be, but our industry is always changing, and I only see that accelerating."

I also agree that there’s 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’s been useful for our industry to introspect and grow. Something I’ve enjoyed recently is seeing this dialogue mature from “here’s why you should do user research” to “what are we doing, and should we?”

"I think the most important questions we have to ask ourselves aren’t the ones that relate to bettering our craft, but rather the ones that better our industry."

I think the most important questions we have to ask ourselves aren’t the ones that relate to bettering our craft, but rather the ones that better our industry. I’ve 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.

What it means to be a designer has changed so much since I got started. There’s no doubt in my mind that it’s going to change so much more, and I’m very excited to see where it goes.