In 1957, British author C. Northcote Parkinson described a fictional committee with three items on their agenda. First: signing a £10 million contract to build a nuclear reactor. Second: a proposal to build a £350 bicycle shed for the clerical staff. Third: £21 a year to supply refreshments for the committee itself.
The fictional committee’s decision for the reactor took two and a half minutes. The bike shed took forty-five. The refreshments took seventy-five minutes and produced no decision at all.
Parkinson called this the Law of Triviality. The time spent on any item will be in inverse proportion to the sum of money involved.
- The more complex and consequential the thing, the less time it gets.
- The more graspable and inconsequential, the more time it gets.
- The most trivial thing of all will consume the most time and still go unresolved.
He explained: a nuclear reactor is so vast, so expensive, and so complicated that people cannot grasp it quickly or easily, and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far. A bike shed, on the other hand — anyone can build one of those over a weekend. So no matter how reasonable the proposal, somebody will seize the chance to show that they are doing their job, that they are paying attention, that they are here.
The terms bikeshedding and bike-shed effect came later, popularized in software development communities. But the phenomenon was already everywhere. Including in game development.
Why Everyone Has An Opinion On The Narrative
I’ve watched the same thing happen in game pitch presentations to the teams that will make them more times than I can count. The team gathers, the pitch goes up, and within minutes the room has strong opinions — almost always some of those opinions will be concentrated on the narrative. The story. The characters. The lore. Meanwhile the gameplay systems, the technical architecture, the things that will actually determine whether the game is functional or fun to play, get a fraction of the attention at that time.
Why? Someone once put it to me in a way I’ve never forgotten: “Everyone thinks narrative is just making things up, so everyone thinks they can do it — and most will try when an opportunity arises.” (His words, not mine — a deeper post regarding this thought is in the works.)
That’s bikeshedding in one sentence. Narrative feels accessible. Everyone has consumed stories their whole lives. Everyone has opinions about whether a character is compelling or a plot point lands. The game’s core loop, its systems design, its technical feasibility — these require specific knowledge most people in the room don’t have individually, and rather than admit that, they engage with what feels safe to engage with.
To go back to the Northcote Parkinson example, the reactor sits there getting two and a half minutes while everyone debates the bike shed for forty-five. The game’s most important questions go unexamined in the moment while the room argues about the protagonist’s name.
The PowerPoint Problem
It doesn’t only happen with features and pitches. Bikeshedding shows up in leadership moments too.
I gave a presentation once. The slide deck had some technical issues during the run — nothing catastrophic, just the kind of thing that happens. I made a few gentle self deprecating jokes, the way you do when you’re trying to keep the energy light and the room with you (especially in a time when most people are watching the presentation over an online conference call and not in a room together). It landed fine. The presentation overall went well.
Afterward, my manager pulled me aside to make a significant point about what they believed was me being “unprofessional” in regards to the jokes. That was the debrief. Not a word about the presentation itself. Not a word about how the room responded, what landed, what didn’t, what it meant for the project. Just the jokes.
I don’t tell this story to relitigate it. I tell it because in my opinion it’s a perfect example of what bikeshedding can look like outside a meeting room. The joke was the bike shed — visible, graspable, easy to have a reaction to. The presentation and its implications for the project and the team were the reactor — complex, consequential, harder to engage with. My manager chose the bike shed. The reactor sat there untouched.
Two Tools
There isn’t a cure for bikeshedding. It’s human nature doing exactly what human nature does — gravitating toward what feels manageable, engaging with what feels safe. But awareness helps, and having the language helps more. If everyone in a room knows what bikeshedding is, you can say “I think we’re bikeshedding” and the dynamic shifts. A pattern with a name can be interrupted. A pattern without one just continues. Give everyone on your team the tool and understanding to break the pattern early in a project — maybe even at the same time as the pitch presentation.
Beyond naming it, there are two tools worth having.
The first is a razor — something you apply quietly to yourself in real time. When a discussion starts consuming more time than feels proportionate, ask: what’s the actual cost if we get this wrong? If the answer is small, you’re probably in a bike shed. If the answer is large and nobody is talking about it, you’re almost certainly in one. The razor is diagnostic. It tells you where you are. You can use it privately, without saying a word, just to orient yourself.
The second is a dagger — something you deploy when recognition alone isn’t enough and the room needs redirecting. Ask out loud: why does everyone have a strong opinion on this particular thing? The question answers itself the moment it’s in the air. People feel it. The accessibility of the topic suddenly becomes visible, which makes the inaccessibility of the thing nobody is discussing visible too. It’s a more pointed move than the razor, but used well it doesn’t feel like an attack — it feels like a genuine question that happens to reframe the entire conversation.
The razor for recognizing it. The dagger for naming it when someone else needs to see it too.
The Reactor Is Still Waiting
In the Northcote Parkinson example, the refreshments took seventy-five minutes and produced no decision. Somewhere in that same meeting, a ten million pound reactor sat largely undiscussed, its details assumed to have been checked by someone, somewhere, at some point before now.
In game development the reactor is usually the thing that will actually determine whether the game works — the systems, the loop, the technical foundation, the question of whether this thing is actually fun to play. And the bike sheds are everywhere: the narrative, the font, the shape of a customizable reticle, the rip-o-matic made from no actual game footage, the joke someone made during a presentation.
None of those things are unimportant. But they’re not the reactor. And the reactor can’t argue for itself.