Let’s begin with a short story …
A committee of project managers and engineers meet to review a proposal for a brand new nuclear reactor. Despite the complexity of the subject the team whizz through the initiative with few questions or comments raised, and approve it with little difficulty. Pleased with their progress, they decide to move to the second point on their agenda — a new bike shed for the office.
“What material should it be made of?”
“Where should it be built?”
“What colour?”
The discussion flows, a few minor arguments break out but get resolved. Before anyone on the team realizes it, they’ve spent almost twice as long reviewing a £500 bike shed as they had discussing the £10,000,000 reactor proposal.
Sound vaguely familiar? Sadly this is far too common in the workplace. Minor concerns can be wrestled with for hours whilst the important ones are skimmed over in moments.
Cyril Parkinson — a naval historian, most famed for the “other” Parkinson’s Law — recognized this effect and coined it as his Law of Triviality.
“The time spent on any item of an agenda will be in inverse proportion to the sum of money involved” — Parkinson’s Law of Triviality
Why do we fall into the trap?
A nuclear reactor is an extremely complex system, one that is fraught with risk. It requires a vast amount of specialized knowledge to understand well. Not all team members will have an equal grasp of the domain. There will be some key experts, for sure, but the majority may feel uncomfortable making suggestions for fear of looking foolish, assuming that someone who knows more about the problem will pick up the slack.
A bike shed, on the other hand, is easily understood by anyone. The detail is simple to grasp, and everyone has an opinion and the desire to leave the meeting satisfied that they’ve made a valuable contribution.
We see this phenomenon in software development. Focus is frequently given to the tasks that are most easily understood, rather than those that are critical to business.
A software developer who enjoys optimizing for algorithmic performance can burn days crafting an elegant algorithm that will never be fully utilized, whilst the real challenges are left untouched because of the mental effort required to dig into them.
Strategies to combat the ‘Bikeshed Effect’
Specificity
Avoid bundling many, unrelated, agenda items in the same meeting. To keep on topic, be specific. Create dedicated sessions for separate subjects, set a clear agenda and use your time wisely.
Too many cooks
Involve experts, those well educated in the subject at hand. Include some non-experts too, but not too many. Try not to include too many people in any one discussion.
Creating psychological safety
There’s no such thing as a dumb question — create a safe space to ask them. By taking away the fear of failure, learning will spread and better discussions can be had.
Give trivial tasks as little effort as they deserve
If a task or decision has a trivial outcome, put it in its place. Allocate fewer resources and give any decision-makers as much autonomy as possible. Not every decision needs to be made by a huge committee.
Short feedback loops
To avoid misplaced priorities, iterate quickly. Procrastination comes due to long-lived, badly specified work. Shorter feedback increases engagement and ensures that you are spending your time as wisely as possible.
Further reading
Why We Focus on Trivial Things: The Bikeshed Effect — Farnham Street
Bikeshedding and the Law of Triviality: Why People Focus on Minor Issues
Why do we focus on trivial things? — The Decision Lab
A final word
This post was written as part of a series on laws of software development for #PragProWriMo 2021 run by the
The Pragmatic Programmers.
Top comments (0)