Why do we need this?

One of the most difficult aspects of a leader’s role is striking the right balance between giving direction and encouraging teams to make decisions independently. While experience may suggest that a particular approach 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 for themselves. Building that environment and providing their teams with just enough direction is where a leader 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, too much is left open to ambiguity: the problem being addressed, the criteria against which potential solutions should be assessed, as well as 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 criteria work best here, although weightings could be added 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 when we come to assess them in step (4), and ensures that ideas are only rejected once they have been properly discussed. 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 interested to hear suggestions and feedback, so please let me know your thoughts in the comments below.