Bikeshedding (Law of Triviality)
Groups spend disproportionate time on trivial issues because everyone feels qualified to discuss them.
“I wish we could let people build a bike shed every so often, and I don't really care what colour they paint it.”
To an executive
Meetings give the most time to the easiest topics, not the costliest ones. Steer review time towards the big, hard-to-reverse decisions, where a mistake is expensive.
To an engineer
In design reviews, time the agenda by risk. Settle naming and diagram style by convention, and spend the hour on data ownership, failure modes and irreversible commitments.
The idea
C. Northcote Parkinson described a committee that approved plans for an atomic reactor quickly but argued at length about a bicycle shed for staff. The reactor was so vast and complex that members could not really grasp it, and assumed someone else had checked the details. Everyone understands a bike shed, so everyone has an opinion.
Poul-Henning Kamp brought the idea into software in a 1999 email to FreeBSD developers, and "bikeshedding" became the name for spending energy on whatever is easiest to comment on. He noted that people join these debates partly to show they are engaged, to leave their fingerprint on the decision.
Architecture reviews are especially prone to this: naming conventions and diagram colours get long debates, while data ownership, failure modes and irreversible commitments get a nod.
Why it works
People talk about what they understand. A topic's accessibility, not its importance, decides how many people feel able to contribute. Simple topics attract more voices and therefore more time.
Contributing feels like participating. In a meeting, saying something is a way to show you are engaged. Trivial topics offer the easiest way in.
Hard topics feel risky. Questioning a complex proposal means admitting what you do not understand. It is easier to assume the experts have it covered.
Where it applies
- Architecture and design review boards, where agendas mix trivial and fundamental items.
- Pull request reviews, where formatting comments outnumber design comments.
- Standards and guidelines, where naming rules can absorb more effort than integration contracts.
- Stakeholder workshops, where a visible but minor detail of a proposal dominates the discussion.
How to apply
- Order the agenda by impact and irreversibility, putting one-way-door decisions first while people are fresh.
- Time-box low-stakes topics, and say out loud when a discussion is outgrowing its importance.
- Delegate trivia to defaults, linters, existing standards or a single named owner.
- Prompt the hard questions directly. Ask "what happens when this fails?" or "who owns this data?" so the complex topic gets real scrutiny.
Example scenario
A review board spent fifty minutes debating REST resource naming for a new service and five minutes on the proposal, in the same pack, to have six teams share one production database. Nobody objected to the database because nobody felt sure enough to.
The following year, that shared database caused the organisation's largest incident. Afterwards the board reordered its agenda to start with data ownership and irreversible decisions, moved naming questions to an API style guide and a linter, and capped any single minor topic at ten minutes.
Questions to ask
- Is the time we are spending on this proportionate to its impact?
- Which decision on today's agenda is hardest to reverse, and have we discussed it yet?
- Can a default, a standard or a single owner settle this instead of the group?
When not to use it
- When the "small" detail is high-impact. Public API names, data formats and contract fields are hard to change once clients depend on them; debating them is not bikeshedding.
- When a group is learning together. Easy topics can be a safe way for newer members to start contributing.
How it misleads you
Dismissing all detail as bikeshedding. Some small details, such as public API contracts, are genuinely high-impact. Calling something a bike shed can also be used to shut down a colleague's legitimate concern; check the impact before applying the label.
In the wild
Further reading
Last reviewed · Suggest an improvement