Finding the real bottleneck (and the fake ones)

Every AI conversation I have been in starts in the same wrong place: someone has a capability and is looking for somewhere to put it. The useful conversation runs the other way. Before any instrument is chosen, there is a question with an unglamorous answer: where is this business actually losing time, money or customers, and is that constraint real?

I have learned to distrust the stated bottleneck. It is usually a symptom, and often it is not even a bottleneck.

Three ways a bottleneck turns out to be fake

It is a data problem wearing a compliance costume. The pattern is familiar to anyone who has asked “why?” more than three times in a row. A manual approval exists to prevent fraud. Large amounts are risky. We cannot verify intent at that value. We have no real-time signal. Our systems do not talk to each other. Five questions in, the control everyone defends as a compliance requirement has turned into an integration gap — and no amount of AI on the approval step will touch it.

It is a habit with no owner. Sequential steps survive because a system twenty years ago required them. Manual checks survive because “only a person can judge this” was true once. Neither gets re-examined, because re-examining them is nobody’s job and questioning them looks like carelessness.

It is a real failure in the wrong place. This one I have hit directly. Working on an extraction pipeline, I had a run where six of seven real-world cases failed. The obvious reading was that the model was not good enough. Five of those failures were genuine and fixable — but the sixth was not a system failure at all: the record simply did not exist in the source catalogue. Had I “fixed” it, I would have tuned the system to hallucinate a plausible answer for a question with no answer. The correct output was to fail, and the correct action was to write that down as a source-data gap rather than a defect. Recognising the difference is the whole skill.

What I do instead

I run the constraint down until it stops moving. In practice that means:

• Ask why five times, and be willing for the question to change. When the fifth answer is in a different domain from the first, you have found the real thing.
• Separate the symptom from the queue. The visible pain is often downstream of where the time actually goes. Instrument first, believe the story second.
• Look at incentives, not the org chart. Silos persist because two departments are measured on metrics that pull against each other. That is not fixable with a language model, and finding it early saves an entire programme.
• Ask what happens if nothing changes. The costs that never appear in the business case — the customer who quietly gives up, the senior person doing rework, the decision that arrives too late to matter — are usually larger than the ones that do.

From my own delivery work

The clearest version of this in a production setting was daily test reporting. The stated problem was “reporting takes too long”. It did — but the actual constraint was that the people writing the reports were the same senior leads whose judgement was needed elsewhere, and the reports varied in shape depending on who wrote them, which made them hard to compare week to week.

Those are two different problems. The time cost was real; the consistency cost was larger and nobody had named it. Once framed that way, the shape of the solution changed: what mattered was not “write faster” but “produce the same shape of report every morning from the same underlying data, so that a change in the numbers means a change in reality rather than a change in author”. That framing is what made the eventual pipeline worth building — and it came from the diagnosis, not from the technology.

How this transfers

In an enterprise portfolio, this stage is the highest-leverage and least-funded work. The cost of getting it wrong is not a failed pilot — it is a successful pilot on a problem that did not matter, which is far harder to walk back because it “worked”.

Concretely, I would expect to spend the first weeks of an engagement on: mapping where the organisation loses revenue or time against a faster competitor; identifying high-volume decisions that carry delay or error cost; finding the pairs of departments whose targets contradict each other; and separating perceived bottlenecks from measured ones. The output is not a technology recommendation. It is a shortlist of constraints worth someone’s money, with the evidence attached.