Operators Over Academics
An academic will not build a better tool for an operating domain than an operator will. That is a claim about structure, not about intelligence.
An academic will not build a better tool for an operating domain than an operator will. Not a more rigorous one, not a more defensible one, and not one that feels obvious to the person using it at the moment they need it to.
That is not a grudge, and it is not the view of somebody who skipped the education and resents the people who did not. I have sat in both chairs. What I am describing is structural, it has nothing to do with intelligence, and it holds regardless of how capable the person on the other end of it happens to be. It takes one to know one, and that turns out to be a claim about how information moves rather than a claim about loyalty.
Start with the chain.
When an operator builds his own tool, there is nothing sitting between what he knows and what gets built, because the person holding the operating knowledge and the person making the product decisions are the same person. Nothing has to be explained to anybody, which means nothing can be misheard.
A researcher building for that same domain has four translations to get through. He interviews the operator, then turns the interview into a specification, then a developer turns the specification into software, and then a test team, usually staffed by people who have never worked in the domain, decides whether the result behaves correctly. Four handoffs, and every one of them is a compression.
Compression is fine when the thing being compressed is the average case. The average case survives every handoff, because it is what everyone remembers to write down. What does not survive is the exception, and in an operating domain the exception is where the decision lives.
I can give you the shape of it. Ask a shipper how they tender freight and they will describe a clean process, because that is the process they believe they run. What they will not mention, because nobody thinks to mention it, is the two accounts that get tendered by phone because a relationship goes back twenty years, or the mode they run four times a year that nobody has documented but that cannot be dropped, or the fact that every exception is handled by one person who has been there since before the current system. Those things do not surface in an interview. They surface when you have lived in it, or when you know exactly which question to ask, and knowing which question to ask is the same knowledge.
That is the mechanism. Now here is the cost, and it is measurable.
Research going back decades puts rework at roughly 30 to 50 percent of total development cost, and attributes 70 to 85 percent of that rework to requirements errors. Info-Tech Research Group traced about half of all rework directly to requirements. A NASA review of seven separate studies found that a requirements error costs about 8 times more to fix during design than at the point it was introduced, 16 times more after coding, 21 times more after testing, and 29 times more after deployment.
The most expensive category of defect is the one introduced when somebody wrote down what they thought the operator meant. Not bad code. Not weak architecture. The translation.
An operator building his own tool does not eliminate defects. He eliminates the defect class that costs the most, and he eliminates it by removing the handoffs rather than by trying to be careful inside them.
There is a second effect that shows up in the interface rather than the requirements. An operator building for operators knows what the screen has to do at 4am when something has gone wrong and the person using it has ninety seconds. He knows which field gets filled in every single time and which one gets skipped. He knows that the report everyone claims to need is opened twice a year and the one nobody mentioned is printed daily. That is not user research. That is memory, and it produces workflows that feel obvious to the people using them because they were designed by someone who used them.
I want to be precise about what I am not claiming, because the absolute version of this argument is easy to knock down.
I am not saying domain expertise beats technical skill. It does not, and a platform built by someone who understands the problem and nothing else would be unusable and unsafe. I am not saying research has no value. Research is how you learn what is true across many cases rather than the one you happened to live in, and I have done enough of it to respect it. My own instincts have been wrong often enough that I take it seriously. And I am not claiming operators cannot build bad tools, because most of them do.
The claim is narrower than that, and I think it is very hard to argue with. For a tool that serves a specific operating domain, the person who already holds the operating knowledge will build something that fits better than the person who must acquire it secondhand, because acquisition through interview loses precisely the material that determines fit. Intelligence does not close that gap. Credentials do not close it. Nothing closes it except having done the work.
What changed is that the operator used to be structurally unable to build. Building required capital, engineers, and a translation chain, which meant the operator's only available role was to be the first link in somebody else's chain. That constraint is gone, and it is gone recently enough that most of the industry has not noticed yet.
So the question is no longer whether an operator can build the tool. It is whether the people who know your business are going to build for it, or keep describing it to somebody who will.
Selecting supply chain technology?
PreShiftIQ matches buyers to vendors on measured fit across TMS, dock scheduling, ELD, carrier vetting, and fleet management. Vendors pay for outcomes, never for influence, and the buyer match is free.
See how matching works at preshiftiq.com/how-it-works.
Sources
- Long-running software engineering research on rework as a share of total development cost, and the share of that rework attributable to requirements errors.
- Info-Tech Research Group, on the proportion of rework traced directly to requirements issues.
- NASA, Error Cost Escalation Through the Project Life Cycle, synthesizing seven studies on the relative cost to fix a requirements error by project phase.
Next in the series: how the money works, and why no vendor can buy a better position.
