In 2014 Henrik Kniberg posted an article describing how a small music player company in Sweden organized some of their development teams. It’s a nice article describing how Spotify was organizing at the time. The names Spotify came up with for the various dimensions of the organizational structure are cute – “Tribes,” “Guilds,” “Chapters.” Somehow, however, this interesting anecdote became a rigid prescription that many large corporate IT organizations thoughtlessly copy, often (mis)guided by one of several large consultancies who flog the Spotify model as a key component of their clients’ Agile org design. In many cases, these consulting charlatans even mis-identify the Spotify model as a “methodology,” further inflating expectations of its potential value and impact.
There’s a lot less to this model than these consultants would have you believe. It is a useful example to inform how companies rethink how they organize; but it is not a prescription for every organizations’ optimal design. An IT organization that thoughtlessly implements Spotify’s org structure will fail to optimize the design of their organization, and as with the many prescriptive, design-up-front Agile recipes and frameworks, mindlessly adopting any prescriptive design is inherently anti-agile.
A framework is a collection of patterns, but no framework contains all the optimal patterns for any complex organization in the real world. The objective of becoming an Agile organization is mastering the sensing, experimenting, thinking, and learning adaptation cycle. Implementing the patterns that are optimal for your unique environment and goals requires thought and tailoring. Agile also means evolving and adapting continuously, and indeed, Spotify itself, being an Agile organization, has grown and adapted beyond this published version of “The Spotify Model” as illustrated in this post. Not convinced? Watch the video: at around the 3-minute mark, Kniberg himself says, “This culture description is really a mix of what we are today and what we want to become in the future.”
I have no objection to Spotify organizing in whatever way made sense for them, and I celebrate them for continuing to evolve and adapt their organizational design. But let’s see this “model” for what it is: another permutation in the decades-old debate about horizontal-dominant versus vertical-dominant matrix organizational structures.
Horizontal vs. vertical dominance
Vertical-dominant structures (common in traditional IT shops) are aligned along functional siloes (developers, testers, project managers, etc). Long before Agile, many organizations realized that optimizing for job functions meant de-optimizing value delivery. So, horizontal-dominant matrix structures became more common, aligning reporting and incentives to project teams, work cells, or product groups. Early on, people realized that the soft or dotted-line dimension of the matrix, though deliberately de-optimized, still deserved deliberate support and focus to enable important organizational objectives. Models and patterns for supporting the soft or dotted-line dimension of the matrix became well established over time.
The Spotify model is one instantiation of organizational patterns (with cute names!) for the strong and weak dimensions, (or if you prefer, the vertical and horizontal axes) of a matrix organization and cross-dimensional goals they wanted to support, but it isn’t a prescription for the optimal design for every organization.
For example, should hard-line reporting align to the “chapter” or the “tribe”? Don’t blindly adopt Spotify’s (former) answer as your own. Don’t assume every part of the organization should have the same design. And as Spotify’s real experience illustrates, don’t assume the best design today will be the best design two years from now.
Let’s get real. There are many patterns and options for replacing functional siloes with more effective organizational structures, and many designs for retaining the strengths of functional alignment after we move to product alignment. Is your company a little Swedish music player developer? No? I thought not…
What Spotify produced isn’t in any way wrong-headed or unsuccessful. There are solid patterns and they gained great benefits from their “model” through its evolution and iterations. But recognize that there are equally effective alternative models and patterns. There is a dangerous trend of dissimilar organizations adopting the Spotify model as a one-size-fits-all design and mistaking it for a static or permanent state, when it hasn’t even remained static or permanent in its original form at the firm for whom it is named.
So, perhaps rather than accepting some random consultant’s voluble PowerPoint solution derived from an old article describing an abandoned model from a dissimilar firm, have a thoughtful conversation among leadership about what objectives your firm is optimizing for. Consider a range of viable patterns, run some experiments, and find your own best-for-now organizational design, then continue to learn, evolve and grow.
And by all means, please publish a nice article describing your model and what you learned!