I
n my previous blog post I talked about Engineering Culture and how important it is to embrace the fact that you need to behave like a software company. In this blog post I want to dive a little bit deeper in to an aspect of the pillar “Empowering Operating Model”.When it comes to the operating model of a software company I truly believe in autonomy, putting responsibility and decisions close to the place the actual work is done. That means that the software engineers and other people that do the real work need to be empowered to make decisions. And with the power to make decisions, they also need to be responsible and accountable.
To implement this concept, I really like the theories of value stream aligned teams, platform teams and end-to-end responsible teams. Organizing teams around a value stream and put the roles and people in the team that are necessary to do the job is key.
However, when you have a number of different teams and a number of different products and are somewhat bigger, full autonomy is not ideal. You might end up with 5 different software stacks or all of a sudden have a multi-cloud strategy. In the picture below, that is from Henrik Kniberg at his time at Spotify, describes this problem magnificently. The term. “Aligned Autonomy”.
As you can see in this picture it is all about finding the right balance between alignment and autonomy. Too much alignment and everyone does exactly what you say. Every decision needs to have an approval and you get what you want but not what you need (mmm.. nice lyrics from Coldplay here
On the other side of the spectrum there is only autonomy. Everybody is doing as he or she likes. The team does what seems right at the moment. Organization goals, standard etc. are not needed because… autonomy. The ideal combination of the two is “Aligned autonomy”. Clear guardrails, organization goals, vision and purpose so that teams and people can make their own decision that are in line with the bigger picture. But, this is easier s from Manager side, from team side
I often get questions or remarks about this. What is a good way to achieve this. Teams often feel that they are constraint. They play the “too much alignment” card. Managers and C-Level often ask me hoe they can get some level of insight and (sorry for the word) control about decisions that are made. A while ago a colleague and PO cam e up with some nice idea and when I combined that with some ideas I had earlier, this might be a way to achieve some aligned autonomy.
Decision type 1 and 2
As said, this idea is from a colleague that struggled with the alignment in his team. To make it clear for anybody when was good time to ask for some “approval” or at least seek for some alignment, he introduced the Decision type 1 and Decision type 2. Feel free to find a sexier term.
Decision type 1 is all decision that can be reverted within 1 or 2 weeks or are very cheap (less that you cost in 2 days). A simple tool, a package that you use, a license that you buy, a conference you visit. Don’t ask, just do. Make the call. Don’t get delayed.
On the other hand there is decision type 2. Decisions that are not easy to roll back, or that need some thinking upfront. Which cloud are we going to choose, which tech stack will be the standard, what tool will we buy ? Those decisions need to be discussed, or at least ben made visible to management and vice versa. When management decides something, they need to communicate that.
But what is a good model here? A while back I found this model from Martin Fowler. He talks about the advice process and how you can streamline this without making specific people the bottleneck.
Summarized this will be as follows:
- Someone has an idea/decision of type 2
- You discuss with another SME
- You record your (pre-)decision in an Architectural Decision Record (ADR)
- You discuss in a forum with like minded people
- You adjust where needed and decide
Summary
By making it clear that there are different type of decisions and surround that with some guardrails, it is easier for people to understand and embrace the concept of aligned autonomy. When you further implement the advice process as described by Martin Fowler, you give teams a great start to be more autonomous without losing touch as management and vice versa.
Source link