Learn it → Apply it → Save as Skill
The smaller and more visible a decision is, the longer a group will argue about it. Hand a committee a complex, expensive, high-stakes question next to a cheap, easy-to-picture one, and watch where the real debate happens. It is rarely the expensive question. Everyone can picture a bicycle shed. Almost no one feels qualified to challenge a reactor.
The Dr. Wallace’s Favorite Mental Models is designed to turn useful ways of thinking into reusable tools. Each model gives you a fast visual overview, deeper interactive learning, practical application exercises and an AI-ready Markdown skill you can save for future use.
Instead of merely reading about mental models, you can gradually build your own AI skills library: a collection of portable reasoning skills that can help ChatGPT, Claude, Grok and other AI assistants apply the mental models you value.
British naval historian C. Northcote Parkinson described this in his 1957 book Parkinson’s Law, or the Pursuit of Progress. His fictional finance committee approves a complex, expensive nuclear reactor in minutes, then spends far longer arguing over a cheap, easy-to-picture bicycle shed for the staff, because everyone can safely have an opinion about a bike shed and almost no one wants to look foolish questioning a reactor.
Important: this is a strong, widely observed pattern, not a measured law. It describes where attention tends to drift absent active management, not a fixed rule every group obeys.
The model is most useful whenever a meeting, thread, or review is spending more energy on the item people find easiest to picture than on the item that actually carries the most risk or cost.
The method separates how much debate time a topic is actually consuming from how much its real stakes, cost, risk, or reversibility, would justify.
An agenda item is getting outsized airtime relative to its cost, risk, or long-term impact.
Compare the minutes spent against the item’s real stakes, and check whether the big-ticket item next to it passed with almost no scrutiny.
Name the pattern aloud, “we may be bikeshedding here,” and steer attention back to the decision that actually carries the risk.
Timebox the easy, visible item and assign a single owner to the complex one, so neither can quietly absorb the whole meeting.
Open a use case to see what the model changes.
A leadership team approves a seven-figure vendor contract in six minutes, then spends forty minutes debating the wording of an internal email announcing it. Naming the pattern out loud is often enough to reset the room’s attention.
This is the exact context that gave the pattern its popular nickname. A pull request introducing a genuinely risky change gets a quick approval, while a trivial variable-naming or indentation choice draws a dozen comments, because everyone can have a confident opinion about a name but few want to be the one who misjudges the architecture.
A board approves a multi-year grant commitment with almost no discussion, then spends most of the meeting on the phrasing of an event invitation. The grant is harder to evaluate quickly, so it gets deferred to trust; the invitation is something everyone can edit on sight.
The term “bikeshedding” itself comes from exactly this setting: a 1999 piece by developer Poul-Henning Kamp inside the BSD Unix community, written after watching simple, cosmetic proposals draw far more argument than complex technical ones.
A complex liability clause in a multi-year vendor contract passes with a glance, while a minor administrative clause, easy for anyone to read and reword, gets marked up repeatedly. The easy clause is not more important; it is simply more accessible to comment on.
A team ships a feature whose underlying logic nobody fully stress-tested, after a design review that spent most of its time on which shade of a button to use. The color choice was simply the part everyone in the room felt entitled to weigh in on.
This is an illustrative example designed to teach the method.
Expand for where the idea comes from and how it earned its nickname.
British naval historian and author C. Northcote Parkinson introduced it in his 1957 book Parkinson’s Law, or the Pursuit of Progress, built around a fictional finance committee that approves a complex, expensive project, in his telling, a nuclear reactor, in a few minutes, then spends far longer arguing about a cheap, easy-to-picture item such as a bicycle shed for the staff. His stated principle: the time a group spends on an agenda item tends to run in inverse proportion to how much money, or complexity, is actually involved.
Danish software developer Poul-Henning Kamp popularized “bikeshedding” in 1999 inside the BSD Unix community, in a widely circulated piece titled “Why Should I Care What Color the Bikeshed Is?” The nickname stuck in software engineering specifically because mailing lists and code review made the pattern visible to everyone: anyone can comment on a naming or styling choice, while far fewer people feel qualified to challenge a complex architectural decision.
It is a satirical, descriptive observation, not an empirically derived formula. Parkinson wrote it as organizational humor grounded in real observation. Related ideas describe similar patterns independently: Sayre’s Law holds that the intensity of a dispute is inversely proportional to the real stakes involved, and Wadler’s Law observes that programming-language debates tend to fixate on syntax rather than semantics.
The pattern is about how approachable a topic feels, not how capable the people in the room are. Smart, experienced groups bikeshed too.
Some seemingly minor topics genuinely deserve the attention they get. The problem is substituting approachability for stakes, not discussing small things at all.
A decision cleared in two minutes was not necessarily well vetted. Often it means nobody in the room understood it well enough to raise an objection.
A technically fluent team can still spend an hour on a naming convention everyone understands, instead of the architectural risk few want to own.
The same pattern shows up in email threads, code review comments, public-comment periods, and group chats, anywhere a cheap, visible choice sits next to an expensive, abstract one.
Calling out “bikeshedding” to dismiss someone’s concern can shut down a legitimate objection. Use it to redirect attention, not to win an argument.
a complex item passed with little debate because nobody present actually understood it. The fix is better review, not simply noting that the group bikeshedded elsewhere.
a seemingly small topic, such as accessible signage or a safety procedure, carries outsized importance for a specific group. Do not wave it away as trivial.
the real problem is unclear ownership of a decision, not disproportionate debate time. Fixing who decides often fixes the airtime problem on its own.
This browser tool structures your thinking. It does not send your information anywhere or perform AI analysis.
Save as Skill converts the model into portable Markdown instructions that teach an AI when and how to apply Parkinson’s Law of Triviality, what questions to ask, what evidence to seek, what mistakes to avoid and how to structure its analysis.
Save the skills you find useful and organize them into your own reusable library. The Markdown is intentionally model-neutral, so it can be used wherever an AI system accepts uploaded files, project knowledge, custom instructions or reusable text context. Platform capabilities differ, so this is a portable skill file rather than a claim of one-click installation.
Yes. They describe the same core pattern. “Law of Triviality” is Parkinson’s original 1957 term; “bikeshedding” is the nickname that spread through software engineering after Poul-Henning Kamp’s 1999 writing popularized it inside the BSD Unix community.
No. The issue is not the size of the topic. It is letting how approachable a topic feels substitute for how much it actually matters when a group decides where to spend its limited attention.
Common tactics include timeboxing agenda items in proportion to their real stakes rather than their popularity, assigning a single accountable owner to complex items so the group does not need unanimous understanding to proceed, and simply naming the pattern out loud, “we may be bikeshedding,” the moment it starts.