Is Kniberg’s Aligned Autonomy matrix still relevant?
You've probably heard of Henrik Kniberg. He worked at Spotify around 2012 when they were pushing the boundaries of scaling agile and experimenting with new organizational designs.
At the time, Kniberg created an interesting graph that became known as the Aligned Autonomy matrix. He used this graph to describe the relationship between the alignment and autonomy of teams. The graph symbolized the fairy dust that was sprinkled over the teams and made the "Spotify-way" (Tribes and Squads) work.
The question we ask ourselves in this article is, "To what extent is Kniberg's graph still relevant to improving the performance of large-scale agile team collaboration?".
The Aligned Autonomy matrix
Team autonomy is on the horizontal axis and team alignment is on the vertical. According to Kniberg, Autonomy says something about the extent to which a team can make its own decisions about the work they do. Alignment says something about "having a common purpose". Looking at the graph it is clear that management plays a role in connecting the two.
Alignment is having a shared purpose. When teams are aligned, all teams are pursuing the same goal (as per Kniberg's example, the goal of crossing the river). Alignment is about getting the noses in the same direction, keeping the frogs in the wheelbarrow.
Kniberg assumes that the level of alignment between teams determines the degree of autonomy of the teams. Management is responsible for laying the groundwork for alignment. In other words, managers must properly convey the "why". If the purpose is clear, then the teams will be better able to take responsibility for delivering the right customer value. He calls this "Aligned autonomy."
For Kniberg, autonomy is linked to alignment, as if they are connected with a rubber band. He sees team autonomy as a consequence of alignment around a common purpose. The more a company succeeds in sharing a common purpose, the more autonomy management can give to teams.
In Kniberg's view, autonomy is "given" to teams by management. Autonomy is about being allowed to work independently, rather than being able to work independently.
While developing Org Topolgogies, Alexey Krivitsky and I have discovered new insights about Autonomy and Alignment that are different from the Autonomy and Alignment Kniberg was talking about.
Autonomy in the now
Trying to create autonomous teams has become commonplace in the majority of organizations that adopt Agile. The management discussion on team mandate has shifted toward determining the degree to which teams are self-organizing, self-directing, or self-governing. We no longer question whether teams should be more autonomous or not.
With the introduction of a plethora of scaling frameworks, the emphasis in recent years has been on a particular aspect of autonomy: speed. The more autonomous a team is, the faster that team can deliver a product backlog item. Teams can be made faster by learning skills, automation, changing team composition, and so forth.
On the Org Topologies map, making teams faster is a horizontal move. A lot of progress has been made in making teams faster. Thanks to the work of Scrum Masters, many teams moved from A2 to A3, from incomplete teams with dependencies to (more) autonomous end-to-end teams.
Autonomy is determined by the completeness of the skillset a team needs to have in order to deliver end-to-end value. The more dependencies, the less autonomy. Similarly, we could identify the skills a team lacks to deliver a "Done" product. The more missing skills, the less autonomy. Instead of talking about autonomy, we prefer to talk about in-team collaboration (depth of cross-functionality).
Autonomy is determined by the completeness of the skillset a team needs to have in order to deliver end-to-end value.
Speed is not enough
Fast teams are a good thing, but worthless if they cannot deliver value. Who would want teams that can deliver products really fast that nobody wants? In other words, the teams need to understand what value is. And the "Kniberg question" here is: Can this be achieved through alignment?
When we started describing Org Topologies, one of the many titles we experimented with for the vertical axis was "Product Centric Alignment." However, we found that "Alignment" did not express deeply enough what makes the higher archetypes (B and C types) so different.
By improving alignment around the "why" we can motivate people and purposefully develop the product in a unified direction. But only aligning on a common purpose is not enough. To deliver value we need to align on a detailed level about the work itself, and across teams. The default response to solving this kind of alignment problem is to add coordinators to the mix (external coordination). But unfortunately, "more people" means more complexity!
Why is alignment on work necessary?
Can we create "Built-in Alignment"?
Yes, we can!
Built-in Alignment (or Alignment by design)
The coordination need is a symptom of an ineffectively designed organization. To create an adaptive organization where alignment is effortless and coordination seamless, we must look at how to make teams collaborate instead of how to make them align. We want to create cross-team collaboration instead of cross-team alignment. And to do that properly, we need to (re)design our organization with the value to be delivered at the heart of it.
Building adaptive organizations is done with cross-functional autonomous teams who know and understand everything about the customer needs.
If everyone knows everything and can do everything, it is starting to make so more sense to work in an equal cadence (Sprints) on the same goals (one product Backlog at the whole product level and a common Sprint Goal across teams). Alignment on the work is done by the people doing the work. It is not a separate activity, it is part of the work and is called Refinement. In this scenario, the teams will have no blocking dependencies. Instead, by sharing the same Sprint cadence and Goal, they will see opportunities for collaboration. (For example: changing the same piece of code, or writing a product policy together).
This requires organizations to experiment with letting groups of teams work as a team. These teams will need to develop a broader understanding of the product. Their focus will move upward from the feature level to the customer journey level.
If this sounds too utopian, use the higher archetypes as a "perfection vision" for your transformation, and move your organization incrementally in this direction. You can grow gradually by trying out practices that are common in the higher organizational archetypes, as we described in this earlier article on organizational cohesion.
In larger organizations, we create Business Value Areas, where teams are grouped as teams of teams by specializing in a sub-product, customer journey, or product domain (in the case of financial services, an example would be: retail banking and business banking).
There will always be some kind of specialization. However, we must strive to make it the right kind of specialization (on customer value) and at the right level (as broad as possible). Both broad product knowledge (understanding customer value, vertical axis) and a large skillset (autonomy, horizontal axis) reduce specialization. And that's what we want, because specialization creates coordination needs, and (external) coordination makes us less adaptive.
This document is written in the present tense. It is not unthinkable that Kniberg's views have changed since 2016 when he was promoting his learnings from 2012. Nonetheless, Kniberg's original interpretation of autonomy and alignment still has value. It has become commonplace and has been integrated into today's servant leadership concepts: Management needs to create an environment for teams to be able to perform at their best.
More information can be found at www.orgtopolgies.com, or invite us for a coffee.
© 2023 Roland Flemm and Alexey Krivitsky