An Approach for Finding Consensus in Complexity
*Originally posted at Product Lab on Medium: link
Have you ever been in a lengthy meeting that doesn’t seem to be going anywhere? Building consensus among a large group is difficult.
As Pivots, we train to get the best out of groups in a short period of time. Luckily, we learn our facilitation skills from fellow Pivots clevergirl and jfraser. Given that each group and problem is different, using these foundational skills to develop unique exercises to fit the situation is essential.
Recently, I ran a ten-person team of talented engineers through a two-hour exercise to determine the best approach to solving an extremely technical problem. Here is how the group tackled the problem.
Get a lay of the land
First, we got on the same page of what the current system looks like. Using sharpies, note cards, and a large table, the team laid out how the system presently looks.
Brainstorm possible solutions
Next, I flipped a few cards and destroyed some others to reflect the desired end-state system. I prompted the brainstorming session with, “What do we need to change in order to make this system work?”
The group then did a “dump and sort” of each of their ideas. The exercise starts by writing down ideas in silence on post-its for three minutes. Next, each team member divides his/her post-its into two piles sorted by viability. I then ask each group member to destroy the pile of less viable solutions. We can’t solve the world. This activity helps us focus.
I then asked each team member to take his/her more viable pile to the front wall and post it for others to see. The group read the solutions in silence, letting the ideas stand on their own, and members clarify any questions. Next, members voted on the two solutions that seem best (note: we are staying at a high level at this point).
The top 5 solutions moved to the next round.
Name the solutions
Before we went looking for the dragons hidden in the existing system, we named the solutions to provide a common language for the coming discussion. The team spent 10 minutes carefully naming each solution. We chose meme’s that best reflected the solution (e.g. “Yo Dawg, I put pointers on your pointers”).
This time was also used as a short break if anyone needed it.
Dump and sort pro’s and con’s
Since this was a technical problem and the knowledge of the system was dispersed, each individual needed to share his/her perspective of each solution.
For each of the 5 solutions, the team did a three minute dumb & sort on the pro’s and con’s of each solution (e.g. “Moves the system to a component architecture” or “This will eat up all our time”). I had the group sort their post-its based on what they felt was most important to share with the team. I also encouraged them to have an even mixture of pro’s and con’s.
3 minutes each
After 3 minutes had elapsed, the team went to the board, each with their sorted post-its, and put each post-it in its respective box. If a team member has a similar thought, then those post-its were grouped together.
5 minutes each
Repeat for each solution
The team repeated this process for the other four solutions.
(3 + 5 minutes) * number of solutions
Vote on approach
Now that the team had a better understanding of each solution, the team voted on an approach with the dot voting method, which is described above.
Time to consensus: 1 hour 55 minutes