Three Teams, One Feature, Zero Coordination: The Silent Fracture of Remote British Dev
Somewhere in a flat in Leeds, a developer is building a notification system. In a spare bedroom in Bristol, another developer is also building a notification system. In a WeWork in Shoreditch — because of course there is — a third developer is building what they're calling an "alert pipeline," which is, when you squint at it, also a notification system.
None of them know about the others. All three are on the same team.
This is the postcard problem, and it is quietly eating British software from the inside.
What Happens When You Can't Tap Someone on the Shoulder
Before remote work became the default setting for half the UK tech industry, there was a deeply underrated communication channel: proximity. The two-second corridor conversation. The accidental overhear. The moment someone says "oh, I'm doing something like that" while waiting for the kettle to boil, and suddenly you've avoided three weeks of parallel development.
Those moments don't happen on Slack. They definitely don't happen in a Tuesday standup where everyone says "yeah, good" and disappears back into their screens.
What you get instead is something like a postcard: a small, flat, carefully composed message that travels slowly, tells you only what the sender chose to share, and arrives after the moment has already passed. Remote communication, even at its best, is asynchronous, edited, and incomplete. You write what you think is relevant. You don't write the thing you didn't know was relevant.
And so, silently, the codebase forks.
The Anatomy of Accidental Duplication
It doesn't happen dramatically. Nobody stands up in a meeting and announces they're going rogue. It happens in the margins — in the space between a vague ticket description and a developer's entirely reasonable interpretation of it.
Feature requests in British tech companies are, as a rule, heroically ambiguous. "Users should be notified when something happens" is a real sentence that real product managers have written in real JIRA tickets. Left to their own devices — which, in a distributed team, they very much are — three developers will produce three architecturally incompatible answers to that sentence, all of them defensible, none of them compatible.
By the time anyone notices, each solution is partially deployed, partially tested, and partially beloved by its creator. Merging them is no longer a technical problem. It's a diplomatic incident.
The Codebase as Archaeological Site
The long-term consequence of this kind of silent divergence isn't just duplicated effort — it's a codebase that starts to resemble an archaeological dig. Layer upon layer of decisions made independently, in isolation, by people who were all trying to do the right thing and had no idea anyone else was doing it differently.
Future developers inherit this. They find three utility functions that do the same thing with slightly different edge case handling. They discover two database schemas that almost overlap. They encounter a module that was clearly written by someone who didn't know the other module existed, and vice versa.
Technical debt, in this form, isn't caused by laziness or corner-cutting. It's caused by distance. By the absence of the casual, unscheduled, uncaptured conversations that used to hold a shared mental model together.
This is not an argument against remote work. It's an argument against unmanaged remote work, which is what most British tech companies have accidentally ended up with.
The Messaging Thread That Could Have Saved Everything
Here's the uncomfortable truth: most of these divergence disasters are preventable, and the prevention doesn't require everyone to commute back to an open-plan office in Farringdon. It requires something much simpler and considerably cheaper: a culture where people share what they're starting, not just what they've finished.
The pull request is too late. By the time code is up for review, the architecture has been decided, the assumptions are baked in, and the developer has emotional investment in their approach. The moment you needed was three weeks earlier, when they were staring at the ticket and wondering where to begin.
What that moment requires is a low-friction way to say "I'm thinking about building X" and have someone reply "oh, interesting — Sarah's doing something adjacent, have you spoken to her?" That's not a process. That's a culture. And it's a culture that remote teams have to actively construct, because it doesn't emerge naturally from a grid of faces on a video call.
Some teams use working-in-public channels. Some use short daily written updates that go beyond "working on ticket 447." Some use architecture decision records that are actually read by people who didn't write them. The specific mechanism matters less than the underlying principle: your team needs to know what your team is doing, in real time, at the level of intent rather than just delivery.
Scribble It on Something Before You Build It
At Beermat Software, we're obviously fond of the idea that the best ideas start small and scrappy — a sketch, a scrawl, a rough shape of a thing before it becomes the thing. The same logic applies here.
Before anyone writes a line of code, write a sentence. One sentence, shared somewhere everyone can see it: "I'm planning to build a notification system that does X using Y approach." Post it in the team channel. Wait twenty minutes.
If nobody replies with "hang on," you're probably fine to proceed. If someone replies with "oh god, please don't, I'm already halfway through something like that," you've just saved yourself a month of archaeology and a very awkward retrospective.
The postcard problem isn't really about postcards. It's about the assumption that everyone on your team has the same picture in their head that you have in yours. They don't. They never did. The office just used to paper over that gap with noise and proximity and the occasional biscuit-tin conversation.
You've taken the biscuit tin away. You're going to have to replace it with something.
