Reframing The Problem

So yeah, you're 80 minutes into an hour-long meeting. The team is trying to settle on the design for their next project. There are two different proposals on the table, and each has someone quite senior advocating for it. Perhaps there are factions, with team members clearly siding with one or the other proposal. By this point in the meeting, everyone understands the proposals, and people are just reformulating prior arguments, trying to persuade others of the superiority of their preferred solution. Round and round in circles you go. How do you get out of here?

The Trap

Group decision-making is about finding consensus, which can be tough to achieve when people with strong opinions disagree. If you're advocating for a particular proposal, it may be difficult to understand why others don't see it your way. Perhaps they misunderstand a certain point, or don't see a danger that your proposal cleverly avoids. The obvious tactic for you is to be more persuasive, continuing to rework and refine your arguments until everyone else comes around. Unfortunately, that's exactly what the advocates for the competing proposal are trying to do as well! Something has to give.

Decision deadlock can occur even when everyone is arguing in good faith, even when everyone is smart and talented and trying to do their best for the group as a whole. We continually rework our arguments under the theory that the best argument will eventually win the day, but that only works if everyone agrees on exactly what problem we're trying to solve. If we're trying to solve even slightly different problems, which may prefer different characteristics in a solution (e.g. speed vs. robustness), we can argue until we're blue in the face and never reach consensus.

The Escape

How do we escape this trap? When I sense a team stuck like this, I'll explicitly make the group take a step back by reframing the problem. Instead of just solving the technical issue at hand, consider the larger business context. Does this solution need to be short- or long-term? How important is cost, or reusability? Maybe the proposals differ along some dimension, such as time-to-market, that we're not even sure how critical it is, and we need additional data/input to make a proper decision. Or perhaps the differences are irrelevant -- how important is it really to solve the particular nuances each proposal addresses?

My role here is not to pick a solution, but instead shape the discussion such that the team can agree on a solution. Rather than advocating for any particular proposal, I am instead an advocate for getting to a resolution and moving forward. If the team needs additional data to make their decision, let's identify exactly what we need and go get it. If we need an external stakeholder to weigh in on a potential tradeoff, let's go grab them. Typically, conflict is the result of people trying to solve a problem with multiple missing variables and coming up with different plausible solutions. If you are able to resolve some of those variables, a preferred solution often becomes obvious to everyone -- and as a bonus, no one feels like they've been told what to do.

Importantly, I can't effectively advocate for resolution if I'm also advocating for a particular proposal. Attempting to do so undercuts the force of your arguments framing the debate, because it's clear to everyone that you're not impartial. Moreover, advocating for resolution means that you may need to compromise on some principles, and you have to be comfortable with that. If you strongly feel something about a proposed solution needs to change, your objection has to be framed as a legitimate business constraint (e.g. customer data MUST be stored a certain way) that the team must work within, or it will be subject to negotiation.

Interestingly, it doesn't always have to be the same person taking on this role every time. Even within the same team, I've sometimes been an advocate for resolution, and other times advocated for a solution I felt particularly strongly about. In the latter instances, someone else on the team may have to step up and lead us to a resolution. This is okay, and even healthy, so long as someone takes on this role when its necessity becomes apparent.

What if you just picked?

If you are a leader with any kind of official authority, you have another tool at your disposal -- you could just pick your favorite solution! Be the decider! For me, this is a last, last-resort tool. It has all sorts of downsides for the people whose solution was not picked, as well as for your relationship with them. Executed poorly, it can break up teams.

I still recall the very first time I used this tool. I had just been made a lead for a multi-month project, with three other developers assigned to the team. As we sat down to plan out the project, we needed to decide on a relatively minor process question -- how would we commit in-progress development along the way? The company had no standard, so teams were free to either commit as often as they liked behind a feature flag, or push work to a separate branch entirely, one that would get merged when the feature was complete. However we did it, for the team to work together, we all had to do it the same way. I advocated for feature flags, and while two of the other developers agreed with me, the fourth was adamant about developing in a separate branch. The strength of our arguments was irrelevant; there was no persuading either side. Seeing no way out, I eventually, with the support of the other two devs, just picked 'feature flags', because we had to pick something and move on.

The next day, my boss pulled me aside and told me that the fourth developer, who adamantly did not want to use feature flags, had come to him and requested to be put on a different team, a request which was granted. I had been a lead of a team for less than a week and already that team had broken apart! From this, I came to understand how important willing consensus is to a team. A team is not a democracy, but neither is it a dictatorship. The manager could have left the unhappy developer on my team, but to what point? Productivity would have been low, and perhaps that developer would have left the company entirely. Maybe this conflict was unavoidable. The team did have to pick something, and possibly the difference was unresolvable. But the cost of dictating a solution, overriding the strong preference of a team member, was the sundering of the team itself. While sometimes necessary, this is not a cost I would willingly pay when any alternative was viable.

A Powerful Tool

Reframing a problem is a powerful, widely-applicable tool. Because it operates on a level above that of solutions, it does not directly contradict any particular solution. It takes a lot more effort and conviction to reject the premise of a frame; most people will just take a new framing as given, then alter their solution to fit it. Moreover, it helps reset the game, weakening existing factions as a necessary step towards consolidating around a single solution. There are certainly other tools for resolving conflicting proposals within a team, but reframing the solution remains my favorite.