Fix what exists before you build something new

One of the first pieces of work I did inside a large federated organisation was an audit of its public-facing directory, the page that tells someone where their nearest branch is and how to get in touch with it. A meaningful share of the links no longer worked.

Nobody had decided to let them rot. Each branch had made its own choice about its own website, or made no choice at all, and the broken links piled up over years, unnoticed, because nobody had the job of noticing them. There are thousands of those branches, each legally its own thing, with no head office able to issue a single instruction and only a shared sense of belonging holding it together.

Something breaks in a long-running organisation and the reflex is to commission something new: a platform, a tool, a fresh workstream. I think that reflex is usually wrong. The better move, the one that rarely gets funded and never gets a launch date, is to look hard at what’s already there and fix it before building anything else.

We didn’t build anything new to fix the directory. We spent a few weeks correcting the data: checking every link, updating the ones that had moved, removing the ones that pointed nowhere. No new platform, no new feature, nothing to demo in a board meeting. What changed was that someone looking for their nearest branch could now find it and get in touch, which had not reliably been true the week before.

I should say that I’m no better at this than the organisations I’m about to describe. On a personal software project, with no board and no politics involved at all, it was easier to add a new feature than to go back and write tests for what already existed or check that the basics were in place. There was no sponsor to impress and no launch to schedule, so what a board can see cannot be the whole explanation. The pull towards the new thing is a habit, and the size of the organisation only decides how expensive it is to indulge.

Why repair loses the argument

Building something new is visible. It has a launch date, a name, a screenshot on a slide. You can point at it and say: we did that. Fixing what already exists has none of that shape. There is no moment when a broken link becomes a working one that anyone watching from a distance would notice.

So organisations that have been running for decades, the ones with the most to repair, systematically under-invest in repair and over-invest in new builds. A board can approve a new platform and see, in outline, what it bought. A board asked to fund six months of fixing something that should already work can’t see anything bought at all. It looks, from where they sit, like nothing happening.

The people who run these systems day to day can describe exactly what’s wrong, because they work round it every week. By the time the same problem reaches the people who allocate money it has been abstracted into something that sounds as though it works, and a new system is what usually gets bought.

What federation does to this problem

Federation makes this worse. In an ordinary hierarchy, someone can at least be told to go and fix the directory. In a federation, made up of legally separate parts that share a name and not much else in the way of authority, there’s no one whose job it is to notice the links are breaking, and no one who can instruct hundreds of branches to check their own page. The breakage happens because the problem belongs to everyone in general and no one in particular.

The same shape that makes the fix hard to notice also makes it hard to sell. A single new platform gives a federation something rare: one thing every part can be shown at once, a shared moment that looks like progress to all of them at the same time. A repair effort is the opposite. It’s hundreds of small, separate, unglamorous corrections, each one invisible to every branch except the one it happened in. There was no launch event for the directory, and no way to show hundreds of separate corrections to anyone at once.

New builds aren’t always wrong. Sometimes the existing system genuinely can’t do the job, and pretending otherwise is its own kind of avoidance. But before commissioning anything new, it’s worth asking a duller question first: is what we already have broken, or has nobody been asked to fix it yet? In most mature organisations it’s closer to the second.

The harder problem is the one I have not solved. How do you make a case to a sponsor whose entire mental model of progress is a new launch, when the recommendation is to spend six months fixing links instead? Every version of the argument I have found only works once the fixing is done and there is a number to point at.