Parkinson’s Law of Triviality

Some ideas have the rude honesty of a mirror. You glance, you laugh, and then you realize you’ve been doing that exact thing all week.

C. Northcote Parkinson coined one of my favorite organizational mirrors: Parkinson’s Law of Triviality. The short version is simple and slightly depressing in a funny way: groups often spend more energy debating small, familiar issues than big, complex ones.

Parkinson illustrated it with a finance committee that has three items on the agenda.

One is massive and technical: approving an expensive atomic reactor. It slides through quickly, partly because it is intimidating, partly because it is abstract, and partly because nobody wants to look foolish arguing about a thing they don’t fully understand.

Then comes a tiny proposal: building a bicycle shed for staff. Now everyone perks up. A bike shed is concrete. You can picture it. You can argue about the roof, the materials, the necessity, the placement. It is manageable, and in a meeting, manageability is catnip.

Finally, refreshments. Coffee. The most dangerous agenda item of all, because everyone is suddenly a subject matter expert.

Parkinson’s point is not that bike sheds or coffee don’t matter. His point is that familiarity creates loud confidence, and loud confidence attracts time. In his own words, speaking about the bicycle shed: “A sum of $2,350 is well within everybody’s comprehension.”

If you work in software, you have seen this creature in the wild.

The architecture decision that will shape your system for three years gets a polite nod and a “let’s circle back.”
Then the team spends forty minutes debating whether the button should be “Save” or “Submit,” whether the folder name should be utils or helpers, or whether the code formatter is “too aggressive.”

It is not stupidity. It is human scaling behavior. Our brains reach for the terrain they can walk barefoot.

The “bikeshed” idea became a well-known software shorthand largely because of a particularly clear, quotable explanation in the FreeBSD FAQ. That write-up is famous in developer circles for turning Parkinson’s abstract example into a practical warning: if you don’t intentionally steer discussion, teams will naturally gravitate toward the most graspable details, not the most important decisions.

I have a soft spot for these observations, the little laws that explain why groups behave like weather systems with agendas. Public administration is full of them, and software teams are basically public administration with more keyboards and fewer clearly defined nouns.

If you know other “laws of the kind” that help explain how organizations drift, stall, or accidentally self-sabotage, drop a link in the comments. For example: Conway’s Law (org charts shaping systems), the Peter Principle (promotion until incompetence), Brooks’s Law (adding people to a late project makes it later). I collect these like some people collect stamps, except mine are made of human nature and mild despair.

References

1. C. Northcote Parkinson, biography (Wikipedia): https://en.wikipedia.org/wiki/C._Northcote_Parkinson
2. Parkinson’s law of triviality (Wikipedia): https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality
3. “Why should I care what color the bikeshed is?” (FreeBSD FAQ): https://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING