Apr 02 2015
“Let’s have our meeting in the conference room. We can order lunch.”
If you’ve heard this before, then you know how likely it is that a significant chunk of your meeting will be spent figuring out where lunch will come from, and what to order.
Because it’s a simple problem. We all understand food. We all know what we like and dislike. We have a strong grasp of the options available, and the likely outcomes of choosing each one.
And if we’re meeting to discuss something challenging, we’ll naturally gravitate toward spending time on the easier problem instead.
This phenomenon has a name: Parkinson’s Law of Triviality.
Parkinson observed and illustrated that a committee whose job is to approve plans for a nuclear power plant spent the majority of its time with pointless discussions on relatively trivial and unimportant but easy-to-grasp issues, such as what materials to use for the staff bike shed, while neglecting the less-trivial proposed design of the nuclear power plant itself, which is far more important but also a far more difficult and complex task to criticize constructively.
Because the team spent so much time discussing the color of the bike shed, Parkinson’s Law has also been called “The Bike Shed Effect,” and it’s where the term “bikeshedding” comes from.
We see The Bike Shed Effect a lot in software development.
Many people, especially when working in teams, give disproportionate weight to things that, in the end, matter very little.
Project teams will spend hours debating the color of a button while the complex issues, like how the interaction they’re designing is going to get the customer from A to B in a seamless way, remain unresolved.
Nobody is immune to Parkinson’s Law, but it’s important to understand when you’ve gone from constructive discussion to wasteful bikeshedding.
Bikeshedding is a form of procrastination. Procrastination, by definition, destroys productivity.
One of the best ways to reduce procrastination is to give yourself an allowance.
For example, if you tell yourself that you can’t visit Twitter at all, you’ll spend all of your time and energy exercising the willpower required to stay away from Twitter. On the other hand, if you tell yourself that you can only visit Twitter five times today, you’ll be prudent in how you use your five visits, but you won’t spend all day thinking about what you’re missing.
The same principle can be applied to bikeshedding.
The second you begin to feel that bikeshedding is taking place, pull out your phone and set a timer for three minutes. Let the team know that they have three minutes to decide the question. Whatever the prevailing opinion is at the end of three minutes is what you’ll go with.
If need be, assign a decision maker (this should be the project lead) to make the call when the timer buzzes.
One of the biggest inefficiencies in many companies is abstract, undefined meeting scopes.
If you have a one-hour meeting planned, and the scope is one sentence (e.g., “to discuss the new landing page design”), then you’re setting yourself up to waste most of that hour.
Make it someone’s responsibility to craft and distribute a detailed scope before the meeting. This should include, on a granular level, the specific topics of discussions and questions to be resolved.
When the meeting starts, go down the list. If the discussion turns to something that’s not on the list, table that topic. When you get to the bottom of the list, the meeting is over.
In many organizations, another reason that teams spend so much time on decisions is the fear of making the wrong choice.
If your team fears making the wrong decision on something so trivial, then there’s likely a culture problem stemming from the top that needs to be fixed.
I’m not a big fan of “failure culture” and I don’t think that we should all be fetishizing failure, but we shouldn’t fear failure, either. That’s what leads to analysis paralysis.
Failure caused by sloppy or reckless work isn’t okay.
Failure that comes as part of a strong, systematic process is a good thing.
Part of a strong systematic process is a system for rapid decision-making, like the 3-minute limit.
Another part of a strong process is a no-fault review, where the team looks at the decisions made and the outcomes that transpired, and gleans actionable takeaways for the future.
When people know that failure is okay as long as the approach is strong, bikeshedding becomes a lot less likely.
Everyone is susceptible to bikeshedding from time to time. But the important thing is to be aware of it so that it can be overcome, rather than succumbing to it and wasting valuable time and resources.
Next time you find yourself or your team bikeshedding on trivial issues, pick a damn color and move on.
~ Nick Kishfy (@kishfy)