Somewhere in your organisation, two teams are solving the same problem and neither of them knows about the other. When you find out, your instinct will be to stop one of them. Hold that instinct, because the alternative you are picturing, one team and one clean solution, is rarely the alternative on offer. The real choice is usually between having two of something and having none of something, and plenty of engineering organisations quietly choose none.

Compare against zero, not against one

When a leader finds duplicated effort, they measure it against a tidy hypothetical: one team, one implementation, half the spend. That hypothetical is fiction. Getting to a single shared solution means both teams stop, agree a common set of requirements, negotiate whose use case wins, and settle who owns the result. Requirements that satisfy everyone satisfy nobody, the design swells to cover every edge case, and a quarter later you have a document and no software.

Amazon named this trade-off. Alongside two-pizza teams and single-threaded leadership sits a less quoted piece of the operating model: tolerating, then eliminating duplication. One working solution is ideal, but two working solutions beat none. The line I heard repeated inside Amazon was simpler again. Better to have two of something than none of something.

Not all duplication costs the same

Internal tooling is where this plays out most often. Any engineering organisation of a decent size has half a dozen homegrown admin panels, back-office screens and operational scripts, roughly one per team, all doing broadly similar things. Look up a customer, replay a failed job, correct some bad state. It looks like textbook waste, and it reliably triggers the same response, which is a project to build the one internal tools platform that everybody will use.

That project has a well-known ending. It runs for three quarters, lands as a general-purpose abstraction, and the teams quietly keep their own screens because the new thing cannot do the specific operational task they needed it for. Each of those original panels took two or three days, was shaped exactly to how that team runs its service, and gets deleted without ceremony when the workflow changes. The duplication was never the expensive part. The attempt to remove it was.

So the question is not whether a thing is duplicated. It is what the duplication costs to keep and what it costs to unwind. Six admin panels are a two-way door, contained and thrown away by whoever stops needing them. Six ways of handling payments, authentication or customer records are not, because the copies drift and the drift arrives as an incident. Leaders who go hunting for waste tend to find the harmless kind first, because it is the kind you can see on a diagram, and they spend their credibility there.

Treat coordination as the expensive thing

Duplication is easy to see. Two services doing the same job turn up in an architecture review and look like obvious waste, which makes them a satisfying thing to go and fix. Coordination cost appears nowhere. Nobody logs the fortnight lost waiting on another team's roadmap, or the improvement dropped because agreement was harder than building.

Communication is a sign of dysfunction.Jeff Bezos, quoted in The Everything Store

His argument was that teams should be designed to need less of it, not more. The point was never that talking is bad. A constant need to coordinate means your architecture and your org chart are wrong, and scheduling more meetings treats the symptom.

Make ownership the price of autonomy

This is the part people drop when they import the idea, and dropping it gets you sprawl instead of speed. Tolerating two solutions is only affordable when whoever builds a thing carries it. You build it, you run it. A team that will be woken at 3am by its own service thinks hard before standing up a second one for the fun of it, and that consequence prevents more pointless duplication than any approval gate. Autonomy without ownership is just permission to make a mess somebody else cleans up.

Tolerate, then eliminate

The second half is not decoration. Tolerating duplication defers a decision, it does not cancel it. When you let two efforts run, say out loud what would tell you which one won and when you will next look. Often it resolves itself, because one team keeps investing and the other loses interest. Consolidation is also far easier once you have two working things and real usage data than it was back when both options were slide decks and everyone was defending a position rather than a product.

Let standards win adoption rather than mandate it

If a platform team needs a policy to get anyone onto its platform, the platform is not good enough yet. Tools that spread without a memo spread because they solve the problem better, and the teams that chose them keep them alive. Mandates produce compliance, workarounds, and a maintenance burden nobody volunteered for. Reserve them for the narrow set where drift becomes an incident. Past that boundary, uniformity is an aesthetic preference dressed up as an efficiency argument.

The trade has moved further in your favour

Werner Vogels wrote in June about a group of Amazon scientists who realised they had each been circling the same problem. Rather than convening to sort out the overlap, one of them spent a night with a coding agent and demoed a working prototype the next day. Within hours the project had an owner for each major piece. Under an older model, that overlap would have been a duplication problem to resolve before anyone was allowed to build anything.

The cost of the second implementation has collapsed. The cost of the meeting held to prevent it has not moved at all. Every argument for tolerating duplication is stronger than it was two years ago, and the leaders still optimising for tidiness are paying a worse price than they used to.

The short version

Compare against zero, not against one. Treat coordination as the expensive thing. Make ownership the price of autonomy. Tolerate duplication, then go back and eliminate it. Let good standards win on merit. None of this is a licence for chaos, and none of it will comfort a leader who takes pride in a clean architecture diagram. But a slightly untidy organisation that ships beats an immaculate one that is still aligning.