Lesson: Designing Your Experience with Jeff Veen

Step #4 Hiring: Learning to evaluate candidates and team fit

Maybe it's worthwhile to hear that I find hiring enormously stressful and one of the hardest things to do in the growth of the business. Probably because it's one of the most important things. There are a lot of important things but finding the right people and convincing them.

Maybe convincing them is not as hard because one of the ways to be successful is to have a very clear and well-held vision. When people are interviewing and they hear the same passion for that vision from person after person, it's infectious, but finding people has always been difficult. It feels more difficult now. It feels like there's just not enough people to make all the stuff that we want to make and I hear that from all kinds of entrepreneurs as well.

You can do all of the tests and code. Do an integer sort on the whiteboard for me. That kind of stuff that you want and that's good. You need a baseline, but to be honest, we mostly just say, "Can you show us your GitHub repository?” and that's your resume now. That seems to be a good criteria for hiring, or a design portfolio. I want to hear about how people solve problems and that's the only thing that I focus on. I let other people on the team really evaluate. Are they going to pull their weight?

I want to know what their role was and how they approached the problem and what didn't work. It's probably pretty standard interviewing techniques and I spend time. I can't sit down with someone for 45 minutes. I got to go for a walk. I got to spend some time and just say, "You're going to be here all the time. We're going to work together a lot and I got to trust you. So let's start that now."

One of the most important things that I tried to cultivate was this culture of the team. And that is that trust and that sense of taste that they shared together, and camaraderie and things like that. There's a danger in that, in that it's very easy to just hire the same kind of person over and over again, and it gets this really homogeneous team that has no sense of diversity. And that I consider probably one of the mistakes. I mean, it was very successful what we've done with Typekit. But that was where I erred on the conservative side, always hiring for the kind of design-thinking person that had contemporary web standards or type of coding style and all those kind of things.

It wasn't till we got the team to Adobe where we had the opportunity to really grow but it was generally by merging other teams in. So a lot of Adobe's investment has shifted from older products into new products, but they're still very talented developers and so we bring them over. We brought, for example, a group of people from the Flash Runtime team into Typekit. These are people that hadn't actually even made web services before, but they were very good and very highly functioning team. We just merged it together, and I was like, "Oh my gosh, look at the benefits here, exponential benefits of doing that." Whereas I don't think I would've hired them, which would've been a real letdown, because look at all that's happened.

And now we've done the same thing. We actually have Adobe type designers from the Adobe Type team and we have all these different desktop client software teams and things like that that are coming in. And it's getting better because we have this much more diverse set of backgrounds coming together and we can still teach them the culture and the taste. I'm not sure you can really teach good taste, but you can certainly set a pretty high bar and people will understand that. And they don't all stay, which is also fine. Sometimes it's just really not a good fit, and that's fine, too. So long as we're quick and crisp with how we decide that collectively.