Abhijeet Vijayakar

Apr 27, 2016

5 min read

Building an Execution Engine, Part 1: People

This is the second in a series of four posts on building a high velocity startup.

In Startups and the Art of Asking Questions, I wrote about a basic framework within which most startups operate. Startups need to be built to ask questions of the market at high velocity, using three primary factors: people, processes and tools.

This post is about getting the right people into your startup.

In Building an Execution Engine, Part 2: Process, I write about the processes you can put in place to ensure that the people in your startup are highly productive.

Building an Execution Engine, Part 3: Tools covers the tools and systems you should use in your startup to enable execution at high velocity and quality.

Specialization

Startup founders and early employees should spend a lot of time thinking about the roles and responsibilities of the existing team, and the holes the team has, in order to know where to put precious recruiting resources. Roles and responsibilities are as much about defining what people don’t do as about what they do. Do you need a jack of all trades engineer, or separate engineers to focus on the frontend UI, client-side Javascript, or backend APIs? Do you need someone who can create design mockups, run projects through implementation, and analyze product metrics, or are those responsibilities better allocated to different people?

There is a tension here between spreading people too thin and bloating the team. A good yardstick is that it is time to hire when the strain of doing too many disparate things is visible on the existing team, and causing a perceptible drop in their quality of output; perhaps even sooner, if you can afford it.

Startups should strive for being excellent at what they do, and that often means having specialists with deep technical skills in many roles.

Urgency

This is a hard attribute to screen for. If you ask people directly whether they have a sense of urgency, they will likely say yes. Asking them to point to examples of when they’ve shipped projects under time constraints is useful, but the question can be gamed. Looking at whether the candidate’s previous experience was at big companies or small can also provide some directional indication, but it is rarely clear cut — many big companies execute quickly, and some startups move at glacial speed.

For engineers, a more direct representation of the candidate’s bias toward action is simply giving them a programming challenge with a time limit, and asking them to write a solution during the onsite interview. To make it closer to real life, have them use their own computer, any language and IDE that they’re familiar with, and the Internet for research.

We’ve found a wide variance in how much candidates get done when presented with even a simple programming problem to complete in an hour. Some people quickly think through the problem, jump into the solution, and have a fully working program at the end of the hour; others skirt around the main issues, getting no further than a rough outline of a potential solution.

The ability to execute quickly allows startups to perform many experiments in the same amount of time that it would take another company to do just one, and is therefore a key competitive advantage. Every employee of the company should share this attitude of urgency.

Context

This context extends from the company’s external environment to understanding, and appreciating, the function of the different departments within the company. Can engineers tell what value the marketing employees add to the company? Do customer support employees see engineers as simply bug fixers, or as people who can help the long term growth of the company? When people are able to understand how the different groups within the company operate, they are more likely to see each other as partners working toward a common goal, rather than in adversarial or competitive terms.

One way to screen for this attribute is to ask candidates about projects they’ve worked on with people from different departments (marketing, sales, customer support) to accomplish a company goal. Pay attention to whether they tend to downplay the contributions of people in roles different from theirs, or whether they mention those colleagues with respect and appreciation. Are they able to clearly explain the company goal toward which they were working, and why it was important, or do seem interested only in the specific tasks they were required to do?

Conclusion

Read the next post in this series here.

Current: Hippo Insurance. Previous: Google Assistant, Trulia Rentals, EA, startups. Engineering leadership and navigating ambiguity. Build, learn, repeat.

Love podcasts or audiobooks? Learn on the go with our new app.