Postmortem of a Failed Design Meeting

Image for post
Image for post
Photo by Kaleidico on Unsplash

I was once in a very frustrating meeting. We were trying to determine the proper design for a component. The meeting was led by a manager* who had little technical experience in the area. Another developer and I were advocating different solutions. The meeting became tense. It became clear the meeting was not going to reach consensus. The manager started seeking out compromise solutions to make us both happy. This also meant that the manager was going to be making the decision. The merits of our solutions no longer mattered.
I started arguing more rigorously for my proposed solution. The other developer just shut down and stopped contributing. That isn’t what I wanted, and was saddened by it, but I could see how I contributed to it. The meeting ended inconclusively, the manager deciding to make the decision offline.

This was nobody’s fault.

The meeting went so badly that I did a postmortem to figure out what went wrong. Here is what I came up with.

A Design Meeting is Different

Our first mistake was that we didn’t realize we were in a design meeting, and the rules for a design meeting are different from most other meetings.

The purpose of a design meeting is to determine the best technical solution to a technical problem given constraints.

The goal of most other meetings where there are multiple interests is to come up with win/win outcomes. They generally deal with scarce resources and how they should be allocated. Whose feature gets implemented? How many resources does my project get vs your project? Win/win generally means we’re seeking to compromise, to give both sides what’s most important to them by giving up some of what isn’t as important.

A design meeting is different in that we are trying to find the best solution. The meeting is the process of understanding the merits of the various solutions so that one can be selected. We are a group trying to find the best solution to a problem. We are not factions trying to get our way or fight over scarce resources.

For my meeting, the fact that this was a design meeting, and what that meant, should have been made clear at the outset.

Define the Problem

Our second mistake was that we never discussed the problem. We all assumed we knew what it was. That was a huge mistake.

This meant that we all had our own criteria for determining what the best solution was. We weren’t able to see the merits of each other’s solutions, because those solutions were solving slightly different problems. We became frustrated when others could not see why our solution is so awesome. We didn’t understand why they made such a big deal out of details that seem irrelevant to us.

Defining the problem means we should enumerate the critical features that the solution must-have, and the constraints the solution must meet. Features are the things that our solution must do. Constraints are the limits our environment places on us. Constraints are often limited resources.
We only have 3 developers. The developers only know Java. The project must be complete in 4 weeks.

For my meeting, the fact that we didn’t enumerate the problem meant that we were talking past each other the entire meeting. It meant that the meeting had shifted into a personality conflict.

Make the Decision-Making Process Clear

The third mistake was falling into a bad decision-making process.

We all naturally want consensus, but sometimes consensus isn’t possible.
When that happens, how are we going to decide? Sometimes it might be best to have one or more senior technical people make the decision. The decision-maker might be the person with the most experience or the person with technical responsibility.

Or it might be a simple vote. Voting works best when voting is able to select the best solution without other factors interfering. For example, a group of peers who are all about the same level of technical experience in the problem area. When the voters are at completely different levels or are voting against their superiors, then voting can lead to bad outcomes.

Since these are technical problems, the decision is best left to people who are closest to technology, generally this are not managers. Managers can help with the process, but only rarely should make technical decisions. That said, the technical solution and its potential impacts should be explainable to the business.

Sometimes it is not possible to come to a good solution. In these cases, the decision might be to do further research, build a prototype, or the like.

For my meeting, the decision-making process was not stated and defaulted to the most senior manager. A person who was not best positioned to be able to evaluate the technical merits of the solutions.

Appoint a Leader

The final mistake was not having a clear leader.

The manager who called the meeting just sat back and let it happen. While that might be good in some circumstances, this meeting needed guidance.

The leader is often the decision-maker, but might just be someone good at running a design meeting. The leader’s job is to ensure that solutions get a proper vetting. This means ensuring that everyone understands that this is a design meeting, what the problem is, and how the decision is to be made. It means spending time discussing a variety of solutions and knowing when to transition from “ideation” to evaluation. It means drawing out shy members and calming down the excited. The leader should ensure that everyone feels like they are getting a fair hearing so that when a decision is made, they feel that the process was fair, even if they disagree with the result.

One thing that has always helped me is to think that every proposed solution is correct, for a given set of assumptions. Change the discussion to be, what assumptions must be true for this to be the best solution.

For my meeting, the leader should have seen how one person started to dominate the discussion, calm him down, and draw out the other person to make sure their solution got the hearing it deserved.

It is a Wonderful Thing

A well-run design meeting is a wonderful thing. It can foster respect. It can lead to solutions that everyone can get behind, even if they disagree.

With these tips, I’m sure you’ll be well on the way to awesome design meetings.

*This is not a current or former manager of mine at Criteo.

Do you want to participate in our next Design meeting? Check out our open positions:

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store