Systems & Organizations
Stop Giving Teams Full Autonomy
The most-copied autonomy model in software came with a warning from its own author that everyone reorganizing around it ignored.
2026-09-021 min read
Henrik Kniberg and Anders Ivarsson published a paper in 2012 describing how Spotify organized its engineers: squads, tribes, chapters, guilds. It escaped. Within a few years that vocabulary was sitting in reorganization decks at banks, retailers, and telecoms that had never built software the way Spotify did. Kniberg spent the following years telling people to stop. The paper was a snapshot of one company at one moment, he said, a journey in progress rather than a destination, and Spotify itself never worked quite the way the paper described.
The part that traveled was the org chart, because an org chart is free. What the copies left behind was the diagram from Kniberg's own later material, which puts alignment on one axis and autonomy on the other and argues that high autonomy is only worth having in the high-alignment corner. Autonomy is a permission, and a permission can be granted in an afternoon. Alignment is a shared answer to what matters most right now, and it is bought with continuous, expensive leadership attention, the same conversation held again every time priorities move. Take the cheap half on its own and you do not get a fast organization. You get squads defending divergent definitions of success, hand-offs nobody scheduled, and a design team building what engineering never planned to integrate.
The diagnostic is not whether your teams feel empowered. It is whether they agree about what is not being done. Ask two squad leads, separately, to name the most important thing the company is currently choosing not to do. Matching answers mean the alignment is real and the autonomy will convert into speed. Different answers mean you have handed out the permission without the compass, and the coordination tax is already accruing somewhere you have not looked yet.
Key insights
What travels between companies is the structure, because structure is free to copy and alignment is not.
Autonomy is a permission granted in an afternoon; alignment is a priority order rebought every time priorities move.
Agreement about what you are not doing is a sharper alignment test than agreement about what you are.
Why it matters
Autonomy granted without alignment does not produce speed; it produces a coordination tax that shows up as hand-offs, re-work, and defended local roadmaps.
Alignment is the expensive half and the half that cannot be copied off someone else's org chart, which is why imported operating models underperform their source.
Use this tomorrow
1Ask three team leads separately to write down the single most important thing the company is currently choosing not to do, then count how many of the three answers match.
2Take your last two reorganization or operating-model decks and count the slides describing team structure against the slides stating a company-level priority order; write the ratio at the top.
Go deeper
The 2012 paper was explicit that it described work in progress, and Kniberg attached steadily more emphatic caveats as the model spread, warning that it was a snapshot rather than a blueprint and that copying another company's structure skips whatever made that structure work. His alignment-versus-autonomy matrix is the argument compressed into one picture: at low alignment, high autonomy produces energetic motion in unrelated directions, while at high alignment the same autonomy produces speed. The reason the failure repeats is that structure is legible from outside a company and alignment is not, so the copy faithfully reproduces the part that was never the point.
The opposite case is worth stating, because structure genuinely does determine outcomes. Melvin Conway observed in 1968 that a system's design tends to mirror the communication structure of the organization that built it, which means an org chart is never neutral and badly drawn teams will produce badly drawn interfaces however aligned everyone feels. The reconciliation is that structure decides what is cheap to build while alignment decides what gets built, and neither one substitutes for the other. Reorganizing is the right answer when two teams who must talk constantly report up through different executives, and the wrong answer when the actual problem is that nobody can rank the roadmap.
