Decision-Making in Autonomous Teams: A Step-By-Step Guide
Why do we need this?
One of the most difficult aspects of a leadership role is striking a balance between giving direction and encouraging teams to make decisions for themselves. While experience may suggest that a particular solution is likely to be the most effective, it’s unlikely to be successful unless the team commits to it. There’s also a chance that better solutions exist, and given the right environment, teams will often discover these themselves. Building that environment and providing their team with just enough direction is where a tech lead really adds value.
Let the team decide is a deceptively simple mantra: Without suitable direction, decision-making sessions can become chaotic, sometimes even adversarial, affairs. This presents more confident participants with an unfair advantage, and ultimately the decisions themselves suffer. One of the reasons that teams struggle to reach agreement is that by simply championing different approaches, there is too much left open to ambiguity: the problem being addressed, the criteria against which potential solutions should be assessed, as well as the specifics of the solutions themselves. If participants have already invested their time and effort in devising these solutions, reaching consensus becomes even harder.
So what can we do about it?
Just as in mathematics it is only necessary to follow each step of a theorem’s proof in order to be convinced of its validity, consensus on technical decisions too can be achieved incrementally. The following steps can help break down the decision-making process, building the team’s consensus along the way:
Step 1: Agree on the problem and set expectations
Ensure that the team shares a common understanding of the problem, and explain what steps will be used to reach a decision. Acknowledge that the eventual decision may not be everyone’s personal favourite, but it does represent the team’s consensus, and we’ll commit to working with it once it’s been established.
Step 2: Agree on a scoring framework
Draw up an assessment framework for scoring possible solutions to the problem. Simple Yes/No assessments work best here, although weightings could be added to the criteria if needed. The aim is to make the assessment as mechanical as possible to reduce the impact of bias. Ensure the team agrees that the criteria are suitable before moving on.
Step 3: Enumerate all possible solutions
This helps highlight the relative strengths of different approaches, and ensures that ideas are only rejected once they have been properly assessed. It is important to avoid discussing the trade-offs of each solution at this stage. Nominating a neutral party to keep the discussion on track can help with this.
Step 4: Assess the solutions
As a group, work through each possible solution and perform the assessment, recording the results.
Step 5: Identify the highest-scoring solution and commit to the decision
Remember that this solution represents the team’s collective understanding and is something they are prepared to commit to. It should be viewed as a ‘best compromise’ if it doesn’t match everyone’s personal favourite. Agree when the decision will next be reviewed and what measures will be put in place to determine how successful it is.
Some Final Thoughts
As is so often the case in software engineering, there are no silver bullets here. This becomes even more apparent when we recognise that building software is a fundamentally socio-technical discipline: a great solution for one team may prove disastrous for another. Having used the method outlined above with several different teams, there does seem to be value in taking a more structured approach to important decisions, especially when the team has reached an impasse. It’s very much a work in progress, but the following pointers have emerged so far:
- Avoid the temptation to begin discussing trade-offs between the different solutions prematurely. Having a scrum master lead these sessions has helped keep everyone on track.
- The process may be uncomfortable at first for teams more used to ad-hoc decision-making, and will quickly become tedious if overused.
- Documenting the scores from step (4) in a wiki provides useful context for future reference.
I hope these ideas are useful to other teams who may be facing similar challenges in promoting collaborative decision-making. I’d be really interested to hear suggestions and feedback, so please do let me know your thoughts in the comments below.