This essay expands on the “Boundaries and Responsibility” thread in Management Retrospective.

Not all duplication is waste. After moving into management it took me a while to accept this — “avoid duplication” sounds so obviously correct that you forget its other side.

System backups, review of critical decisions, and important capabilities held by more than one person — these are all healthy redundancy for disaster recovery. What they share is a clear purpose, an acceptable cost, and clear boundaries of responsibility. No one accuses a database of “duplicative construction” just because it has a replica, and no one seriously objects to a critical service having two people who can take it over.

Harmful overlap is organizational horse racing

Harmful overlap is more like organizational horse racing: teams grab resources, reporting lines, and projects from one another, turning goals that could have been collaborative into zero-sum competition. It usually isn’t because someone suddenly turned bad, but because authority is unclear, the organization fails to act, or competition substitutes for real prioritization — ultimately pushing people into involution, exhaustion, and defensiveness.

The most common starting point is the surface rationale of “avoiding dependence”: two teams each build similar capabilities, claiming they don’t want to be at someone else’s mercy, when what they actually worry about is often losing resources to the other side — while no single person is clearly responsible for the final problem. So duplicative construction, fighting over reporting, and mutual defensiveness keep intensifying. There are no villains here, only one question nobody answers: who is actually responsible for this?

To spot it, you can’t just look at the schedule

On paper, “each owns a piece” usually looks clean. To identify harmful overlap, you have to ask a few sets of questions:

  • Why are different teams doing similar things? Are the goals they’ve been given in conflict?
  • Who has the final say?
  • Is anyone hiding information out of fear of losing resources?
  • Do the reporting line and the real workflow give the same answer?

The last one matters most. The reporting line answers “who reports to whom,” while the real workflow answers “who is actually solving the problem”; these two structures often aren’t the same thing — a division of labor that looks clean on the reporting line can turn out to be overlapping in the real workflow.

The core of governance is authority, not banning duplication

The focus of governance isn’t “no duplication” but making authority clear:

  • Who owns this problem (problem owner)?
  • Who owns the interfaces?
  • When is a joint review needed?
  • When should the horse race stop and the decision be escalated?

Answer these clearly, and duplication returns to where it belongs: what remains is disaster recovery (backup of the critical path, review, substitutability), and what gets removed is the zero-sum horse race. Once authority is filled in, one of the duplicate paths naturally closes — the part that remains is disaster recovery, not a horse race.

The difference isn’t in “how many copies were made”

The difference between healthy redundancy and harmful overlap isn’t in “how many copies were made” but in whether they jointly serve an explainable goal. Doing the same thing twice — if both copies point to the same user outcome and are coordinated by a clearly accountable owner, it may be disaster recovery; if the two go their own way and fight over the same budget pool, it’s a horse race.

To decide whether a duplication should be cut, I ask one question: after cutting one of the copies, does the remaining one’s goal become clearer? If so, the duplication probably should be cut; if cutting it makes people worry there’s no one to fall back on when something breaks, then it’s redundancy worth keeping.

In the end, make every duplication able to say what it protects. What can’t say so is the overlap to be removed.