3 Lessons I Learned About Group Decision Making

Over the past years I've helped make many changes and improvements at my job. Those reached from project prioritisation to architectural solutions, changing a style guide, introducing a career ladder and many more. In all of these cases, forming consensus in a group was required to make the decision. I call it Group Decision Making. Here's what I learned.

1. The Change Needs To Be Clear

Decisions are always tied to a change, which is why I'll refer to changes a lot in this post.

When you're pushing for a change, it helps to acknowledge that you have a unique perspective that not everyone will share out of the box. I found a couple of questions pretty useful to find a shared perspective in a group.

What Happens If You Do Nothing?

For most decisions the default option is to do nothing and leave things as they are. Try answering the following questions:

• What's the best thing about the current solution?
• When we stick to using it, what is the worst case scenario we could be in a year from now?
• Is there anything you can categorically not do with the status quo? (this applies to only few cases)

It helps to answer these questions for yourself as doing so will help you understood the status quo well. You might find out that you need to put more effort into researching the way we landed at the current situation. This is necessary to make a good decision on how to move forward.

If you can, publish your perspective to the wider group. This allows everyone else to weigh in, so that you can hear concerns and problems early.

What Problem Should Be Solved?

It's not always easy to put into concise words what you're solving. Addressing what problem shall be solved leaves for the largest amount of misunderstanding. I tend to think about it as something directional, describing with examples what will be possible. I've found it helpful to ponder

• Who will benefit from the change?
• What is the time horizon? (How soon will someone profit through the change & how frequently)
• Does this change enable radical new opportunities? (e.g. better deployment tooling makes it easier to manage more & smaller micro-services and is therefore one of those enablers)
• What is out of scope to be solved with this change?

Often when you get people excited about a change, they may bring up a couple of other problems that they would like to see changed, too. This can sometimes lead to scope creep and your change proposal may lead nowhere when it's trying to solve 1000 different problems. Therefore it's important to draw the line between what items should be improved and what items should not.

What Solution Are You Proposing?

Name your solution. After you've described the status quo and laid out the problem, you have everyone's attention to present your solution. It's particularly great if your proposed solution has a name that people will remember.

How Would You Implement That Solution?

You don't need to have the answers for this on day 1, but answers for how the solution will be implemented are critical to gain everyone's agreement. Who is willing to take the cost of making the change? How will it be rolled out? In a small team this may all be trivial to answer, but in a team of hundreds of developers responsibilities need to be a lot more clear.

What Alternatives Exist?

You know about alternative solutions if you've thought about a problem hard enough. The work you put into this depends on how big the change is. Changing an eslint rule might require a one sentence answer while changing git branching workflows may require 5 minutes of explanations why some other options are not worth considering in as much detail.

2. Changes Require Determination And Effort

This seems obvious now, but I had to learn that the hard way. Changes don't just happen even when everyone wants them. Changing habits & tools requires hard work from someone.

A Champion For The Change Needs To Drive The Effort

Chances are that if you're reading this, more often than not you want to champion a change. The champion will facilitate the decision, ensure that the right people are in the room to drive it forward and make sure that the change is documented appropriately. They can inform you about the consequences of doing nothing, the scope of the problem being solved, the proposed solution, the implementation of said solution and the available alternatives. Often the champion also drives the option or options that are being considered as solutions, but it can also work that they act purely as a facilitator.

Split Between Discussion And Decision Meetings

There needs to be a time to hear everyone's concerns and discuss them and there needs to be a time to make decisions. I've found it very productive to split that into two sessions: One where floor is open for discussion and one where the focus is on making the decision.

Imagine you haven't clarified if people are in the room to make a decision or to have a discussion. You'll easily end up in a situation where one person is trying to push for the decision and another is blocking that decision because not enough has been discussed yet. If you set a clear meeting agenda that describes wether the meeting is about having a discussion or making a decision, the whole group can come together much more easily.

Drive Quick Decisions With TOMASP

It can help to have a certain urgency in making decisions to avoid change fatigue. Change fatigue happens when you talk about a change over and over again with nothing to show for it. At some point people stop believing that it is ever going to happen.

The TOMASP Decision Framework can help tackle such an issue by forcing you to make decisions more quickly. This leads to less risky decisions and better agility.

3. Trusting Teams Make Better Decisions

Simon Sinek has a great story about trusting teams, which explains much of why trust makes such a big difference

After all, only in a trusting team can you receive the feedback that's necessary to address everyone's concerns. Only then people will make suggestions without fear of being called stupid. And only then can you truly know how people really feel about a change.