ZeroBlockers vs Spotify Model

A reorganization can copy the visible structure quickly: teams become squads, departments become tribes, and line managers become chapter leads. Who decides and who pays stays exactly as it was.

The 2012 paper describes much more than a chart. Squads have a long-term mission and direct contact with stakeholders. A regular survey asks each squad which dependencies are blocking it, and the results lead to “reprioritization, reorganization, architectural changes or technical solutions.” An operations team exists to help squads release their own code. The goal is stated in words ZeroBlockers could have written: “Ideally each squad is fully autonomous with direct contact with their stakeholders, and no blocking dependencies to other squads.”

It stops there. It does not say who funds a squad, which decisions a squad owns, or what replaces a change board. Without that, organizations keep what they already have: project budgets and release approvals.

The source is Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, written by Henrik Kniberg and Anders Ivarsson in 2012. The paper is careful about what it is. It calls itself “only a snapshot of our current way of working” and “a journey in progress, not a journey completed.”

Accounts differ on how fully Spotify followed the description. Kniberg wrote in 2022 that “at the time (2014) most teams used most of the model most of the time,” and that parts have since changed.

Jeremiah Lee’s 2020 account draws on his own time at Spotify and on former colleagues. He quotes agile coach Joakim Sundén: “Even at the time we wrote it, we weren’t doing it. It was part ambition, part approximation.” He also reports Ivarsson’s worry about people treating the description as a framework to copy.

Ask what job each Spotify structure did, and who does that job in your organization. The titles do not convert one to one.

• Owning a customer outcome. Squads carried this. In ZeroBlockers a Stream Team does: two to four designers and developers who own one part of the customer journey from research through live use.
• Setting direction and resolving conflicts. The paper has product owners keeping a shared roadmap. ZeroBlockers gives this to a Product Team, the leadership group for one product: a Product Manager with the design, development, and marketing leads. It owns the vision, the strategy, and the funding of each team’s scope, agrees quarterly outcome targets with each team, and reviews results with them every week.
• Developing people in their craft. Chapter leads were line managers for a discipline. In ZeroBlockers the design and development leads on the Product Team own hiring and careers. Enabling Teams, one or two senior practitioners per discipline, coach Stream Teams, but they do not do the work for them, as they would in a Center of Excellence.
• Sharing knowledge. Guilds were voluntary communities of interest. ZeroBlockers keeps communities of practice and adds playbooks that a team can use without asking anyone.
• Shared capabilities. The paper’s operations team was “building the road to production.” ZeroBlockers applies the same idea more widely. When the same request shows up across several teams, from deployment to legal review, the common cases become a self-service product run by an Internal Product Team that treats the Stream Teams as its customers.

Keep long-lived teams with a mission, craft communities, and the engineering support that makes autonomy usable. A small organization does not need every ZeroBlockers team type as a separate group. Assign the responsibilities at the scale you have.

In Lee’s account, the matrix fragmented engineering accountability: chapter leads managed careers and “had little responsibility beyond” that, so “there was no single person accountable for the engineering team’s delivery.” A disagreement inside a squad could need three engineering managers to settle it.

ZeroBlockers also places careers with leads who sit outside the delivery team, so the criticism deserves a direct answer. There is one development lead for the product, where Spotify had a chapter lead for each specialty. That lead sits with the Product Manager in a single Product Team that owns the funding and runs the weekly review, which gives a disagreement one place to go. The Stream Team as a whole is accountable for its outcome.

Two of his other warnings apply as well. He says Spotify’s agile coaches “were not accountable for anything.” ZeroBlockers measures its Enabling Teams on whether teams choose to use them and on the capability those teams gain. He also warns that “every responsibility a team cedes to increase its focus becomes a new cross-team dependency.” That is the risk with any internal service, which is why ZeroBlockers makes adoption of internal products voluntary and treats teams routing around one as a signal to redesign it.

Another of Lee’s causes is that Spotify “fixated on team autonomy.” He reports that the paper was meant to be the first of a series and that “the parts on alignment and accountability were never completed.” In his account, “Spotify did not define a common process for cross-team collaboration.”

With AI, teams ship faster, so teams with different priorities ship more conflicting changes before leaders notice. The strategy has to reach the people who choose the work, with enough of the reasoning that they can settle routine tradeoffs themselves.

ZeroBlockers builds alignment into the weekly routine. The Product Team shares its strategy with the reasoning attached, teams propose outcome targets against it, and a 30-minute Weekly Product Review looks at each team’s metrics, what it learned, and the decisions it needs.