Please, Not Another Standup: The Case for Letting British Developers Actually Do Some Work

It is 9:47 on a Tuesday morning. Somewhere in Britain, a developer has just achieved what psychologists call a state of flow. The problem they've been circling for three days has suddenly become tractable. The code is moving. The logic is clicking. The solution is right there, almost visible, just a few more minutes of uninterrupted—

"You're muted, by the way."

The standup has begun.

A Brief History of How We Got Here

The daily standup has noble origins. Borrowed from agile methodology and popularised by Scrum, it was designed for teams building complex software who needed rapid alignment without the overhead of lengthy planning sessions. Fifteen minutes. Three questions. What did you do yesterday? What are you doing today? Is anything blocking you?

In theory, it's elegant. In practice, across a significant portion of the UK's software industry, it has metastasised into something considerably less useful — a ritual performance of productivity that consumes the very time it was meant to protect.

For larger enterprise teams coordinating across departments, some version of this ceremony perhaps still makes sense. But for the indie developers, small studios, and boutique software shops that make up a vibrant chunk of Britain's tech ecosystem? The daily standup has become a millstone dressed up as a methodology.

The Mathematics of Interruption

Let's do some uncomfortable arithmetic. A team of five developers. Each standup takes twenty minutes — because they always take twenty minutes, regardless of what anyone tells themselves. That's one hundred developer-minutes per day, five hundred per week, roughly twenty-six thousand per year.

But the real cost isn't the meeting itself. It's the context-switching either side of it. Research into developer productivity consistently finds that recovering full concentration after an interruption takes anywhere from fifteen to twenty-three minutes. Schedule a standup at 10am and you've effectively written off the entire productive morning for anyone who was in flow. Schedule one at 2pm and you've done the same to the afternoon.

For a small team trying to ship actual software, this isn't a minor inefficiency. It's an existential threat to momentum.

The Peculiarly British Problem

There's a cultural dimension to this that's worth naming. British workplace culture has a complicated relationship with the appearance of diligence. Being seen to be busy — attending meetings, filling calendars, demonstrating visible participation — can carry as much social weight as actually delivering results. The standup, in this context, functions partly as a collective reassurance ritual. We are all here. We are all engaged. Nobody is quietly watching football.

This instinct is understandable. It's also, for smaller teams where trust should already exist by default, a fairly expensive way to manage anxiety.

The irony is that the teams most likely to over-invest in meeting culture are often the ones who can least afford it. A startup with four developers has no slack in the system. Every hour lost to process theatre is an hour not spent building the thing that pays everyone's salaries.

What Asynchronous-First Actually Means

The phrase "async-first" has become something of a buzzword in remote-work circles, which is a shame, because underneath the jargon is a genuinely practical set of principles that small teams can adopt without a wholesale cultural revolution.

At its simplest, async-first means defaulting to communication methods that don't require everyone to be present simultaneously — and reserving synchronous time for conversations that genuinely benefit from it.

Here's what that looks like in practice:

The written standup. Instead of a video call, team members post a brief update to a shared channel — Slack, Notion, a shared doc, whatever you're already using — at a time that suits them. Three bullet points. What's done, what's next, what's blocked. Takes two minutes to write, thirty seconds to read. Nobody loses their flow state. Nobody has to remember to unmute.

The weekly sync. Rather than daily check-ins, a single weekly video call — properly structured, with an agenda, with a defined end time — handles the conversations that actually benefit from real-time discussion. Problem-solving, planning, anything emotionally complex. Everything else lives in writing.

The working-out-loud document. A shared space where developers log what they're working on in real time — not for surveillance, but for coordination. If someone gets stuck, the context is already written down. If someone needs to pick up a task, they're not starting from scratch. It sounds fussy until you've tried it, at which point it becomes indispensable.

The explicit "do not disturb" norm. Perhaps the most powerful change of all: agreeing as a team that deep work time is protected, that pinging someone in flow is the exception rather than the default, and that a response delay of a few hours is not a crisis requiring immediate escalation.

The Objections (And Why They're Mostly Wrong)

"But how do I know what everyone's doing?" You know because they've written it down, which is actually more reliable than a verbal update delivered at speed to a camera.

"What if something urgent comes up?" Genuinely urgent things — production down, client emergency, actual crisis — bypass async norms by definition. The problem is that most things labelled urgent aren't. They're merely impatient.

"Won't the team feel disconnected?" Possibly, if async is implemented badly. The solution is intentional social connection — a Friday afternoon video call that's explicitly not about work, a team lunch, a Slack channel for sharing things that are funny or interesting. Connection doesn't require constant synchronisation.

In Defence of Boring Productivity

There is nothing glamorous about protecting your team's calendar. It won't make for an exciting blog post or a compelling investor narrative. But the small software shops getting things done — actually shipping, actually growing, actually maintaining the kind of team culture that doesn't haemorrhage developers every eighteen months — are often the ones who've quietly decided that meetings are a cost, not a feature.

The beermat, as a metaphor, is instructive here. The best ideas are compact. They don't require a two-hour planning session to communicate. They fit in a sentence, or a bullet point, or a brief written message sent when the timing suits the sender rather than the calendar.

Cancel the standup. Write it down instead. Let your developers find their flow and stay in it.

The software will thank you.