What is bikeshedding?
Bikeshedding, also called the Law of Triviality, is when a team spends too much time arguing over minor, easy-to-understand details while complex, high-impact problems get waved through. The debate goes to code formatting, variable names, the color of a UI element or even the name of the team Slack channel. Architecture, security and core logic barely get discussed.
It's about people, not the system
The classic explanation is structural: people argue about what everyone can picture and stay quiet about what few understand. My experience working with teams is different. In well-run, experienced teams I have hardly ever seen bikeshedding. In my view it is less a systemic problem than one that comes from the personalities in a team and how they behave in discussions.
That means a lot can be done at a personal level: get people to be concrete and to focus on what matters. No lecture mode, no detours, no making a topic broader than it needs to be.
Preventing bikeshedding before the meeting
Two steps have proven useful for preparing meetings so that bikeshedding doesn't start.
First, the PM or PO has the “what” firmly under control. The “what” has to be cleanly separated from the “how”, and they make sure every requirement meets a strict Definition of Ready before it reaches the team.
On that basis, the requirements can be prioritized, for example with an Eisenhower matrix. The most important requirements then get more time in the team discussion than the less important ones.
Second, the team reviews that prioritization before going into detail. It checks whether the priorities and the planned time budgets match the technical questions it expects to work through. Where they don't, the team adjusts the ranking or the time budgets together.
This gets the team's agreement on priorities and time limits. It also gives you a shared basis you can point back to later, when a discussion gets out of hand.
Hourglass intervals and timeboxes
In the meeting itself, two simple measures help. The first is limited speaking time per person. I call these “hourglass intervals”. You can use real hourglasses with different run times, or a timer in online meetings. Each participant gets, for example, a maximum of 90 seconds before someone else has the floor.
The second is a timebox for each topic: a clear time frame within which the team should make a decision or find a solution.
One question to end detail debates
To avoid micromanagement and excessive detail discussions between developers, there is one guiding question you can bring into the discussion again and again:
“Is the requirement understood and agreed on well enough that a developer can work on it independently and make sound decisions to the best of their knowledge?”
If the answer is yes, that is a good moment to end the discussion and leave the rest of the work to the developer who owns it.
What if people ignore the rules?
A common objection: rules are all well and good, but what happens when people don't stick to them?
Honestly, that question surprises me. Enforcing agreed rules and making sure people follow them is part of a leader's job, much like a referee is responsible for keeping things orderly and enforcing the rules.
Anyone who repeatedly breaks rules the team agreed on has to expect consequences. That can be a direct intervention, or it can be taken into account in one-on-ones and in the performance review.
Where the term comes from
The British historian C. Northcote Parkinson described the Law of Triviality in his 1957 book Parkinson's Law. His example is a committee that approves the plans for a nuclear reactor almost without discussion, because few members understand it, and then argues at length about the staff bicycle shed, because everyone can picture one (Wikipedia).
In 1999 a trivial change set off a long thread on the FreeBSD mailing list. The Danish developer Poul-Henning Kamp replied with the bike shed image, and the word “bikeshedding” took hold in software.
These are skills beyond code
All of this falls under skills beyond code: setting priorities, driving decisions, running effective meetings and holding people to what the team agreed. We cover these skills in our course The Senior Shortcut.