Load-Bearing Fear

There is a service in your system that everybody suspects.

It has been "probably bloat" for about a year. It comes up in planning, gets a grimace, and survives. Someone says we should look into that at some point. Nobody looks into it. It sits there through two reorgs and a rebrand, costing a little money, a little attention, and a little of everyone's confidence in the map they carry of their own system.

Notice what is not happening. Nobody is defending it. There is no camp arguing it earns its keep. If anyone had a reason, they would have said so a year ago and the conversation would be over.

What keeps it alive is not a reason. It is a question nobody can answer.

What breaks if I pull it?

That question is the whole story. Someone has to do it. Then if something goes down at two in the morning three weeks later, people remember who removed it, whether or not that is why. The blast radius is unknown, so everyone treats it as unbounded. Nobody volunteers to own an unbounded risk in exchange for deleting something that costs almost nothing to leave alone.

So it stays. Not because it is load-bearing. Because the fear is. That is what is actually holding the weight in that room, and it is the shape I pointed at last time. Load-Bearing Fear.

Now watch what a team usually does with it, because the response rarely works. They schedule a discussion. They get the people who might know into a room and they talk about it.

That meeting cannot produce an answer. It is people taking turns being uncertain out loud. Not because they are not smart enough. Because you cannot reason your way to a fact that is not in anyone's head. The person who built the service left. The system it talked to was replaced. The dependency, if there is one, is an undocumented call from a cron job nobody has read in three years. Discussion cannot retrieve information the room does not have.

That is the trap. The question is empirical and the room keeps treating it as a matter of judgement. The knowledge does not exist yet. It has to be made.

So the move is not an argument. It is an experiment.

Remove it and see. Not permanently, not heroically. As a test, built so that being wrong is cheap.

A safe one has four parts, and they are all dull.

Make it reversible. A flag, a toggle, a stopped process, something you can restore in minutes. If restoring it takes a day, you have not built an experiment. You have built a different kind of fear.

Give it a window, and say the window out loud. Two weeks, four weeks, whatever covers the cycles that matter. If a thing only fires at month end, a one-week window proves nothing.

Decide in advance what counts as breaking, and who is watching. Otherwise the first unrelated incident becomes evidence, someone panics, and the experiment gets rolled back for reasons that have nothing to do with what you removed.

Give one person the rollback. Not the team, one name. That is what dissolves the fear, because now nobody is owning an unbounded risk. They are watching a defined one, for a fixed period, with an exit already built.

Then turn it off and listen.

Designed that way, it pays either way.

If nothing breaks, you were right and the thing is gone. That is the outcome everyone wants, and the less useful one.

If something breaks, you just bought the knowledge that was missing. The unknown dependency became a known one. That cron job now has a name, an owner and a line in a document, and you found it inside a controlled window with a rollback ready, instead of at two in the morning in six months when it dies on its own. The failure case of the experiment is the thing the fear was protecting you from, delivered on your schedule rather than its own.

That is what the four dull steps are for. They keep a bad outcome from becoming an expensive one.

Another meeting does neither.

Fear keeps dead things alive, and it gets more expensive every year, because the pool of people who might have known keeps shrinking. Most of that is recoverable by anyone willing to run a two-week test instead of a six-month conversation.

That is one shape. The next is harder to see, because the thing in question is not dead at all. It works. It is well built, well run, actively used. And it is still wrong, because it was built for a company you are no longer running.

That is where I go next.

Cases in this series are composites. The patterns are real, the companies are not.

The full Core and Bloat™ method, four boxes and all, sits at dirkbauer.com/core-and-bloat.html.

The question arrived as a tool question. Business runs on one project tool. Engineering runs on another. Should engineering move over, so everything lives in one place?

It has all the trappings of a decision. Two options, a comparison, an obvious tidiness argument on one side. People had opinions. It could have gone to a meeting and stayed there for a quarter.

Then someone said the thing that changed its shape. We use maybe ten percent of the tool we already have.

Ten percent. Everything else is configured, maintained, occasionally argued about, and unused. So the real question was never which tool. It was what the current tool is doing for them, and nobody knew. They had never removed anything to find out. They had kept adding fields, statuses, automations and custom views, and lost track of which were load-bearing and which were furniture.

Move that to a new tool and you carry the confusion across, with a migration on top. A new tool does not fix adoption. It relocates the question and buys a quarter of feeling productive while nothing gets answered.

So the team did not answer it. They ran it.

Strip the setup back to something almost embarrassingly simple. A board, a few columns, the minimum needed to see what is in flight. Then work like that for a few weeks and let the retrospectives do the auditing. Every time somebody says they miss something, that is a real dependency, so add it back. Every time nobody mentions a thing that used to be there, that is the answer, and it cost nothing to learn.

A remove-and-see, run on a process instead of a codebase. Same shape, same logic, same reason it works.

Worth keeping, because the tool question comes back every couple of years. It is often Load-Bearing Fear under another name. The team half-knows most of what they have is dead weight, nobody knows which parts, and nobody wants to be the one who deleted the field that turned out to matter. A migration is an appealing way to not decide. It feels decisive, it takes months, and at the end you still do not know what any of it was for.