Autonomy requires three different types of Alignment
Few people these days would honestly argue against empowerment, against giving employees more autonomy. It is, as Daniel Pink famously wrote, one of the three primary motivators for knowledge workers, along with Mastery and Purpose. General Stanley McChrystal describes the need for autonomy:
… [it is] when the velocity and volume of decisions needing to be made so exceed the capabilities of even the most gifted leaders that empowerment of those on lower rungs is simply a necessity.
But it would be naive for a leader to simply grant more autonomy, without giving thought to the conditions under which autonomy leads to better, faster decision-making and better results - alignment.
I first heard about the relationship between autonomy and alignment when I read Stephen Bungay’s book, the Art of Action. In it, he describes the insights of Field Marshal Helmuth von Moltke that autonomy and alignment are not at opposite ends of a spectrum, but two axes on a grid.
“The more alignment you have, the more autonomy you can grant”.
If you have:
Low alignment and Low autonomy, you get confusion, because people are being told what to do (and sometimes how to do it), often without knowing why. They follow orders and tend not to question authority.
Low alignment and High autonomy, you get people deciding for themselves what to do and how to do it, but going in different directions, or not deciding much of anything if they’re just not used to making decisions.
High alignment and Low autonomy, you get command-and-control; people waiting to be told what to do, with ‘expertise’ in the hands of the most senior people in the hierarchy.
High alignment and High autonomy, you get people all moving in the same direction, and figuring out themselves how to achieve the stated objective.
Henrik Kniberg created this lovely little cartoon to illustrate these different conditions.
But what do we mean by alignment?
Alignment refers to three different things:
A common understanding of goals and objectives; everyone knowing what needs to be achieved so that they don’t need to be told what to do every day, and can make rapid decisions without seeking approval, in order to meet the objective. It is also the differentiation between, on the one hand, customer needs and organisational objectives, and on the other a list of things a team has to do. It is the former that is more important; like the reason we need to get across the river at all. If we all understand that, we’re much more likely to build a suitable bridge.
Standards and agreements (rules) that constitute the boundaries of the autonomy. In essence, what do people / teams have autonomy over, and what do they not. What things can they decide for themselves and when do they need to adhere to standards or working agreements, or consult others. For example, can a team decide how to estimate and forecast their progress? Can they decide their own sprint cadence? Their own working hours? Can they set up and run their own environments, purchase their own software licences? Clarity over where the autonomy starts and ends is essential to rapid, high-quality decision-making. Establishing clear rules for who makes what decisions can help in this regard.
Knowledge of how to do their job. Are they technically competent? You cannot give autonomy to people who you cannot trust to get the job done. You cannot tell people to build a bridge if they do not understand bridge-building materials and techniques. If you run an agile shop with autonomous teams deciding their process for themselves without an understanding of agility, they are likely to make decisions that are not in the interest of maximising agility. This is where ‘Scrum-but’ originates and thrives.
In his book Turn the Ship Around, L. David Marquet writes
“… as control is divested, both technical competence and organisational clarity need to be strengthened.”
His leader-leader model is about “giving employees control over what they work on and how they work. The two enabling pillars are competence and clarity.”
Autonomy has distinct advantages for agile teams. It helps to motivate people and it helps get things done faster when the team don’t have to wait for someone else to approve minor decisions. But an organisation looking to increase the level of autonomy, also needs to ensure that those granted more autonomy all understand their goals and objectives, the boundaries of that autonomy, and that they are all well-trained in how to get the job done.
Only in that way can people be granted more autonomy.
Ensuring alignment is not as easy as it sounds. It requires a conscious effort on the part of an organisations leaders, sometimes to the detriment of what they have been doing for years.
In Team of Teams, Gen. McChrystal described how his Task Force demanded a disciplined effort to create a shared consciousness, making as much information as widely available as possible, in direct opposition to normal military “need to know” doctrine, and built processes for sharing that information. He redesigned physical work spaces and built trust between teams by using embedding and liaison programs to cut across organisational silos. He initiated the disciplined practice of empowered execution whereby operatives could make instantaneous decisions based on all the available information, without waiting for approval from above.
Under the old way of doing things — just tighter and faster - his task force improved their number of raids from 10 to 18 per month. After changing the organisational model, granting autonomy and creating a shared consciousness, the task force were achieving 300 raids per month with minimal increases in personnel and funding. And the raids were more successful.
In conclusion, it is insufficient for leaders to grant autonomy in the hope it leads to better results; it probably won’t. They still need to work hard to ensure that technical competence and organisational clarity are optimised.
Art of Action, Stephen Bungay
Turn the Ship Around, L. David Marquet
Team of Teams, Gen. Stanley McChrystal et al
Drive!, Daniel Pink
This article was originally published on Medium.com