Headcount goals, feature factories, and when to hire those mythical 10x people

What is output?

• I don’t mean an engineer just hammering on the keyboard shipping code at light speed. When I talk about it, I refer to a whole range of things, like helping your coworkers, introducing new frameworks, improving the process, and much more.
• You can’t really measure it, of course. But all managers try, when they set the salary of Alice to $110,000 and Bob to $115,000.

Headcount goals

• In a typical engineering hiring process, a CTO (or high up person) figures out roughly how much they need to get done compared to how many engineers they have, then goes to the CFO and haggles a bit, then gets assigned a headcount number and a salary range for those people. That then gets distributed across the org recursively, and every hiring manager gets a target for how many people to hire.
• Let’s say the CTO is absolutely adamant that they need to grow the engineering team by 2x in a year. This bubbles down to a junior engineering manager. If you are running a decentralized interview process, then you now create a great agency problem where the junior manager is told their success at the company is partly measured by how well they reach their hiring goal. Of course they are going to lower their bar for who they hire!

Solving the misalignment

• The right solution to this is partly to make the interview process and decision centralized.
• But let’s also on more fundamental level: why headcount goals? This makes the underlying assumption that every engineer has roughly the same productivity. In reality, engineer productivity can be very dispersed.

Cost as a function of productivity

• What’s maybe surprising is that cost as function of productivity seems to be a sub-linear function.
• Any exponent less than 1 works for the purpose of this argument, and note that an exponent larger than 1 would not exist in an efficient market. No one would hire a 2x engineer at 2.1x the cost – they would simply hire 2 1x engineers.
• This seems like a no-brainer then. Why wouldn’t everyone pay a ton more money to hire the most senior engineers? Let’s throw headcount targets out the window and replace with total output target Maybe we should even go as far as having a total salary dollar target, rather than headcount?

Feature factories and task overhead

• There’s one common argument for hiring “cheaper” engineering talent which is that a ton of tasks are straightforward, unsexy, or boring.
• At the extreme end of this spectrum is a type of company often derided as a feature factory, where I suspect people imagine a sweat shop of super inexperienced engineers basically updating forms in HTML or adding tracking pixels.
• I’m pretty unconvinced by argument. A senior person will find opportunities to automate and reduce repetitive parts, paying for themselves.
• However, there’s a slight variant of this idea that I think actually does justify hiring less experienced engineers, which has to do with task overhead. Let’s consider a toy model:
  • Let’s say we have two engineers, one called Norm the normal engineer and one Twanda the 2x engineer. Let’s say they both work at a company where Norm spends 50% of his time actually working, with the rest of the time lost as “task overhead”. Maybe a bunch of bookkeeping (going into Jira, creating Github pull requests, waiting for CI etc). This is overhead that have to happen for every task.
  • How much more productive is Twanda compared to Norm? 2x? No! Twanda generates 4/3 as much value! And in general, if a 1x engineer spends c of their time on “task overhead” items, then a kx engineer will have output factor 1/(c/k+1−c).
  • Note that spending time in meetings doesn’t have the same impact. In a hypothetical company where 90% of all time is being spent in meetings, a 2x faster engineer would still get 2x more work done (in the 10% of time that isn’t spent in meetings). What my model is talking about is task-related overhead.

Getting the most value out of your tech team

• If you don’t have [a centralized recruiting process with a consistent high bar, and reduced task-related overhead], there’s no point trying to hire super senior people: and in particular you are probably better off hiring average engineers. Xavier Amatriain wrote a blog post with sort of similar conclusions: don’t expect that you can cherry-pick elements of the Netflix culture and drop it into your startup. You might have to start with your development process and your hiring process!
• If you had asked me before I wrote this blog post why some companies pay top dollars for engineers and other don’t, I probably would have said that some companies are super tech focused, and so they can truly get value out of really expensive engineers, whereas some companies are a collection of scripts using some off-the-shelf framework, and an expensive engineer wouldn’t make a huge difference.
• I still think this is right, but I think the exact causality has to do more with the model posited in this post. As an example, Google (known for paying much) have types of challenges that engineers can work independently for a very long time. That lowers the (amortized) task overhead, which means that they get more value out of an expensive (but more productive) engineer. Other companies have a large quantity of small projects (thus a large task overhead) meaning they rationally shouldn’t pay at the top of the market.