Combating Bikeshedding

how to keep your team focused on what matters

In any business that’s moving fast, decision-making speed is critical. Decisions can run the gamut from trivial to business-critical, and getting good at scaling and distributing decision-making is both hard and ultimately rewarding, both for morale, as well as efficiency. It is possible for engineering teams to get stuck sometimes in making minor decisions that should be able to be federated, but for some reason get stuck into bike-shedding and just need to be made by a leader.

Bikeshedding refers to the phenomenon, which has some behavioral research behind it where teams spend too much time discussing trivial issues while ignoring more important, complex ones. The term originates from the idea that if you assign a committee to build a nuclear plant they will tend to spend a disproportionate amount of time debating how to build the bike shed than to tackle the design of the nuclear power plant. In essence, bike shedding occurs when people focus on small, simple decisions that need to be made because they are easier to reason about, than addressing the more complex designs that truly need attention. An example of possible bikeshedding is a long, protracted discussion on naming something or turf wars on using tech A vs tech B, when either are equivalent.

Bikeshedding is an anti-pattern. It can be overt, but usually not. It slows teams down and leads to suboptimal outcomes. While I am open to some diversity in approaches to engineering, there are things that I hold closely to and that are important. One of those things is that if teams are bikeshedding, it's a clear sign that we need a decision. There are only two possibilities for bikeshedding. (1) The issue isn’t trivial, it’s actually important that we get it right or (2) It’s truly not important and we need to make a decision and move on. So in either case, the best thing we can do is make the decision quickly and go.

In my role, I manage a series of meetings throughout the week that are designed to keep our team focused and aligned. (Full disclosure, I have enjoyed employing recommendations from Will Larson's writing). On Mondays, we have a staff leadership meeting where myself and my product leader meet with our leadership teams. On Tuesdays we have the Eng Ops Review meeting where we dive deep into metrics, initiatives and postmortems. On Wednesdays we have our Tech Spec Review, which allows us to take a close look at the design work being done. These are my favorite meetings all week. It allows me to dive deep with the teams across all aspects of engineering regularly.

Team members know that these meetings are where decisions can be made and are actually starting to use the process. So it’s highly likely that if they need help making a decision, they will raise the issue in one of these meetings. It’s hugely rewarding to see that happening. It makes the meeting valuable to me and everyone when we start using it for its intended purpose instead of it being a one-way meeting. Most decisions are either (1) Architectural, (2) Product oriented or (3) Bikeshedding. I highly encourage debate in these meetings to make sure every side is heard, but it’s also important to end the discussion with a promise on how the decision will be made.

Just last week during one of our tech spec reviews an engineer asked a simple question: "What should we name this feature?" It was a classic bikeshedding moment. Naming something may seem trivial, but it's the kind of question that developers could spend hours debating. My favorite approach to naming things like services is to try to not come up with a name that represents what the service does. Naming things can lock you or those that come later into a mental state that limits utility or expansion. However, in some cases, it makes sense to name things well, such as when it comes to schema objects and attributes. This could have been a bikeshedding moment, but it was easily solvable in this case.

There are really just two effective options for any bikeshedding moment. The first is to apply Occam's Razor, a principle that suggests the simplest solution is often the best one and just make the decision on move on. The second option, if it's not so clear, is to delegate the decision to someone who owns that aspect of the project to come up with tradeoffs to help make the decision quickly. Ideal timeframe for any decision is a small number of days. In this particular instance, I chose to delegate the decision to the product team. Although I could have easily used Occam's Razor to settle the debate, I recognized that naming the feature was something that the product team needed to own. It was important for the product, not engineering, to own this part of the project. By delegating, I placed the decision in the right hands and reinforced the importance of ownership within our organization. I also asked them to come back with an answer within a day.

Naming things is an easy example, but these techniques also work with architecture or tech stack decisions. These sorts of decisions can actually be more gnarly, especially if code has been written. My favorite quote on this is from Ben Horowitz's book, the Hard thing about Hard things:

Early in my career as an engineer, I'd learned that all decisions were objective until the first line of code was written. After that, all decisions were emotional.

Decisions made after code has been written almost always have an emotional element to them. Sometimes it helps to remind teams of the emotional part of the decision and ask them for objectivity. It can help to ask them to come up with a short list of the most important tradeoffs involved in the decision and which of those are most important to the business. Ultimately, decisions that involve code already written almost always have to be made by the most senior engineer or engineering leader.

Using Occam’s Razor or delegating to a reasonable owner and asking for quick turnaround are both effective tools for driving through and making decisions quickly. Some decisions can be deferred for later, which is another technique, but not making a decision that needs to be made is the worst possible outcome for a team that can leave lasting impacts. It’s better to come to a decision, even if it’s tempered with “for now”, and everyone can move on.

Bikeshedding is a common challenge in any team. So the next time a bikeshedding moment arises, remember to stay focused, delegate when necessary, help your team get to an answer quickly and move on.