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.
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.)
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:
folks making the decisions having to make their decisions
without knowing the decisions made by others, e.g. synchronous turns, and
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?