Single-Threaded Leadership
Kill resource contention by giving one leader one mission and every function they need to deliver it.
- Difficulty
- Expert
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 95%
As Amazon scaled past the point where the CEO could sit in every meeting, teams began competing for a central pool of engineering resources, and leadership spent its time refereeing roadmap line items. The answer was to invert the org: create standalone teams, each owned by one leader, with the cross-functional resources they need dedicated to them (straight-line, dotted-line, or a mix). Leadership then referees resource allocation between teams a few times a year instead of adjudicating priorities daily.
Origin
Emerged at Amazon during the 2003–2007 complexity crunch as an evolution of the two-pizza team, described here by Bill Carr, who ran single-threaded teams for what became Amazon Music and Prime Video from roughly 2004–2005.
Core principles
- 01Ownership, speed, and agility are the three things you are buying — everything else is a trade.
- 02Move from a project orientation (resources swarm, then leave) to a program orientation (a standing team owns the surface forever).
- 03There is no free lunch in org structures — you are always trading one thing for another.
- 04Better to fully own a short list of things than to half-own a long list.
- 05Autonomy is earned through a plan review, not granted by default.
How to run it
- 1
Decouple the technology first
You cannot single-thread teams on top of a monolith with pervasive interdependencies. Amazon could only move once it had a service-based architecture with defined, well-documented API endpoints that teams could own.
Pro tip Treat the architecture migration as a prerequisite, not a parallel workstream.
Watch out Reorging onto a monolith just relocates the contention into cross-team code conflicts.
- 2
Run the resource test before drawing the box
For each proposed team ask: does this leader have the resources within their control to effectively manage this product, department, or P&L? If you have sliced too narrowly, the answer is no and the team is not viable.
Pro tip Carr's Prime Video example: TV apps, game consoles, and mobile all pass the test cleanly, and can be sub-divided further into Xbox, PlayStation, and iOS teams.
Watch out Narrowing a P&L too far leaves a leader accountable for outcomes they cannot influence.
- 3
Make the team write and defend the plan
The leader and their team document what they will build and how they will measure success. That plan gets reviewed and deeply scrutinised — up to the VP, SVP, or S-team level — until senior leadership and the team are genuinely aligned.
Pro tip The value of the review is that afterwards the team never has to wonder whether they are aligned with the CEO. They can sprint.
- 4
Give the team controllable metrics and their own roadmap
The team runs its own prioritized list against the metrics it can actually move — e.g. the percentage of searches where the customer clicks a top-three result, or page-load milliseconds by browser and device type — rather than fighting for headcount.
Pro tip Teams will always want more resources; the correct channel is petitioning management once a cycle, not renegotiating priorities weekly.
- 5
Install functional-excellence countermeasures
Because engineers now report to generalists who cannot run a code review, rebuild functional depth deliberately: keep a C-level functional leader (Amazon kept Rick Dalzell over core infrastructure and services) who owns company-wide standards for code reviews, interviewing, and the promotion ladder; and give senior people a second job beyond their day job — sitting on promotion panels, running code reviews for other orgs.
Pro tip Make the second job an explicit expectation of VP and director roles, not volunteer work.
Watch out Skip this and you get speed for a year, then a slow rot in craft quality as engineers lose access to expert coaching.
In the wild
In the project model, a team swarms on 'change the search result page and algorithm', delivers in six months, then disperses to another part of the company. In the program model, one team always works on search, thinks holistically about improving it, and runs its own prioritized roadmap against metrics it controls.
→ Time previously spent on resource contention and planning artifacts is spent building; leadership referees headcount two or three times a year instead of arbitrating the roadmap daily.
Carr took over a small software engineering team for the nascent music and video businesses despite having written no production code since high school (BASIC and Pascal) and holding an MBA and a marketing background. He could not conduct a code review or an architectural review, let alone mentor an engineer on craft.
→ Amazon compensated structurally — company-wide engineering standards owned by a functional C-level leader, plus cross-org promotion panels and code reviews — rather than reversing the org model.
Common mistakes
Adopting the model without countermeasures
Spreading every engineer, marketer, and BD person into small teams under generalist leaders risks functional competency decay. Carr treats countermeasures as a required part of the design, not an optional add-on.
Confusing it with 'one visionary's ass on the line'
Carr explicitly corrects this reading: it is one leader AND their team who are accountable and responsible, and they don't get to go off unreviewed — there is an intense plan review before any sprinting begins.
Solving contention with more collaboration
The instinctive fix is an intense centralized collaborative planning process. Amazon went the opposite way, because the planning meetings and projection documents were bureaucratic time-wasters resting on deeply flawed assumptions — debating numbers built on bad assumptions is a waste of time.
Is it for you?
Best for
Leaders of a scaling company where multiple teams fight over one central engineering pool and executives are refereeing roadmap items weekly.
Not ideal for
Small companies still on a monolithic codebase, or teams so narrow they cannot control the resources needed to hit their own goals.
From the transcript
“the three things we really wanted were ownership Speed and Agility”
“we moved from what we called a project orientation to a program orientation”
“instead of management Senior Management refereeing every different every item on a road map they're refereeing which teams have how many resources”
“there's no free lunch in org structures any org structure you're trading off one thing for another thing”
“part owning half owning you know a long list of things instead of fully owning a short list of things”
“people had other jobs in addition to their day job to build and maintain functional excellence”
From the episode
Unpacking Amazon’s unique ways of working
Bill Carr (author of Working Backwards)