Chemistry, not Culture: Casting Your Engineering Team

I often use the word “casting” when talking about how I build an engineering team. Like stage and screen, you want to hire people who are going to come together and create something that none of them can do alone. What you really want to assemble is that fabled chemistry that you see in classic entertainment. It doesn’t happen accidentally though. You have to deliberately put people into roles where they will bring out the best in each other. After the last act, you want to see your cast hand in hand taking a group bow as an ensemble.

Six Things I Look For

• Lifelong learner. What this means to me is that the candidate is continually learning increasingly complicated things…for fun. Watch out for people who are only learning things related to their job, or worse, only learning while on the job. I once hired a lad to do Ruby development on an internal business application. Outside of work, he was teaching himself audio processing and WebGL visualizations. Neither had any direct relevance to his job, but he had an innate desire to learn anyway, and it rounded him out well.
• Critical thinkers. You want somebody that questions everything — somebody that believes that anything can be improved upon. These types walk into a company and immediately identify inefficiencies and problem areas. Seek these people out! You never want to hire somebody that will simply embrace the status quo which would only further exacerbate all of your problems.
• Opposite-side brain affinity. If you’re hiring engineers, look for people that also have a creative outlet. In my experience, engineers that are also photographers, musicians or any other expressive outlet make well rounded teammates. They see aesthetic value in what they do because they genuinely want to live in a beautiful world. Stay clear of robotic engineers with no other interests. They will forever confound you because they can’t see all the facets of your decisions. Eventually you’ll have to ask an engineer to make compromises in their work in order to meet a critical business deadline. When that happens, you want them to be accepting of the reality of business. Similarly, I’ve found that the best artists are the ones that have a strong left brain. This is especially important when expecting an artist/designer to be able to translate their work into CSS, use version control systems, and do in-browser debugging.
• Loyalty. Most people these days have little to no equity in a company, so what exactly do you want people to be loyal to? You want them to be loyal to each other. In his book “Free Agent Nation: The Future of Working for Yourself” Daniel Pink points out that people aren’t loyal to a company — they are loyal to “clients, colleagues, ex-colleagues, teams, professions, projects and industries.” Don’t have unrealistic expectations about candidates that trigger a loyalty warning in your head. It’s not the problem that you think it is.
• Trust. When I hire systems engineers I always come back to the very real question of, “can I trust them with root access?” A person with root access at your company can see everything. They can read your email, they have access to all of your files, your bookmarks and browsing history, they can eavesdrop on your instant messages, they can wipe your phone remotely. In the SMB space, this is a big deal because there usually isn’t a budget for several technical layers of information security. Given this risk, does the candidate have discretion? Do you trust that they won’t go snooping around? Do you trust their judgement, as much as is possible after just meeting them? Root access can bring out the worst in people — you have to trust them.
• Differences. These come in many forms, starting with basic communication style. If you’re not careful you’ll end up with a room full of loud extroverts. In her book “Quiet: The Power of Introverts in a World That Can’t Stop Talking” Susan Cain wrote, “We have two ears and one mouth and we should use them proportionally.” Try to find an equal distribution of extroverts and introverts to balance out the conversations of your team. After this comes the ability to say no. I love casting a nay-sayer on a team because they act as the realist in a group of chronic optimists. Many people think that saying no makes a person a negative influence and not a team player. But in my experience, they have been the best brake pedal ever invented for my engineering teams. They give pause to over-ambitious goals and they almost always come up with more simple and elegant engineering solutions. You need them in your cast of characters.

Two Big Things that I Stay Away From

• “Cultural Fit.” If you’re hung up on this one, you’re probably paying too much attention to trying to invent a company culture. But culture is an emergent property, not dogma. Think of it this way: you could never force everyone to like the same kind of music, so why would you try to force your own flavor of utopia on people? When you have a good mix of people, it will come out on it’s own and it will be so authentic that you’ll never be able to figure out how you did it.
• Myself. Never try to hire somebody that “reminds you of yourself.” I’ve made this mistake more than once and what I ended up with were employees that acted too much like me. They reinforced my bad habits, and generally brought out the worst in me. Instead, I try to find people that have different ideas and attitudes than I have that can bring out the best in me as their leader. Nobody likes the guy that is an amplified microphone of the manager.

Hiring is an imperfect science for people, and you get better at it with experience — nobody is good at it right out of the gate. I’ve made some huge hiring errors in the past, and undoubtably I’ve also missed out on hiring some great people. Put some thought into your process, trust your instincts, and be honest enough with yourself to change it when things don’t go the way you thought they would. In the event, don’t ever tell yourself that it’s not personal, because it always is. Get ok with that.

Special thanks to Charles Kirk (archr.io), Jon Nelson (archr.io), Matt Hoffman (re-factor.co), Matt Kornatz, and Max Ellinger for their advance feedback on this piece. It’s much better as a result of their help.