Tom Pinckney was VP Engineering and co-founder of SiteAdvisor (along with me and Doug Wyatt) up through and beyond SiteAdvisor’s acquisition by McAfee. Tom sometimes gets asked by friends who are starting internet companies what to look for in potential VP Engineering hires, so we thought it might be helpful to put Tom’s thoughts down in writing here. (In addition to being co-founder and VP Engineering at three VC-backed startups, Tom has a BS & MS from MIT in Computer Science). Here are Tom’s thoughts:
This is based on my experience with very early stage Internet companies. I’m sure if I were building an ethernet switch I’d want someone different. But if I were building a website, whether for consumers or other businesses, this is what I’d look for.
Note that we think of the VP Engineering role (as opposed to the CTO) as the person who makes software that gets built on schedule, on budget, in a reliable, scalable way etc. You might also want a CTO at your company to think of big, creative ideas but often those people aren’t good VP Engineers.
1) They are comfortable with web-speed development — release every week, ok to have minor bugs on the site vs never getting a release out etc. You don’t have any users right now so you can afford a few bugs. In six months you will have users and then you can start worrying more about having more process.
2) They are not overly process oriented — you’re not building the space shuttle so don’t need to spend three months designing the next release. You do need to know how the big pieces of the problem will interact with each other and what the overall system architecture will be. No Gantt chart experts, non-techy people managers, or high level big company guys who haven’t been hands on in years.
3) They are someone who can architect the system, understands how to test/QA a site, what IT needs to do to keep the site running fast and reliably. They need enough technical expertise in all areas to see how each person’s work affects other people’s work, what it’s inputs and outputs are, see how each piece fits into the rest of the system, judge trade-offs being made, estimate complexity, timelines etc.
Make sure they can talk in intimate detail and have opinions about all of this. How should the DB clustering work? What exactly were the test scripts checking and how did they get written so that as the software changed all the scripts didn’t have to get thrown out? That sort of thing.
4) They have experience using open source technologies such as MySQL, Apache, Java/Python, Linux etc. I’d avoid people who want to use MS
technologies since you have to pay a lot for it and most of the kids these days want to work on the open source stuff.
5) They are someone who can code and wants to code on day one and could even build the first version of the system, but understands that by day 365 they won’t be coding any more. You’re not so big that you can afford anyone who just manages in the early days.
6) They can architect the system in a way that developers can build your project with maximal parallelism and so that computers can run it with maximum parallelism so that you can scale to the millions of users, terabytes of data, or whatever it is you need to do.
7) They should prefer the simple to the Baroque. Most simple, reliable and quick-to-build systems can also be built as a complicated, slow, bug-laden piece of software too. Every line of software that doesn’t exist because of your simple design is a line that has no bugs, can’t slow the system down, and won’t take time for new developers to understand. Can they talk about how they design things to be simple, what they gave up to make the system simple, etc?
1) Watch out for people that seem dogmatic about unreasonable things (”Anyone who uses Postgres instead of MySQL is an idiot” etc etc) (Note, see my comment above about anyone that uses Windows technologies being an idiot).
2) Watch out for empire builders or people who need lots of resources. Do they believe they can build anything with a couple of great guys or have they never worked with a few great people before? Do they want to hire a large over-seas staff because everyone else is doing it and it will look good on their resume? Do they know so little about things that they need lots of expensive tools or consultants?
3) They should be outgoing, fun, intense people. No one likes to work for a low energy introvert. Ask them why they want to manage instead of coding. See if they are an engineer who got promoted into management because they wanted the higher pay but really would be happier just coding all day and not interacting with people. A lot of people aren’t into managing but end up doing it for the money. Or maybe they are an ego maniac that needs to be in control since otherwise no one pays attention to them?
4) Are they really excited about technology, do they do techy things in their spare time, etc? Do they talk about how they programmed for fun in high school or wax poetic about the cool game they wrote back in the day?
5) Most technical hiring is about convincing engineers that your problems are the best to work on and that the rest of the team are super smart people, so your VP Eng will have to be able to pitch this.
6) The ideal VP Eng could build most parts of the system themselves, but they’re self-confident enough to work with people better then themselves too.
7) They should be hungry to step up and prove themselves. Ideally they have been a tech lead or had some managerial exposure already, but are
eager to step up and build something even bigger then they’ve been responsible for so far.
Where do you find someone that has these qualities?
Unfortunately, there’s not one good answer. I’ve seen people have good luck by having a recruiter target specific companies. Your personal network is obviously the ideal way so that you can get trusted references. If you have outside investors, their network might be useful too. We’ve had basically no luck using job boards like Monster and Hotjobs.
I think it’s hard for people with no technical background to interview a VP Engineering candidate. If you don’t have a technical background, have someone technical (if not someone full time at your company, perhaps an advisor or board member) interview with the candidate as well.