The Four Levers of Velocity at Scale
Small missions, a real platform, leaders in the trenches, and a team you keep recalibrating.
- Difficulty
- Advanced
- Time to result
- ~ongoing to results
- Steps
- 5
- Confidence
- 91%
Henrickson's answer to the question he is asked more than any other: how do you maintain — and even improve — velocity as you scale? Four levers: decompose the always-large problem into small-team-sized missions that minimize horizontal communication; bake complexity into a clear platform so domain teams have a smaller decision space; have leaders dive deep rather than assign hills; and continuously recalibrate team composition as products move through lifecycle stages.
Origin
Jeremy Henrickson, drawing on scaling Coinbase's product and engineering orgs 10x through the 2017 crypto run-up and on building Rippling's multi-product org as SVP Product.
Core principles
- 01The problem is always very large; the win is decomposing it into pieces small groups can attack wholeheartedly.
- 02Horizontal communication is the tax — 300 people on one thing fails on communication paths alone.
- 03Platform investment reduces the decision-making complexity for everyone working on the domain part of the problem.
- 04A platform cannot be written speculatively and hoped into fitting; it is iterative, and it needs people who do systems thinking and product thinking simultaneously.
- 05Leaders learn where the challenges are by being in the trenches on the hardest thing, not by allocating hills from above.
- 06Skill fit decays with product lifecycle: zero-to-one people two or three years in may neither enjoy nor be good at scaling.
- 07With all four levers plus precise product leadership, velocity can accelerate over time rather than decay — engineers do more with less as more is baked into the platform.
How to run it
- 1
Decompose into small teams with clear missions
Break the very large problem into sufficiently small bits that small groups can attack wholeheartedly, and structure them to minimize horizontal communication between groups.
Pro tip Test a proposed team boundary by counting the coordination edges it creates, not the headcount it contains.
Watch out If 300 people are trying to work on one thing, sheer communication path count makes acting quickly impossible regardless of talent.
- 2
Bake complexity into a clear platform
To the extent it is a technology problem, push shared complexity into a platform with a clear, easy-to-use interface — easy in all the ways both engineers and product people want it to be easy. This shrinks the space in which domain teams have to think.
Pro tip Staff the platform with the rare people who can do systems thinking and product thinking at the same time; the interface has to serve both audiences.
Watch out You cannot just write a platform and hope it works for the products. It is very much an iterative thing, co-evolved with real product teams.
- 3
Dive deep as a leader
Resist the temptation to float up and assign hills. Pick whichever thing seems hardest or most complicated and be in the trenches with the people on it, as often as you can.
Pro tip You always learn a lot from the detailed exercise — treat it as a standing habit, not an intervention.
- 4
Recalibrate the team's experience distribution
Continuously check the seniority and experience mix against what the product now needs. The people who were amazing at zero-to-one may, two or three years on, be scaling to millions of users — a job they may neither love nor be good at.
Pro tip Frame the move around what people love doing: 'hey, let's try this other thing instead.' Fit, not failure.
Watch out Leaving a mismatched team in place is invisible drag — it looks like a motivation problem and is actually a lifecycle problem.
- 5
Add precise product leadership on top
Pair the four levers with product leadership that is very clear and precise about what needs to be done. Without it the levers produce fast motion in unclear directions.
Pro tip The compounding effect: as more is baked into the platform, engineers do more with less, so velocity can actually increase with scale.
In the wild
Rippling runs many product lines — payroll, benefits, device management, identity, time and attendance — each of which is a multi-billion-dollar industry on its own. The activation energy of building the first versions of everything on one single system of record was extremely high, but once the platform existed, each new vertical could be built as a small independent startup on top of that foundation.
→ Small independently-operating teams across many products, with velocity that Henrickson says exceeds any company he has worked at from 5 to 5,000 people — precisely because the platform absorbs the shared complexity.
Common mistakes
Speculative platform building
Writing a platform up front and hoping the products will fit it produces an abstraction nobody can use. The platform must be built iteratively alongside the products that consume it.
Solving velocity with headcount
Adding people to a large undifferentiated problem multiplies communication paths. The lever is decomposition into small missions, not more bodies on the same mission.
Assuming skill fit is permanent
Teams are staffed once and then left alone. But the product changes stage and the required skill set changes with it, so a great zero-to-one team quietly becomes a mediocre scaling team.
Is it for you?
Best for
Product and engineering leaders at a company past ~100 people watching per-engineer output decline as headcount rises.
Not ideal for
Very early startups where there is nothing to decompose and no platform worth building yet — premature platform investment is pure overhead.
From the transcript
“you want like small teams with clear missions right”
“having smaller groups groups of people breaking down what is always a very very large problem into like sufficiently small small bits that small groups…”
“a clear platform with a clear interface easy to use and all the ways that both engineers and product people want it to be easy…”
“and I think the last thing is it's just making sure that teams have like the right distribution of like experience and and seniority”
From the episode
Moving fast and navigating uncertainty
Jeremy Henrickson (Rippling, Coinbase)