What to Look For in Your First Technical Hire

I’m looking for a technical co-founder or hiring my first engineer. Since I’m not technical, I don’t know what qualities to look for. Any advice?

There’s a big difference between a technical co-founder and first engineer but putting that aside, here’s a list of things to look for.

• Generalist – A strong indicator of whether a startup will be successful is how quickly they can test and iterate on their ideas. Engineers who are good at many things but maybe not the best in any single thing tend to be better at this. They’re also more capable of adapting with your startup. You might be building a web app now but in 3 months you might find yourself primarily focused on iOS and Android. Ideally you can get an engineer who has range (tough but valuable) or is happy to learn (more likely and still valuable).
• Thoughtful – Key technical decisions such as what language to use, how to design the database, etc. have significant, long lasting impacts on your startup. You want to find someone who is thoughtful and considerate about these decisions. Using an exciting but brand new language might be exciting for them but good luck trying to hire people who know it or want to work with it. Doubly so if that language suddenly goes out of fashion.
• Communication – Related to being thoughtful, a bad engineer will make key decisions without considering the trade-offs, different stakeholders, etc. An okay engineer will consider these things but not communicate that they did and why they made the choice they did. A great engineer will consider them, layout the options, trade-offs, their recommendation and have a discussion about it. You might not be technical but great technical people can bring you into the discussion by explaining it in a way that you understand and from the perspective of the company.
• Useful > Interesting – There’s a type of engineer that’s primarily concerned with either (1) working with the latest technologies or (2) only on problems that are technically interesting. Stay away from them. If you hire one of these engineers, they might do what's technically interesting instead of what's good for the product or company. Most software development isn’t technically interesting. Building an activity hook that triggers an email campaign isn’t technically interesting or particularly fun to build but it sure does boost retention. Find engineers who prioritize building something people want regardless of how interesting it was to build.
• Management (Optional) – There's a type of first engineer or technical co-founder that's an incredible individual contributor. The type that can solo build the first version of the product in a few weeks. Unfortunately, they often are not interested in being a manager. That can work but at some point you'll have more engineers and will need someone that can manage them. If that's not your first technical hire, you're going to have to find someone else.

In addition, there’s a few common mistakes you should be aware of.

• Large Company Engineers – Before I get a bunch of hate mail, this is obviously not true of every large company engineer but it’s happened enough to call out. Engineers from large companies, especially non-technology companies (banks, etc.) but even places like Google, tend to be specialist. That makes sense when you’re operating at that scale and complexity. Unfortunately, very little of that expertize is necessary at an early stage startup. Furthermore, there tends to be more culture shock to how quickly and chaotic startups are. Lots of great engineers at large companies, just be mindful and don’t assume that an engineer from XYZ large company is an automatic win.
• Outsourcing – Outsourcing your initial MVP can work but there’s a couple of things to consider. First, it’s likely you’ll have to throw away everything they did at some point. To agency, your product is a temporary project. Second, at some point you’re going to want to build an in-house team. Again, your ability to iterate quickly is a core competency. You don’t want to outsource core competencies. Third, it’ll likely take more work than you’re thinking. You’ll need to stay on top of them, communicate clearly and repeatedly what you want, etc.

Hopefully that's helpful. I sometimes get the feeling that non-technical people think technical people are magicians or something. They do things they'll never understand. It's simply not true. Writing software is a skill like any other and any reasonably intelligent person can do it. There's no need to be intimidated by it or the people that do it. If you don't understand, ask them to explain it to you. If they can't, that says as much about them as it does about you.