You Cannot Price a Standing Refusal Until You Remove It

A migration got approved, and I inherited the team that had to do it.

Everyone was right. That is the part I want to start with, because the story does not work if you think somebody was being stupid. The systems were old. Security patches were getting harder to apply. Operating system support was running out. The plan on the table read as a straightforward move onto current infrastructure with a proper cleanup along the way, which is three good things stacked on top of each other. The people pushing for it had been pushing for years and they had the better argument every single time they made it.

It was not a swap. It was a rewrite.

The bill

The work turned out to be exponential rather than additive. The estimate was not off by a margin, it was off by a category. Time went, money went, and the part that actually hurt was the forward progress, because for the duration nobody was building anything new. We were paying to end up where we already were.

I have seen a lot of projects run over. This was different in a specific way that took me a while to name.

He had been stalling it for years

A senior technical leader had left some months before the approval. His directs came to me, which is how I ended up close enough to this to understand it.

He had been the reason the migration had not happened. Not through a document, not through a veto, not through any process anyone could point to. He had been absorbing the pressure. Every time it came up he pushed back, and every time he pushed back he was arguing against people who were correct on the merits.

He never won those arguments by proving anyone wrong. He just kept declining, and each time he declined, the thing did not happen for another few months.

Then he left, and the pressure that had been landing on him for years landed on me and the newly inherited team without knowledge of the cost, and the plan went through in the ordinary way that plans go through when the last objection stops arriving.

Right on cost, not on merits

Here is what he knew that the merits did not capture.

He knew what was welded to what. He knew the core system had accumulated assumptions over years, and that those assumptions lived in the system itself and were not going to travel to the new infrastructure. What looked like a platform underneath the product was actually load carried in a hundred small places that nobody had catalogued, because nobody had needed to. That is what his standing instruction not to diverge from the core had actually been protecting.

So he was not right about whether to modernize. Modernizing was correct. He was right about the price, and he was the only person who could clearly see it.

I doubt he could have fully articulated it even if asked. It was not a position he held so much as an accumulated sense of where the bodies were, built up over years of being the person who fixed it when it broke.

Nothing happening is not an artifact

So why was none of this written down?

Because there was nothing to write down. He was not producing a recommendation, or a decision memo, or a design doc with a rejected-alternatives section. He was producing an absence. The output of his judgment was that a thing did not occur, and a thing not occurring generates no document, no ticket, no commit, no line item, and no entry in any system we have ever built for tracking what people do.

Think about what a refusal has to be for it to leave a record. It has to be one you can justify on the merits. Those go in a wiki, because you win them with an argument and the argument is the artifact.

A refusal against the merits leaves nothing at all. You cannot write “I think this will cost more than any of you believe and I cannot show you why” into a decision log and expect it to survive contact with a roadmap review. So you just keep saying not yet, and the not-yet is invisible, and the day you stop saying it is the day it disappears without anyone noticing a thing has changed.

Someone is going to say he could have written something down anyway, and that is fair. He could have. “Core system has undocumented coupling, estimate confidence low pending an audit” would have gone into a risk register without anyone blinking.

But that is the indictment, not the defence. Nothing ever prompted him to write it, because from the outside nothing had happened. There is no ritual for the thing you stopped. No review fires when a proposal quietly fails to get made. No field anywhere asks why not. Every mechanism we have is triggered by an event, and a refusal is the absence of one.

They knew the parts

The obvious response is that this is what documentation and succession planning are for, and that a functioning organization would have retained the knowledge.

Some of it was retained. That is the part that took me longest to understand.

His directs knew the systems. They knew their own areas well, in some cases better than he did. What did not survive was the integration. They knew the parts and nobody held the picture of what depended on what.

Which means the estimate that came back was not simply wrong. It was unreviewable. There was no longer anybody in the building who could look at it and say that number is too low. The mistakes that got made were exactly the mistakes he would have caught, and they got made by capable people doing careful work, because the thing that had left was not knowledge. It was the assembly of it.

What we already know how to record

I want to be careful here, because there is real prior work on this and I am not claiming to have found something new.

There is good published work on why you write down a decision’s reasoning while you still have it, instead of grading the decision later by how it happened to turn out. Engineering teams have had a formal discipline for this for well over a decade, precisely so that future you can tell whether a choice was deliberate. All of it is right. I keep a decision log for exactly that reason.

But look at what all of it records. Decisions that were made. Things that happened, and why.

None of it captures the decision not to. The refusal that was never a proposal, held by a person who could not fully explain it, protecting against a cost nobody else could see. That is thinner ground, and I think it is the more expensive gap.

What the model learns

Activity data is very good at recording output. The most valuable thing your best people do is sometimes to stop something from happening, and that leaves no output to capture.

That has always been true. It matters more now, because we have started feeding those records to something that will act on them.

Every AI system a company points at itself learns from the record that company kept. The tickets, the commits, the specs, the roadmaps, the postmortems, the decisions that produced something. All of it is a record of what happened.

So the model inherits the hole. It sees everything the organization did and nothing it deliberately did not do, because the second category never generated a file to train on.

Now run my migration through that. Give a model full access to the codebase, the incident history, the patch backlog, the support timeline. It would find aging systems, expiring operating system support, a rising maintenance burden, and a clean modernization case. It would recommend the migration. Confidently, with more evidence than anyone in the room could assemble, and faster than any of us managed.

It would reach exactly the conclusion we reached, and it would be wrong in exactly the same way, because every piece of evidence pointing the other direction lived in one person’s head and left the building when he did.

Your company has an immaculate record of what it built and almost none of why it didn’t. Point a model at that and it will hand you back, with total confidence and a citation for every line, the thing your best person spent years keeping off the table.

The same gap, in my own system

I said I keep a decision log. I do, and I have kept it rigorously for years.

It records what I decided. Every real call, with the reasoning, written down while I still had it.

There is nothing in it for what I am declining. No place for the thing I keep pushing back on, that has never been a formal proposal, that I would have trouble justifying on the spot if somebody made me. My own system has the exact hole I have just spent a thousand words describing inside somebody else’s organization, and I did not notice until I sat down to write this.

So I am adding one. Not the noes, though. The why behind them.

That distinction is the whole thing, and I want to be precise about it. Knowing he had blocked the migration for years would have told us nothing useful. We knew that. Everyone knew that. It was the most visible fact about the project. What we needed was the reasoning underneath the objection, the part about assumptions having accumulated in the system rather than in the infrastructure they were about to move off, and that is the piece that never got said out loud, because a refusal does not come with a prompt to explain itself and nobody asked while he was still there to answer.

A column I have to remember to fill is the weak version of this, and I know it, because the reason nobody captures an objection is that an objection does not feel like an event. Nothing happened. There is no moment where you think, that was a decision, I should write down why.

Here is what is genuinely different now. When I push back on something, I am usually pushing back inside a thread that already has an AI system in it. It was there for the argument. It does not need me to notice that a decision occurred, because it was present when I said not yet, and it can hold the reasoning while I still have it.

There are two versions of putting AI inside how a team works. One generates more of what already gets recorded, which makes the record longer and exactly as incomplete. The other captures what has never been recorded at all, because for the first time there is something in the room for the decisions that leave no trace. I am much more interested in the second one.

And when I next come into an organization and work through how it actually operates, that question is going in. Not just what the team is building and how it decides. What keeps getting proposed and still has not happened, and who the reason is.

You cannot price a standing refusal until you remove the person holding it. By then you have already paid.

Who on your team is the reason something hasn’t happened, and does anyone know why?