Parkinson's Law of Triviality

The shed gets forty-five minutes. The reactor gets two and a half.

October 14, 2026 8 min read

Picture the agenda from a sixty-minute product review, with how long each item took:

Nobody set out to run the meeting this way. Everyone in the room had a view on the sidebar label, so everyone shared it. The queue migration was presented by the one engineer who had designed it, nobody had a question ready, and it passed. The retention item was read aloud and accepted.

The decisions that will be hardest to change got the least attention, and they probably left the least behind in writing.

Parkinson's committee

C. Northcote Parkinson described this pattern in his 1957 book Parkinson's Law, in a chapter called "High Finance, or the Point of Vanishing Interest." He stated it as a law: "the time spent on any item of the agenda will be in inverse proportion to the sum involved."

His illustration is a fictional finance committee. It approves a nuclear reactor in two and a half minutes, then spends forty-five minutes on a bicycle shed for the staff. Parkinson's point was that this isn't carelessness. Very few members understand a reactor well enough to question it, and every member knows what a shed is.

The idea got its common software name in 1999. Poul-Henning Kamp, a FreeBSD developer, emailed FreeBSD's committers and hackers mailing lists after a long thread over a small proposed change to sleep(1), and summarized Parkinson's example in it. The email turned "bike shed" into shorthand for arguing over the trivial thing.

Two forces behind it

Kamp's email names both of them clearly.

The big decision is hard to grasp, so people assume it was checked. Summarizing Parkinson, Kamp writes that an atomic plant is "so vast, so expensive and so complicated that people cannot grasp it, and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far." Silence in the meeting reads as agreement, when it may only mean nobody felt able to ask. That is the same gap the approval theater post describes: a sign-off that looks like review without being one.

The small decision is easy to grasp, so everyone takes part. "Anyone can build one of those over a weekend," Kamp writes of the shed, and so somebody "will seize the chance to show that he is doing his job, that he is paying attention." Commenting on the button color is cheap, visible, and safe. Asking a basic question about the event queue risks looking uninformed.

Together, those two forces move the team's scrutiny away from the decisions that most need it.

Why coding agents make this worse

Coding agents can produce a lot of small, easy-to-follow changes. A pull request that renames twelve files and adjusts formatting gives reviewers plenty to comment on. If the same pull request also adds a dependency or changes how a table is keyed, that line sits among hundreds of others, and the law of triviality suggests it is the one least likely to get discussed.

The decision inside that line may never be stated anywhere. The agent made a reasonable choice given what it could see, and the review spent its attention on the parts everyone could follow. Months later, the team can end up living with a choice nobody remembers making.

A short check for your next meeting or review

1. Which item here is hardest to reverse? If you can't tell, that's the first thing to discuss. One-way and two-way decisions deserve different amounts of time, which the one-way doors post covers in more depth.
2. Did the hardest-to-reverse item get its share of the time? A rough match is enough. A four-minute pass on a migration, or a one-minute pass on a retention promise, is a signal, whatever the reason.
3. Is the reasoning for the big decision written down somewhere a newcomer would find it? If the only record is "approved," the meeting kept the outcome and lost the reasons.

None of these stops people from enjoying the shed. They just make sure the reactor doesn't pass on silence.

Where this fits at Brief

Bikeshedding is a problem of attention, and no tool can make a meeting care about the right item. What a team can fix is what the big decision leaves behind after its four minutes, and whether later work runs into it. Follow the queue migration from the agenda above through Brief.

After the meeting, one more minute. The engineer who designed the migration goes back to the Slack thread where the design was discussed and mentions Brief to log it. Brief reads the surrounding thread for context and proposes a structured decision to confirm or edit, as the Slack integration guide describes. Typing /decide with the decision and its reason works too, with a preview to confirm before it is logged. Once confirmed, Brief saves the decision with its rationale, the person who logged it, the time, and the channel. A decision made outside Slack can be recorded from the terminal with brief decisions create --decision "..." --rationale "...". Either way, the rationale is where the minute goes: "Move integrations to an event queue, because direct writes block on slow providers and give us no retry. Revisit if queue lag becomes visible to customers." That extra minute leaves a reason someone can test later, which "approved" in the meeting notes doesn't. The one-minute retention promise deserves the same treatment, since it is the one a security review will ask about.

Six weeks later, an agent meets the decision. An engineer asks a coding agent to add a billing integration, and the agent plans to write straight to the database, the way the older integrations did. If the engineer or the agent runs that plan through brief ask --mode check, which validates an approach against the team's existing decisions, the check can flag the conflict with the queue decision before any code exists. Nobody had to remember the four-minute agenda item. This is how the imbalance gets partly repaid: the decision that got the least human attention is still there for a later plan to be checked against, as long as someone recorded it and the agent runs the check.

Next quarter, the shed comes back. Someone proposes renaming "Projects" back to "Workspaces." If the label was recorded, the new decision can be marked as replacing the old one, and the earlier call stays readable as history (see supersession). The new debate can start from the reasons the team already gave, instead of from scratch.

Brief doesn't decide which agenda item deserves the time, and it doesn't rank decisions by importance on its own. It holds what someone confirms or writes down, so a four-minute decision with a one-word rationale is still a one-word rationale, and a check helps only if the agent runs it. What it changes is how far a quick decision travels. Once its reasons are on record, the item that got the least discussion can still shape the work that follows.

Which decision from your last planning meeting got the least discussion, and could anyone find its reasoning today?

Frequently asked questions

What is Parkinson's law of triviality? The observation that groups spend time on agenda items in inverse proportion to the sum of money involved. C. Northcote Parkinson described it in his 1957 book Parkinson's Law, with a fictional committee that approves a nuclear reactor in two and a half minutes and spends forty-five minutes on a bicycle shed.

Where does the term "bikeshedding" come from? From Parkinson's bicycle shed example. Poul-Henning Kamp, a FreeBSD developer, retold the example in a 1999 email to FreeBSD's developer mailing lists, and "bikeshedding" became the common software term for arguing over trivial details.

Why does the law of triviality happen? Parkinson's explanation, as Kamp retold it, involves two forces. Complex decisions are hard to grasp, so people assume someone else has checked them and stay quiet. Simple decisions are easy to grasp, so everyone can offer an opinion and show they are paying attention.

How does Brief help with bikeshedding? Brief records decisions with their rationale, who logged them, and when. When someone mentions Brief in a Slack thread, Brief reads the thread and proposes a decision for them to confirm or edit. Coding agents can check a planned change against those recorded decisions with brief ask --mode check. Brief doesn't decide which decisions deserve discussion; it keeps the reasoning for the ones a team records.