Starting a High-Tech Business: Hiring Your First Engineer


I'm starting a new business called Kynetx. As I go through some of the things I do, I'm planning to blog them. The whole series will be here. This is the twenty-sixth installment. You may find my efforts instructive. Or you may know a better way---if so, please let me know!

Allan Carroll asked me a question on LinkedIn that I thought I would answer more publicly:

What's most important in hiring the first engineer at a startup and how do you find that person?

On one hand, I'm probably not the right guy to answer this question because I cheat. At both iMall and at Kynetx, the first engineer I hired was a (barely) former student. Kelly Hall in the case of iMall and Sam Curren in the case of Kynetx. Being a professor gives me the opportunity to get to know, over the course of months or years, the character, work habits, and innovative abilities of a number of great programmers and I simply cherry pick the best of the best.

On the other hand, that doesn't mean that I didn't have some clear objectives. A startup's first engineering hire comes at a special time. You've likely been writing code solo for several months. You've picked many of the architectural features and implementation directions. You need additional horsepower in several different areas:

  1. You need someone to help flesh out the parts you don't have time to do alone.
  2. You need new skills for some things you can't do or aren't particularly good at.
  3. You need innovation around ideas that haven't even surfaced yet.

Because you're fiscally constrained, you can only hire one person. In the short run, you need (1) and (2) badly. In the long run (3) is more important. In the case of Kynetx, I was looking for someone to build other pieces of the architecture while I continued to work on the core engine (which was written in Perl). So I was able to relax requirement (1).

One of the things I've written about before is my desire to hire people I know. People have pointed out that that idea doesn't scale, but in the early stages of a startup, it doesn't have to. The early stages of a startup are when you can least afford a hiring mistake. Hiring the wrong person can be deadly. So, I simply wouldn't trust it to someone I've met in an interview and exchanged a few emails with. I want to know that I'm hiring someone who is "smart and gets things done" in Joel Spolsky's words. If you can't hire someone you know well, then you'd better find someone who will give you honest references for whoever you're considering.

As you can see from my penchant for hiring students, I like to hire engineers early in their careers. That has the advantage of being able to get them into your culture with as little baggage as possible. I'm a big believer in culture. When you hire someone who's worked other places you need to assess whether their cultural experience and expectations will match your own. That doesn't mean I won't hire engineers further along in their careers. Although most of them are people I've worked with before so I know what baggage they bring along and they know what they're getting in to.

Ideally, the first engineer you hire will be more than a code monkey. You need a leader and someone who can jump into things that they're not familiar with. You need someone who has their own ideas and isn't afraid to express them. At the same time, they need to be able to withstand the blow to their ego when not all of their ideas are immediately taken up and paraded around as the salvation of the company.

Finally, I think that the first engineering hire has to be "startup compatible." Startups frequently have lower pay and fewer benefits than a job with an established firm. The other side of that coin is that your first engineering hire should get (and expect) equity of some form as an offset. The hours are long and unpredictable. They might be asked to do things beyond coding like speaking, teaching, or doing tech support. Heck, the junior engineer at Kynetx even has to stock the fridge. All these things can be a problem for an engineer (or spouse) who isn't used to them--even when disclosed up front.