“Aligned Autonomy” is a concept that aims to strike a balance between autonomous decision-making and alignment with organizational goals and values.
The concept suggests that employees should have the freedom to make decisions and take actions autonomously, while also being aligned with the overarching objectives and principles of the organization.
"Aligned Autonomy" as a concept has been referred to in various sources, to name a few:
“Drive: The Surprising Truth About What Motivates Us” by Daniel Pink
“Turn the Ship Around!” by L. David Marquet
“Empowerment and Organizational Development” by Bernard Bass and Bruce Avolio
Another source is Henrik Kniberg, a famous Swedish agile coach and org consultant. Henrik coached at Spotify around 2012, where he described their unique scaling model, initially proposed by Joakim Sundén and his colleagues. Henrik created a cartoon series that sparked worldwide interest and became known as the "Spotify Model."
As a part of explaining how Spotify's ways of working were unique, Kniberg drew an image that describes the special relationships between the teams and management at Spotify:
This image describes the relationship between team alignment and autonomy as a two-dimensional matrix. Team autonomy is on the horizontal axis, and team alignment is on the vertical axis. According to the matrix, autonomy marks the extent to which a team can make decisions about its work. Alignment symbolizes having a common purpose. Looking at the matrix, it is clear that management plays a role in connecting the two.
Key insights to derive from this matrix:
alignment and autonomy are not different extremes of the same continuum
more alignment doesn't mean less autonomy
we need
both (alignment and autonomy) to achieve a high-performing organizational setup.
In this article, we ask ourselves: to what extent is the Aligned-Autonomy matrix relevant to multiple agile teams collaborating at scale?
Alignment (for Purpose)
Alignment is having a shared purpose. When teams are aligned, they pursue the same goal (as per Kniberg's example, "crossing the river"). Alignment is about getting the noses in the same direction and working toward a shared purpose.
Management is responsible for laying the groundwork for alignment. In other words, managers must properly convey the "why". But without autonomy given to the team(s) to solve the challenges the way they feel like, alignment itself is not enough to drive performance
Autonomy (for Agency)
For Spotify and the way other great companies work, autonomy is a degree of freedom the teams have to act within the aligned purpose. Management "gives" autonomy to teams.
These days, a common term for this phenomenon is an agency - degree of freedom. Intelligent agents are given the freedom to act independently for the benefit of a shared purpose.
While developing Org Topologies™, we have discovered new insights about Autonomy and Alignment that are different from the Aligned Autonomy model we were discussing.
Dimensions of Autonomy
Trying to create autonomous teams has become commonplace in most organizations that want to become agile for real. The management discussion on team mandate has shifted toward determining the degree of self-organization. They no longer question whether teams should be more autonomous or not. The question is where that boundary lies.
Richard Hackman, Edgar Pierce Professor of Social and Organizational Psychology, provides a powerful illustration of the options organizations have:
By "autonomy of teams," most organizations mean the second column per Richard Hackman's model above. It is the bare minimum of self-management. Teams must be given the authority to "executing the task" and "monitoring and managing work processes." There is no self-organization when these two permissions are not granted to the teams by management.
Very few organizations have tried the next level of "self-designing teams," where the teams not only execute and monitor but also "design the team and its context." We have experienced these experiments within the LeSS-inspired adoptions and can confirm that this adds tremendously to teams' agency.
Designing for Autonomy in a Multi-Team Environment
No one will deny that an individual team's speed is an interesting indicator of organizational performance. The fewer blocking dependencies a team has, the more autonomous it is. With autonomy comes the ability and speed to deliver product backlog items end-to-end.
On the Org Topologies™ map, making teams faster is a horizontal move. Teams can be made faster by acquiring skills, insourcing skills, removing dependencies, cutting the need for certain skills via automation, etc.
In a multi-team environment, such a change is not a single-team transition but a coherent transformation of the entire ecosystem. In the picture below, three teams have merged to create an A3 Team with no dependencies on other teams and, hence, possesses a high degree of autonomy. It can complete features in a fast-flowing end-to-end manner.
Note that such a transformation is an org design change and not simply a policy or process change.
Designing for Alignment in a Multi-Team Environment
In the same way, creating autonomy in a multi-team environment is not a mere manager's blessing: "thou shalt now be all aligned".
Imagine a big-room planning event (something similar to Product Increment Planning in SAFe, for instance). The teams are gathered for a few days. They are presented with a top-down strategy. The product board is filled with cards of different sizes and values. Teams are facilitated to identify mutual dependencies. As a result, the dependency strings are attached among the cards, and there is a detailed three-month upfront plan for dealing with that work as a Release Train. Managers and coordinators are assigned to control the plan's execution and track the dependencies. The teams are now free to go home and start working.
Are those teams aligned?
From our point of view, yes, they are aligned. There is a shared purpose and a common plan.
Will those teams be coordinating?
We'd say yes. Cross-team meetings will be held to compare the plan with the actual state and make necessary course corrections. As a result, the teams' work queues can slightly change.
Are those teams collaborating on the true meaning of this word?
From our perspective, not really. The whole idea of the detailed plan, upfront identified dependencies, and external coordinators is to avoid cross-term collaboration, which might be a valid thing to do in a given organization.
But what's the conclusion we can draw from this example:
Alignment doesn't guarantee collaboration!
To create a truly agile organization where change of direction is easy and fast, we must focus on enabling teams to collaborate, not simply aligning them. Alignment is a prerequisite for collaboration:
Alignment is needed but not sufficient prerequisite for cross-team collaboration.
Multi-team collaboration requires much for than just alignment to happen. Org Topologies offers a model of how to think about collaboration at scale. It identifies four distinctive levels of the team's focus:
These four levels are crucial to consider for collaborative org design.
As the teams' scope of work expands from task focus and feature focus (Y- and A-levels) up to business areas and whole business focus (B- and C-levels), teams' scopes of work start to overlap. Teams now have a mostly shared scope of work and can join forces to attack big common challenges:
A shared scope of work won't happen because of a manager-enabled alignment. Such rich collaboration results from deliberate management actions and thoughtful org design.
Bringing It All Together: Aligned Autonomy at Scale
As we've analyzed, neither autonomy nor alignment, not even both, are enough in a scaled, multi-team environment. One needs to design an organization explicitly for collaboration.
It is the space where highly collaborative practices such as Multi-Team Product Backlog Refinement and Joint Sprint Review become the norm. Refer to Elevating Structures™ to learn more about designing collaboration at scale.
Such an organizational design requires organizations to experiment with abandoning the idea of Independent, autonomous teams and instead creating cohesive, interdependent multi-team units: a team of teams.
At Spotify they created a true space for collaboration with many cross-team structures and meetings:
Over time, through practice and tight collaboration, a team of teams will develop a broader understanding of the product. They will start to think holistically from the business and customer perspectives and realize that they need each other to make big things happen faster in the product. The collaboration will only grow from that moment on.
We need more than autonomy and alignment at scale to create a truly collaborative, agile organization.
This might sound utopian but don't worry. This is a "perfection vision" for your transformation. You can aspire to it and gradually move your organization in this direction. You can also grow gradually by trying out practices from the Elevating Structures™ set.
At larger scale (hundreds of teams) there can be multiple "teams of teams", each specializing in a business domain and a set of cohesive customer journeys. In the case of financial services, there can be, for instance, a team of teams for Retail Banking and a team of teams for Business Banking
There will always be some kind of specialization at a larger scale. 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 (scope of work, the vertical axis) and a large skill set (scope of capabilities, the horizontal axis) reduce specialization and enable collaboration.
We want that because teams must rely on external coordination with a narrow scope of work and a low scope of capabilities. This makes them less autonomous and less aligned.
© Roland Flemm and Alexey Krivitsky
