Headcount dilemmas.

When I was four, I won a cake walk. For thoes who haven’t partaken, a cake walk is when a group of folks walk around a path on the floor, and then stop when they are told to stop. Whether you win or lose a cake is entirely out of your hands, it’s a matter of timing and position, both of which are out of your control.

I’ve been reflecting lately on the forces which make headcount planning–really just a specialized form of resource allocation–difficult, and perhaps the cake walk has something to teach us.

Position

Folks often talk about the company growth “S curve”, with a company’s growth experiencing three phases: 1) exploring a problem domain as a startup until they find product-market fit, 2) rapidly scaling after finding product-market fit, and 3) ending as a mature company with slowing growth.

Depending on your position on this curve, you’ll orchestrate headcount differently. Early on, you want to keep burn-rate low to extend your horizon for identifying a successful product. Later on, you’ll want to be methodical in adding headcount, to ensure you preserve or improve margins as revenue growth declines. In-between, you’ll want to grow quickly enough to avoid headcount becoming the defining constraint for your revenue growth.

However, this curve really reflects a single business line, and most successful companies rapidly transition from a single business line to multiple, which leads you to a much more challenging scenario of balancing investment across a portfolio of businesses with a broad range of revenue, margin and growth. This is the Innovator’s Dilemma.

Optimizing across this portfolio is difficult, and something I’ve realized is that while your senior leadership is explicitly performing that optimization, many other teams are also put in the place of implicitly doing the same, without the benefit of senior leadership’s broad ken.

For example, folks on infrastructure teams are implicitly prioritizing security, scale and stability features useful for the largest business lines against the fast-iteration needs of smaller business lines. Operations teams are deciding how to align their teams and processes against ticket volumes across all business lines. Design and data science teams are pondering the same tradeoffs, too.

Some ways I’ve tried to navigate the innovator’s dilemma:

• Don’t get eliminated from the iterative tournament. Businesses stay in business by providing sufficient value at every moment, and fail if they are too long-term or too short-term focused. One mechanism I’ve found that implicitly starves short-term work prioritizing revenue-generating business lines is when KTLO work is not fully funded. This disproportionately impacts revenue lines, because they are the ones that are experiencing scaling bottlenecks, whereas exploratory work rarely pushes infrastructure boundaries of existing systems. Exploratory work often requires new infrastructure though, which can put the two at tension.

  Being clear about the level of work required to maintain the existing business lines, before considering work to create new ones, is powerful because it forces you to explicitly deprioritize them. KTLO tends to be less inherently interesting for folks, so if you aren’t structured and intentional about this proces, you’ll generally starve existing businesses without noticing it. This is problematic because it undermines your largest business lines, and also because the delta between required and provided resources is paid through technical, product or organizational debt.

• Composable abstractions such that the lower abstractions are specialized towards the needs of scaled businesses, and the higher abstractions are specialized towards rapid development. Users select the abstraction appropriate to their current needs, and migrate to lower abstractions as their needs become more sophisticated. An example here might be prototypers starting with AWS Lambda, graduating to Amazon ECS when they require in-memory state for performance reasons, and then a small subset moving to AWS EC2 if they truly require persistent state.

• Invest explicitly with clear thresholds a new business line needs to hit before receiving additional funding. This helps address “zombie business lines” which are supported by your most successful business lines’ profit, but which are not on the path to product-market fit. As a corrolary, having a clear deprecation path for new business lines is a powerful enabler of this kind of thing. Without a deprecation strategy, even challenged business lines become difficult to extract yourself from. (That is an advantage that small, single line busineses have over lager ones: they can simply close.)

• Deprecate explicitly when things don’t ramp properly, or market conditions pull your product out of product-market fit. Deprecating things is very hard, but the alternative is worse: a slow, ambiguous languishing. (I’m raising a pet theory that companies which excel at deprecation maintain their velocity of innovation longer than those that excel at maintenance.)

Time

The other dimension of headcount planning that can be difficult is that there are enough independent decisions made by different folks, that you can easily find yourself in an accidental prisoner’s dilemma.

Because headcount allocation is generally zero-sum, there are sometimes “winners” and “losers”, meaning folks who do or don’t get their requests fulfilled. Sure, sometimes success is defined by by who is the most compelling writer or who is the most connected, but I think most headcount problems are related to:

1. folks making the decisions having to make their decisions without knowing the decisions made by others, e.g. synchronous turns, and
2. not knowing how many rounds of negotiation will occur, e.g. will these numbers stick or will we do a refresh in a quarter, will we get to adjust our ask later in this process, etc.

Some of the approaches I’ve used here are:

• Make visible asks to ensure that other folks are aware of what you’re doing, and can at least incorporate your actions into theirs! If the largest organizations do their plans visibly, then everything else can fall into place.

• Headcount reviews with your peer teams where everyone discusses their planned escalation are a particularly effective way to make visible asks. They’re also couple well with project roadmap reviews effectively to identify hidden prioritization decisions to be made.

• Scalable headcount asks instead of fixed asks. For example, get approval for a ratio of infrastructure to product engineers instead of asking for 100 infrastructure engineers. Then your asks will be scaled to other asks, protecting you from uncertainty over of the number of rounds of others’ decisions.

• Maintain a buffer of headcount beyond your expected need, to create some flexibility for future adjustments. I think this is often bad behavior to be avoided. In a sufficient burdensome process, it’s probably the most effective behavior, and best for the company. This is significantly less “bad” behavior if folks implement buffers consistently across teams/organizations.

How do you handle balance resourcings across a growing company?