Also available in fr
May 31, 2023
13 min read
Over the years, I've met and observed teams that were competent and yet failed: working on the wrong priorities, sometimes working on the right objectives, but with unsuitable solutions, sometimes working with no priorities at all.
The root cause of these problems can be articulated around these 3 words: autonomy, alignment, and context.
If these words seem relatively simple to understand, in practice, their implementation is not trivial.
How do you ensure that everyone in a team is trying to solve the same problems? What does autonomy mean within a group, and what are its limits?
Perhaps you've heard the term "empowered teams"? And thought it was yet another new consultant concept?
The expression gained popularity via the book Empowered by Marty Cagan. In simple terms, an empowered team works on a problem to be solved, as opposed to a feature team which works on a list of functionalities (the famous roadmap).
We also speak of a team that prioritizes outcomes (impacts) over outputs (deliverables).
The first thing I'd like to stress is that this isn't just a topic for product managers. Any senior person in Engineering should be involved in decision-making, for example :
I'm writing this chapter for any technical leader looking to create impact. To do this, we'll see that creating autonomy, alignment and knowing how to communicate the context are levers for achieving this.
Here, as a Tech Leader you can be in two situations, but often in both at the same time:
To tackle this subject, I'm going to start from a drawing by Henrik Kniberg about alignment and empowerment. "Empowered teams" being the teams in the top right-hand corner.
This drawing is part of a keynote given in 2016 that I invite you to watch.
In this keynote, it's about a group, whose goal is to cross a river to settle on the other side of the bank.
The lower-left corner shows a group with little autonomy, no alignment and no precise directions. No one in this part of the quadrant has taken the initial problem of crossing the river personally.
The symptoms of such an organization in a technological context :
What can be done about it?
It's a tough job on this part of the quadrant. Even before talking about autonomy, the first issue will be to get people to agree on a common goal. The role of a tech leader is to get close to the business, or its closest representative, and understand the issues that need to be addressed. In this type of organization, the business is often far away and/or difficult to access. Breaking the distance can be difficult, and is not part of the company's culture. Technique and "best practices" are likely to be the least of your worries in this context, as the importance of connecting Engineering to the business is paramount.
If we move to the right, we come across organizations made up of individuals or groups of individuals, each of whom has defined objectives, but all of which are different.
If the group's objective is to cross a river, everyone is working on different things: some are growing vegetables, others are fishing, and a few leaders are wondering whether someone is working on crossing the river.
There's a misunderstanding of autonomy here. Autonomy does not mean independence. A team that decides its priorities in its own corner doesn't make an impact, or does so by accident, and this success is hard to repeat many times over.
And this doesn't mean that individual groups can't be highly effective. Unfortunately, impact is measured in global terms.
The symptoms of such an organization in a technological context:
What can be done about it?
The observation is fairly similar to the previous one, but the work will be less arduous due to the highly entrepreneurial nature of the company. Here, the tech leader will be able to rely on committed teams. We'll need to work on alignment.
But let's define this notion a little better.
Alignment defines the ability of a group to all seek solutions to the same problem.
Example: Objective: A European company decides to enter the US market.
Each team will seek to contribute to the same objective.
However, in the drawing in the upper left corner, we can see a clear alignment without autonomy. One or more leaders can decide exactly what needs to be done to achieve an objective.
The leader explicitly asks to build a bridge across the river.
This mode of operation can be very effective, especially on a small scale with a visionary leader. But scaling up can cause problems, as the visionary leader can't spread out across the company and follow all the decisions.
On several occasions, I've observed companies with very good leaders, but with great difficulty in managing rapid growth. They recruited people who were more junior than they were, more capable of carrying out a task than making decisions. These people then failed to scale up in the time available.
Symptoms of such an organization in a technological context:
What to do about it:
If you're a tech leader, one of your responsibilities is recruitment. You have to recruit people who are better than you in certain areas. You have to learn to share your legos.
The second important thing is to get out of the vicious circle:
At stage 2, you have a major responsibility for coaching/mentoring to educate and provide the necessary context for more effective decision-making.
If you're a tech leader, but you're in a situation where the work is delegated to you, you'll need to show that the team can be autonomous. To do this, two things are important:
In our example above, a group that chose to build a catapult to hurl individuals to the other side would be showing a certain lack of understanding of the effect of gravity on human bodies :) Hopefully, the initiative would be stopped.
Don't be the one to suggest the catapult.
Bad: there are too few of us in the team, so we can't finish the project on time.
Good: given the size of our team and our current speed, I've decided to cut back on some of the functionalities to meet the deadline.
Bad: We're drowning in support. The team can't deliver project A on time.
Good: We carried out a support analysis and noted a sharp increase in support cases linked to a bug in a recent feature. We decided to assign one person for a week to fix this bug and regain velocity on project A.
Before I talk about the last quadrant, I need to talk a little about the "context".
"Lead with context, not control" is a quote you'll find in the excellent book "No rules rules" by Erin Meyer and Reed Hastings. For a person or a group to make a good decision, they need to know the whole context.
If we go back to our group, which has to cross a river, we lack the context to propose initiatives.
Maybe we have to cross the river to find food. In which case, why didn't we decide to settle on this side?
The leader failed to mention that we're in the territory of another tribe who has asked us to leave before autumn.
Okay, and if the leader had told us that this tribe wasn't against trading with us after all, having a bridge would probably be more interesting in the future than just building a boat.
Having the context allows you to make the right decisions.
And in the corporate world, there are plenty of occasions when you neglect to give the full context, sometimes for the sake of speed, sometimes to protect your team, sometimes because you've forgotten. But without context, you can't expect people to make the right decisions. Context gives you the constraints that will enable you to propose the most appropriate technological solution.
In this corner of the quadrant, the objective is clearly defined, such as crossing the river. The constraints are known, and each group is invited to contribute to the common goal.
In theory, this is the most efficient type of organization, especially at scale.
I'd like to point out two pitfalls at this stage:
It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.
You have to accept the unexpected, accept that the solutions you come up with may not be the ones you originally imagined. If a group suggests crossing the river with a boat or a tunnel, or has spotted a ford a hundred meters downstream, it may be different from what you had in mind, but it may be more effective. Accept that not everything is as it seems in your head.
BUT, if there are several groups working, one on building a tunnel, another on building a bridge, another on building a boat, you've got a problem. If everyone is working on the same problem with different solutions, that's also a form of misalignment.
Again, autonomy doesn't mean independence, and there needs to be regular discussion around the initiatives launched to ensure overall coherence.
Don't be the one working on creating a tunnel while everyone else is trying to build a bridge.
Certain methodologies, such as OKRs for example, help to materialize this periodic discussion.
Objective: The product should enable the acquisition of 10,000 prospects in the USA.
Quarter 1 initiatives:
Quarter 2 initiatives:
The coherence of the initiatives is linked to a discussion at the beginning of the quarter of what each group has come up with to contribute to the initial lead acquisition objective.
This step, designed to ensure the coherence of initiatives, can be found in many methodologies:
I must stress once again that autonomy does not mean independence. If, during these discussions, a decision is made to favor a bet, and it's not the solution you had in mind, too bad but you have to commit to this decision. This is the famous "disagree and commit". And that doesn't take anything away from team autonomy. Teams can be the driving force behind initiatives to solve a given problem, but in the end, we'll be looking for alignment. Otherwise, we're back in the bottom right quadrant.
If your aim is to create more autonomous product teams, you may come up against the following difficulties:
These 3 subjects create deadlocks.
A good PM and/or Tech Leader will be reluctant to join an organization where he/she feels a lack of autonomy.
Management will find it hard to trust a team that they don't feel is business-oriented enough.
Top management who don't have confidence in a team will continue to demand a high degree of predictability in development via detailed roadmaps.
As a Tech Leader, you have your hands on several levers that I've already covered in the first chapters:
The aim of all these actions is to increase the trust placed in Engineering's actions. This confidence will be transformed into the delegation of autonomy.
Would you say that you have all the constraints in mind for your current projects?
How much time do you spend explaining the context to the people who work with you?
What is your team/department's objective for the year?
How are you contributing to this objective this quarter?
This blog post is part of the book Impactful Software Engineering. Feel free to read the other chapters.