“Control leads to compliance; autonomy leads to engagement.” – Daniel Pink, American Author
Dear all,
I am traveling this week. As a consequence, my writing time is constrained. So, I will just sketch out a train of thought that occurred to me over lunch.
Everyone wants their product to be able to respond to market and business needs and improve or create additional business value within a reasonable timeframe.
To ensure that, most companies resort to a more or less elaborate planning process.
A planning process is required because, in particular, industrial organizations, due to their often siloed specialist structures, typically harbor many dependencies.Dependencies, in turn, create delivery risks. And, technically speaking, every removed dependency doubles the chances for in-time delivery (more on thishere). Therefore, planning likely helps.
As most industrial companies naturally plan to optimize resource utilization in production, planning software production also seems logical.
This results in the assumption that an improved planning process will lead to better and more timely product or feature delivery.
For this reason, many organizations develop scaling planning models and invest a striking amount of time and manpower in managing and refining these planning processes.
And these processes work to a degree. Product delivery usually becomes more predictable – but at the cost of business agility.
Triggered by yet another discussion of a particularly long planning cycle this morning, I started to ponder the alternatives over lunch in my favorite local cafe.
What would be required to react to an opportunity without resorting to an elaborate planning cycle? Using what is known as the „Opposite Thinking“ method, I tried to imagine an alternative reality.
Minimizing planning would require teams capable of autonomously adapting or building complete features or products.
To be able to do so, the team’s structural dependencies should be minimized.
In other words, an autonomous team, first and foremost, needs the x-functional resources and capabilities to create products or features independently.
To minimize dependencies further, it is essential to also decouple the technology infrastructure as far as possible. This infrastructure should be easily accessible to product or feature teams through well-defined interfaces that do not create additional dependencies by requiring other teams to develop customizations or adaptations.
To ensure that individual teams create products or features that drive value for the larger organization, the teams need to be aligned on shared organizational goals and outcomes.
Therefore, to increase business agility and reduce the need for planning, it takes aligned and enabled autonomous teams.
So, instead of focusing on optimizing planning (with typically diminishing returns),wouldn’t it be worthwhile to invest in enabling and granting more team autonomy?
I’d be interested in your views!
Henrik Kniberg’s videos on
Spotify’s Engineering Culture
address Alignment and Autonomy, among other topics, and are absolutely worth their combined 25-minute viewing time!
Is Kniberg’s Aligned Autonomy matrix still relevant?
Org Top[ologies’ Roland Flemm asks himself: To what extent is Kniberg’s graph still relevant to improving the performance of large-scale agile team collaboration?
The Power of GrantingTeams Autonomy
Correlated’s Diana Hsieh covers what team autonomy is, why it’s important, and what it looks like when implemented correctly.
Saluti Dall’ Alto Adige
Godehard