Searching for… The next Steve Wozniak
Over the past three years, I’ve had the honor of scaling out our Engineering team here at Komodo Health where we’ve been able to build a dynamic 50+ person team on the fundamental ABC’s of great Engineering: Autonomy, Boldness, and Collaboration.
One question that I get pretty often these days, often from non-technical co-founders, is: “How do I get an Engineering team off the ground?” Not surprisingly, there’s no easy solution to that problem as the question itself often devolves into the title of this post.
The good news: once you acknowledge that, you find out (at least from my observations) that hiring your initial technical teams is not all that different from the challenges founders face in other aspects of their business.
(a) There is a difference between hiring a CTO, Head of Engineering / VP of Engineering, Engineering Manager, and Engineer #1.
Observation: The instinct for a lot of non-technical founders is to focus on hiring a CTO / VPE first and then have that person scale out their technical teams and help them build their products.
Commentary: It seems like a lot of this is born out of an insecurity that the founders themselves will not be able to source / select / manage engineers and/or make the correct technical decisions about how to build out their initial offering(s).
Not only is this insecurity irrational, it’s also self defeating.
Honestly, if you can quickly hire a CTO / VPE, great! I’m all for this as a Plan A (and you can also skip the rest of this blog post fwiw). If you can’t, that’s also okay. Focus instead on finding a competent Engineer #1
Why? The harsh reality is this:
- Engineering leaders like myself are not cheap, and even if you’re able to convince us to join, we’re likely to take up a disproportionately large portion of your cap table. This an analogous to the the current state of massive, long term, guaranteed contracts in both MLB and the NBA, where the contracts themselves can become albatrosses to future growth and flexibility, even when the person is performing.
- Technical leaders, as with all leaders, are force multipliers — which means that we need teams in order to dramatically have an impact on an organization. While we can also help hire out our own team, unless we already have the follower-ship where we can (literally) bring with us our own team, we’re unlikely to have as much of an impact on getting you to your MVP as if you just hired a small team of Engineers yourselves.
Hire an Engineering leader when you have Engineers to lead.
- Lastly, a more nuanced point: Ironically, to land us, you had to convince us to join on the basis of your business model, investors, persona — basically everything non-technical to begin with. If that’s the case, then it’s really the same challenge for you to hire Engineer #1 as hiring a VP of Engineering or CTO. As with all other parts of the business you’re building, for a majority of your first hires (technical or not), it’s all about selling yourselves as founders, and the great business you’re building.
(b) Wait, what if I get my architecture wrong? What if I hire the wrong types of engineers?
Observation: The next fear is often the fear of getting the technical decisions wrong and inadvertently accruing so much tech debt that you will sabotage / mortally wound the company (from a technical perspective) before you even get out of the gate.
Commentary: Bluntly? To be in a position to pay down tech debt, that means that you’ve first been successful enough to have it come back to bite you.
It’s a privilege, not a right to eventually be able to pay down tech debt. No, seriously.
So unless your business thesis is to eek out the last 0.1% of performance of a computationally expensive problem, your pilot customers won’t know (or care) about the difference if your MVP is powered by Angular or React.
The fact of the matter is that as you go from MVP to a scaled product, you’re going to have to refactor everything anyways. Different architectures / technologies are designed to solve for different problems. It’s a fact of (Engineering) life. Just ask my team.
Getting it wrong out of the gate isn’t going to kill you. Not having a MVP (or clients) will.
Lastly, if you don’t know what types of engineers to hire… or what technology to start with. Hire a consultant (or just ping me).
(c) How do I know if I’ve hired the right person as Engineer #1?
Observation: Along with the desire to hire a CTO / VPE out of the gate is the desire to find unicorn engineers — someone who has done this all before, is capable of building the product themselves, and preferably with the pedigree you can show off to your investors.
Commentary: Similar to my earlier comments, if you can find someone who meets the requirements above, congratulations! (and again, you can skip to the end of this article). If you can’t, of all the dimensions to focus on, I would choose (a) General Cognitive Ability and (b) A Bias Towards Action, and (c) Someone with at least 5 years of work experience.
- Inexperienced Engineers, even great ones, don’t know what they don’t know, and are therefore likely to make mistakes without even knowing it. Having some experience means that you’ve also made a few mistakes and hopefully learned from them — while on someone else’s payroll. The five year bar a somewhat arbitrary number. I’m balancing the general pool of available engineering experience against the risk associated with inexperience.
- Most Engineers struggle with ambiguity / risk; we’re born problem solvers / optimization experts → the more the ambiguity, the larger number of combinations that we need to consider. Finding Engineers that are capable of dealing with this and capable of rapidly executing are critical in the early days of a startup where things, by definition, are not well defined.
Great, so how do I test for this?
- Ask questions that highlight a candidates ability to think through the question itself. My favorite question? “What question(s) do you have for me?” (no, really).
From there, I can test for a candidate’s:
- Innate sense of curiosity
- Ability to structure questions
- Ability to synthesize information (based on how they change their questions / reference other answers I’ve given)
- *and* general level of interest in joining.
While it’s not a perfect question, it does avoid a couple of the normal interview pitfalls where interviewers either (a) are testing candidates for specific domain expertise they are not likely to already have *or* (b) are testing for things that the interviewer themselves are unable to assess.
- Push candidates on their line of questioning — i.e. what were you really trying to ask me? or what’s another great way to ask that question? The goal is to see if they are able to abstract things and understand the “why” behind questions? This is important in order to make sure that they can both detach from prior biases and push thought when necessary.
What I really want to test for is can they breakdown and sequence a problem / identify the correct set of trade-offs and make the best possible decision. Your initial engineering team, unless you have a strong product team already, needs to be a capable thought partner to the founders — especially if all you need is a MVP.
Lastly, as answer(s) to some of the most common questions I get:
- Where does cultural contribution fall into all of this?
My “answering the question, without actually answering the question” is that (a) it’s important, but not critical and (b) it’s a function of capitalization and runway. If you have more time / money, you can anchor (relatively) more on cultural contribution.
- Note: Cultural contribution will be absolutely critical by the time Engineering organization reaches the size of Komodo’s, as the norms by which your team operate are among the biggest direct influences of it’s overall ability to deliver.
- What about Engineers from Google / Facebook? (and degrees from CalTech? Cornell?). Does brand really matter?
At the risk of undermining the investments that I have made in my personal life: to be honest, not really. Another way to look at the problem: by definition the top schools and companies output a very small percent of the overall number of Engineers. Seeking engineers with the right brand dramatically restricts your potential pool of candidates. Besides, did I mention that they’re expensive?
Taking a step back, my argument is not that you shouldn’t follow the tried and true model of finding a technical co-founder / head of engineering / CTO as fast as possible, if you can, that’s great. Rather, it’s recognize the opportunity cost of spending the time *and* the likelihood of being able to do so. Quite often what you find is that you’re better off hiring a bunch of engineers, getting them moving, and then hiring in a more senior leader to sort things out after the fact.
For most startups, the main goal is to get to a MVP, and you can get there faster by focusing on what your critical requirements are and rest assured that eventually, you’ll have to refactor anyways.