Death by Deck: How Alignment Meetings Ate British Software Alive

There is a specific kind of grief that British software developers carry around with them. It's not the grief of a failed launch, or a missed deadline, or even a production incident at 11pm on a Friday. It's quieter than that. More bureaucratic. It's the grief of watching something genuinely brilliant get talked to death in a conference room that smells faintly of stale biscuits and broken dreams.

The meeting that killed the product. You've been in one. You might be in one right now.

It Started So Well

Picture the scene. A developer — let's call her Sarah — has spent three weeks quietly solving a problem that's been quietly annoying everyone for three years. Her solution is scrappy, fast, and works beautifully. It fits on a beermat. Literally. She sketched the core logic on one during a particularly dull all-hands and had a prototype running by Thursday.

Then someone suggested she 'present it to the wider team.'

This is where things go wrong. Not dramatically. Not with a single catastrophic decision. British corporate culture doesn't do dramatic. It does gradual. It does iterative degradation disguised as process.

By the second meeting, Sarah's elegant three-screen tool has acquired a dashboard nobody asked for. By the fourth, there's a working group. By the sixth, a PowerPoint deck with seventeen slides, a RAG status report, and a slide titled 'Alignment Considerations' that contains the sentence: 'We need to ensure all key stakeholders are on the same page before proceeding to the build phase.'

The prototype still works. But nobody's looking at it anymore. They're all looking at the deck.

Why Britain Is Especially Vulnerable to This

Other tech cultures have their own dysfunctions, naturally. Silicon Valley drowns good ideas in pivot pivots and vibe shifts. German engineering culture occasionally disappears up its own specification document. But Britain has a particular weakness: we are pathologically polite about bad meetings.

We sit through them. We nod. We say 'that's a really interesting point' when what we mean is 'please stop talking so we can go and actually build something.' We schedule a follow-up to discuss the follow-up. We cc people who don't need to be cc'd because leaving them off feels rude.

This isn't a character flaw, exactly. It's a cultural feature that works brilliantly in diplomacy and absolutely catastrophically in product development.

The meeting industrial complex thrives in British tech shops precisely because challenging it feels impolite. Saying 'I don't think this meeting is necessary' is treated with roughly the same social horror as turning up to a funeral in a novelty hat. So we don't say it. And the meetings multiply.

The Anatomy of a Product Murder

Having spoken to a frankly depressing number of indie developers and small studio founders across the UK, a pattern emerges with uncomfortable consistency.

Stage one: The enthusiasm phase. Someone builds or specifies something good. Momentum exists. A small group of people who understand the problem are genuinely excited.

Stage two: The visibility problem. The idea gets noticed by people outside the core group. This sounds like a good thing. It is not.

Stage three: The alignment request. A meeting is called to 'make sure everyone's across it.' The people who understand the problem are now outnumbered by people who don't but have opinions anyway.

Stage four: The feature negotiation. Each stakeholder, feeling the social pressure to contribute something, suggests an addition. Nobody suggests removing anything. The original elegant solution begins to accumulate requirements like a ship accumulating barnacles.

Stage five: The rebrand. Someone decides the name isn't quite right. A naming workshop is scheduled.

Stage six: The silence. The original developer, somewhere around meeting nine, stops mentioning the prototype. It still works. It's just no longer the point.

The product that eventually ships — if it ships at all — bears the same relationship to the original idea as a camel bears to a horse: technically functional, deeply ungainly, and designed by committee.

What Actually Works

The developers who've managed to protect their best work from this particular fate tend to share a few habits that are worth nicking shamelessly.

Ship before you present. Getting something in front of real users — even rough, even incomplete — before it enters the meeting circuit is the single most effective protective measure available. A working thing is much harder to committee-design into oblivion than a slide about a working thing.

Name the meeting tax explicitly. Some founders have started keeping an actual log of hours spent in alignment meetings versus hours spent building. Showing this number to a room of people who've just scheduled another meeting has, reportedly, a clarifying effect.

Protect the prototype. Treat early-stage work the way you'd treat a vulnerable species. Keep it away from large groups. Let it develop in a controlled environment. Introduce it to stakeholders gradually, and only after it's robust enough to survive contact with someone who wants to add a reporting module.

Make the beermat the artefact. Literally. If your idea genuinely fits on a beermat — and the best ones do — keep that beermat. Bring it to meetings. When someone suggests a new requirement, ask them to show you where it fits on the beermat. If it doesn't fit, it probably doesn't belong in version one.

Declare meeting bankruptcy. Several indie studio founders have described a moment of clarity where they simply stopped attending certain categories of meeting entirely and waited to see if anyone noticed. The results were, by their accounts, revelatory. Often, nobody noticed.

The Broader Point

None of this is an argument against collaboration. Some of the best software gets built by people arguing productively in a room together. The difference is that productive argument is about the work. Alignment meetings, at their worst, are about the appearance of the work — about making sure everyone feels included, informed, and consulted, regardless of whether any of that actually improves the outcome.

Britain has produced extraordinary software precisely when developers have been left alone long enough to finish a thought. The scrappy, brilliant, slightly weird solutions that come out of small teams with clear problems and minimal interference — that's the tradition worth protecting.

Sarah's prototype, by the way, still runs on her laptop. She demonstrated it to a friend at a startup event six months after the working group dissolved. The friend's company licensed it within a fortnight.

The PowerPoint deck, as far as anyone knows, is still in SharePoint. Slide twelve has a typo that nobody ever fixed.

Some things, it turns out, are better scribbled on a beermat and shipped quietly before anyone has time to schedule a meeting about them.