We have a saying. 'Move fast and break things.' The idea is that if you never break anything, you're probably not moving fast enough - Mark Zuckerberg
What is the optimal rate to hire people? What is the optimal rate to fire people? To address these questions we must first shape the problem.
Broadly hiring involves some up-front cost. From the perspective of the company, the cost will largely be the opportunity cost of onboarding a new hire as opposed to someone else in their place. Secondary costs are financial, and lower quality work being introduced into the organisation.
Hiring involves long-run benefit. Talented individuals, who are aligned with the companies values, culture and mission create huge value in the long-run. Instagram scaled to 14 million users with 3 engineers. WhatsApp scaled to 1 billion users with 50 engineers. At CHAI we’ve surpassed 10 million users with 15 engineers.
So our intuition is that hiring at a startup is likely an edge-case solution. It probably involves hiring as many people as one possibly can, but rejecting anyone who cannot contribute to a massively impactful product.
How can this be implemented in practice? Interviewing and selecting who to hire sounds a lot like an optimal stopping problem. For which it seems likely the solution from the secretary problem is a good heuristic.
Evaluate N candidates. Reject the first 1/e, and hire the next candidate which is better than the best interviewed so far.
Great, so now we know what our hiring rate should look like. But we have a limited number of ‘slots’ or people which can be onboarded at a time. How do we know when to ‘reject’ someone, i.e. fire someone to free up a slot? This sound like a dynamic-programming problem where the Bellman equation applies. Intuitively if the expected value of a new hire is greater than the value of an existing hire then the person should be rejected and the slot opened-up for a new hire.
How to determine the thresholds? From personal experience the standards must be exceptionally high. Any individual who cannot contribute at a level on-par or above the existing team will be a poor use of an ‘onboarding slot’. Fundamentally this is because talent or productivity is distributed according to a power-law.
How is this implemented at CHAI?
Through personal experience, trial and error and learning what other high leverage teams do, we’ve learnt that between 5 weeks and 3 months is sufficient to make an accurate bet on whether an individual is likely at the far right of the distribution of the power-law.
Therefore, in the first 3 months onboarding new-hires are put under additional scrutiny, where rigorously high-standards are explicitly outlined, and the team continuously track people as they are onboarded. Paying close attention, not to the intercept, but the slope. “Is this person on a trajectory where within
12 months they are operating at an outstanding level?”
What this looks like in practice?
Typically we see a failure rate of about 25%-50%. This varies depending on the candidate, people with less track record tend to be higher-variance, people with more experience tends to be less-variance. People who pass the Fire-Fast Mechanism (FFM) tend to be very focused on learning, adapting to the team, and producing high quality work.
People who fail the FFM tend to be worried about how people view them, they devote energy to looking good, and ultimately are unable to operate at the
same pace as the rest of the team.
The single best predictor of someone passing the FFM is if the candidate believes they will pass it themselves. This is likely down to the informational asymmetry where super-stars have a full-understanding of their own abilities, whereas people with overly impressive resumes but less talent are more likely to fear underperforming.
For those who join CHAI, but ultimately don’t pass the 3 months probation, we offer them 2-4 weeks compensation as part of their severance package. We believe this is a healthy amount of cash so individuals have time to look for another company for which they are a better fit.
Suggested further reading: