The Constrained-Resource Headcount Test
When the bottleneck isn't people, each new hire is a net productivity loss unless they uplevel everyone.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 85%
Kilpatrick explains why OpenAI intentionally keeps its research team small while growing customer-facing and engineering roles fast. In a domain where the binding constraint is a shared, finite resource (GPUs), adding a headcount does not add throughput — it splits the resource, slowing everyone else's experiments. The hire is only net-positive if they uplevel the whole group profoundly enough to outweigh the dilution. Where the constraint is human effort instead (writing code), the usual add-people-add-output logic holds.
Origin
Logan Kilpatrick on Lenny's Podcast (Feb 2024), relaying a thread from an OpenAI research colleague about GPU-constrained research productivity, and using it to explain OpenAI's deliberate research-team size policy.
Core principles
- 01Identify the binding constraint before you size the team.
- 02If the constraint is a shared finite resource, headcount dilutes it rather than expanding output.
- 03A hire into a resource-constrained group must uplevel everyone else profoundly to clear the bar.
- 04A hire who opens a new direction and consumes the shared resource is a net negative to the group.
- 05If the constraint is human effort, adding people genuinely adds output — apply the opposite policy.
How to run it
- 1
Name the binding constraint for the team
Ask what actually limits output: is it a shared finite resource (compute, budget, a single production environment, a scarce data set), or is it human hours?
Pro tip Do this per team, not per company. Kilpatrick applies opposite policies to research and to the API/product teams inside the same organisation.
- 2
If the constraint is a shared resource, treat headcount as dilution
Model each additional person as taking a slice of the shared resource. Everyone else's iteration cycle slows proportionally. The default expectation for such a hire is net negative.
Pro tip The concrete version: add a researcher and you now share your GPUs with them, so everyone's experiments run slower.
Watch out The person who joins to pursue a completely different direction is the worst case — full resource consumption, zero uplift to the existing group.
- 3
Raise the bar to 'must uplevel the group'
Only hire into a constrained group if the person increases the efficiency of everyone else profoundly enough to more than offset the resource split. That is a far higher bar than 'strong individual contributor'.
Pro tip Frame the hiring debate as: what will this person make everyone else better at?
- 4
Grow the unconstrained teams aggressively
Where the limit is human effort — customer-facing roles, infrastructure, API engineering — the classic logic applies: another engineer writes more code and does more, and is net beneficial for everybody. Grow there without hesitation.
Pro tip This is exactly OpenAI's shape: research intentionally small, engineering and customer-facing roles growing fast.
In the wild
Most of OpenAI's growth is in customer-facing and engineering roles that provide infrastructure for ChatGPT. The research team — where most of the innovation originates — is intentionally kept small, because in a GPU-constrained world each new researcher splits the compute pool.
→ Research throughput is protected by refusing to grow the team, an inversion of the standard 'scale the innovation engine' instinct.
Kilpatrick contrasts this directly: adding another engineer to the API team or a ChatGPT team means more code gets written and more gets done — a net beneficial improvement for everybody, because the constraint there is human effort, not a shared scarce resource.
→ Two opposite headcount policies coexist in one company, each correct for its own constraint.
Common mistakes
Applying one headcount policy across the whole company
The same hire that accelerates a product team can slow a resource-constrained research team. Uniform hiring policy guarantees you get one of them wrong.
Hiring to open new directions inside a constrained group
A person tackling a completely different direction consumes the scarce shared resource without upleveling anyone, producing a strictly negative return for the group.
Assuming more headcount always means more output
The intuition holds only when human effort is the bottleneck. Kilpatrick flags this as the trade-off product people don't face and therefore don't intuit.
Is it for you?
Best for
Leaders sizing teams where a shared scarce resource — compute, budget, lab time, a single staging environment — rather than people is the real bottleneck
Not ideal for
Ordinary product and engineering teams where human hours are the genuine constraint and adding people does add throughput
From the transcript
“the research team is like again intentionally kept small”
“you now have to share your gpus with that person and everyone else is now slower on their experiments”
“if I add”
“another engineer to like our API team or to our some of the chat GBP teams like you can actually write more code and do…”
From the episode
Inside OpenAI
Logan Kilpatrick (head of developer relations)