We are very good at building. We have almost no muscle for letting go.
Watch how the sector grows. A crisis exposes a gap, so we stand up a new coordination body, a new reporting line, a new minimum standard. The intent is sound and the early results are real. Then the crisis passes, but the structure stays. The next crisis brings the next structure, layered on top of the last. Over a decade this accretes into something none of us designed on purpose: parallel systems that do similar work, review cycles that check each other, dashboards that feed dashboards. We did not choose this complexity. We arrived at it one reasonable addition at a time.
Why we keep what we have outgrown
The honest reason we rarely retire anything is that adding is cheap and removing is expensive. A new initiative comes with a launch, a budget line, and a name people can attach themselves to. Closing one comes with awkward questions about why it existed, who relied on it, and who would have to absorb the change. Nobody is rewarded for the system they switched off. So even when a process has quietly stopped serving the people we exist for, it keeps drawing time, attention, and money, because the path of least resistance is to leave it running and route around it.
The cost lands where we can least afford it. Every redundant report a field team files is an hour not spent with a community. Every overlapping approval chain slows the response we promised to make faster. Complexity does not stay neutral. It compounds, and it compounds against the frontline.
A discipline for letting go
The fix is not about tearing structures down for its own sake. It is a standing habit of subtraction, treated as seriously as we treat the habit of building.
A few practices make it real.
Give every new system a sunset by default. State at launch what it is for and when we will check whether it still earns its place. A process that has to justify renewal is a process we can retire without a fight.
Run a regular retirement review, not only an expansion review. Once a year, ask of each major system: if this did not exist, would we build it again today? The ones that fail that test are candidates for retirement.
Measure burden, not just activity. Count the hours a requirement consumes downstream, not the reports it produces. When the burden outweighs the use, that is the signal to act.
Name an owner for closure. Removing a layer needs a person accountable for doing it cleanly, keeping what matters and switching off the rest, so retirement is a real job and not a hope.
None of this is anti-rigor. It is what rigor looks like once a system is mature. We keep what proves its worth, we close what cannot, and we free the capacity for the work that only people can do.
The measure of a serious sector is not how much it can build. It is how well it can let go of what it has outgrown, and how much it frees in the process for the people we are here to serve.