Parkinson's Law of Triviality / Bikeshedding

What is bikeshedding?

Members of an organization give disproportionate weight to trivial issues because the trivial issues are the ones everyone feels qualified to have an opinion on.

Parkinson's original example: a fictional committee approves a nuclear power plant in minutes — the engineering is above their heads — then spends hours debating the materials for the staff bike shed, a topic anyone can hold views on.

The joke lands because the pattern is real and recurring. Every engineering org, every PM meeting, every strategy offsite runs into it. The bike shed always gets more discussion than the reactor.

Why it happens (the structural explanation)

Bikeshedding isn't caused by unserious people. It's caused by a structural asymmetry between how participation works and how expertise is distributed. In any group meeting:

1. Speaking time is roughly egalitarian. Everyone feels entitled to contribute.
2. Expertise on complex topics is concentrated. Only one or two people in the room can meaningfully weigh in on the reactor design.
3. Trivial topics invert this. Everyone has color preferences for the bike shed.

The result: the group's time budget gets allocated to wherever participation feels most natural. The complex topics get nodded through because nobody wants to ask the obvious question; the trivial topics get re-litigated because everyone can hold a view.

This means bikeshedding is primarily a meeting-design problem, not a team-quality problem. Teams you respect still bikeshed when the meeting structure doesn't actively prevent it.

Where it shows up in tech

• Code review. Nit comments on naming and formatting get 20 comments; the subtle race condition in the locking logic gets one "LGTM." Reviewers gravitate to what they can evaluate quickly.
• PRD reviews. The copywriting of the CTA button gets 45 minutes; the pricing model decision that determines whether the product is viable gets 5.
• Board meetings. The logo redesign generates more debate than the hiring plan. This is so common that Paul Graham once joked the quickest way to get a decision approved is to sandwich it next to a trivial, visually-obvious one.
• Architecture decisions. Teams spend an hour debating variable naming conventions and then accept a fundamental data-model choice with "sure, that works."

In every case the mechanic is the same: the high-leverage decision is hard to have an opinion on without homework, so it gets under-discussed; the low-leverage decision is accessible, so it gets over-discussed.

Mitigations that actually work

Not every "overcome bikeshedding" tactic is equally effective. What works in practice:

1. Separate decision modes per agenda item. Mark each item as either "decide here" or "inform here." Debate is only allowed on "decide here" items. Cosmetic items should almost always be "inform here" — one person owns them, the group doesn't revisit.
2. Assign a DRI with pre-work. For any consequential decision, one person is the Directly Responsible Individual. They circulate a written memo 24 hours in advance with a proposal. The meeting discusses the memo's weak points, not the problem from scratch.
3. Time-box by importance, not by appearance. If an item is 80% of the quarter's outcome, allocate 80% of the meeting. Put the trivial items last — they'll get compressed naturally because time runs out, instead of expanding to fill available space.
4. Convert cosmetic decisions into single-owner decisions. Button color, variable names, README phrasing — pick one person to decide, tell the team the decision is theirs, and don't revisit. You trade some quality on the trivial axis for enormous time savings. It's always worth it.
5. Use writing to equalize expertise asymmetry. A written proposal lets the non-experts read, think, and form a considered view before the meeting. Meetings where everyone read the doc ahead of time don't bikeshed — nobody wants to expose that they missed the real issue. ADRs, RFCs, and design docs exist partly for this reason.
6. Name the pattern out loud. Saying "I think we're bikeshedding on this — let's table it and come back to the data-model question" is often enough. Most teams know they're doing it; they just need permission to stop.

What doesn't work

• "Just have a clear agenda." Agendas help but don't solve the problem. A clear agenda with equal time per item still bikesheds, because the equal-time structure is itself the issue.
• Trying to make the hard topic easier. Simplifying the reactor to bike-shed level doesn't help. The simplification usually loses the decision's actual complexity.
• Appealing to seriousness. "Let's focus on what matters" in the middle of a bike-shed debate rarely redirects the group. The structural asymmetry is stronger than the appeal.

The deeper lesson

The phenomenon generalizes beyond meetings. It's a specific case of a broader pattern: attention is allocated to what's accessible, not to what's important. You see it in personal productivity (the easy tasks get done first), in writing (the copy edits get obsessed over while the argument doesn't hold together), and in life (gym habits get tracked meticulously while the harder questions of relationships and purpose go unexamined).

A useful private habit is to periodically ask: Where am I spending my attention, and is it proportional to what actually matters? The honest answer is usually "no" — and the correction is usually to redirect toward the harder, less tractable thing.

See also

• Steve Jobs: Managers and Bozos — another failure mode where process displaces substance.
• Bullshit Detector — related cognitive asymmetry: confident opinions on trivial matters mask weak analysis on important ones.