You would never accept a doctor who walks into the examination room, hears you say “my head hurts,” and writes a prescription without touching you.
In medicine, that’s a fault. It can cost a doctor their license.
In tech consulting, it’s the business model.

The brief already has the conclusion
I receive these kinds of briefs regularly. Not occasionally. Regularly.
“Our team is slow. We need a process audit.” Translation: confirm that the problem is the team lead and recommend replacing them. We’ve already told him his contract isn’t being renewed. We need documentation for HR.
“Our cloud costs are out of control. We need an optimization plan.” Translation: confirm that the migration was poorly handled and recommend a new vendor. We’ve already started conversations with AWS. We need an outside voice to close the internal debate.
“Our CTO isn’t performing. We need an outside view.” Translation: we’ve decided to let him go. We need a professional who’ll write it up in a way that holds legally and looks objective.
I’ve turned down these missions. Not out of principle — principle is a luxury. Because the work is structurally corrupt. You spend the entire engagement justifying a conclusion that existed before you started. Anything you find that doesn’t support the original diagnosis gets quietly deprioritized. And at the end, the client gets what they paid for, which was never the truth about their system. It was ammunition.
The consultant who takes that work isn’t doing consulting. They’re doing litigation support without the courtroom.
The consulting industry has a structural incentive to keep you sick
Here’s what I rarely hear said directly: the dominant economic model in tech consulting rewards the prescription, not the diagnosis.
If I run a team of fifty consultants and I need them billable, I need ongoing engagements. An engagement that finds the problem, solves it in four months, and ends is bad for revenue. An engagement that validates a migration, manages the migration, then optimizes the result of the migration is eighteen months of billings.
I’m not describing bad actors. I’m describing rational actors in a system that rewards perpetuation over resolution.
The client is often not aware of this. They’ve hired a firm. The firm has good people. The people are well-intentioned. But the incentive structure means that the questions the firm asks are shaped by what they can subsequently sell, not by what the client actually needs to understand.
This is why “referred pain” is so prevalent and so expensive.
Referred pain
In medicine, referred pain means the injury is in one place and the pain manifests somewhere else entirely. You treat the shoulder. The problem is in the heart.
Tech systems have referred pain as their default mode.
A cloud bill that keeps growing is almost never a cloud problem. It’s usually an architecture decision made under time pressure three years ago, without visibility on what the business would become. The engineer made a reasonable choice given what they knew. The business grew in a direction nobody fully anticipated. The architecture didn’t adapt. The bill reflects the structural gap, not cloud mismanagement.
You hire a cloud optimization consultant. You shave 22% off the invoice in quarter one. You’re satisfied. In quarter three, the bill is back at 90% of where it started, because you changed the symptom, not the cause. The consultant will offer you a phase two engagement.
A CTO who “isn’t performing” is almost never performing badly on purpose. More often, he’s navigating an organization that gave him the title without the authority, expects him to deliver technical transformation while fighting every budget conversation alone, and has a product roadmap that changes direction every quarter. He can’t perform because the structural conditions for performance don’t exist.
Replace him. You get a new person in the same structural trap. I’ve watched this happen. The new CTO quit eight months in. The outgoing CTO found a role at a company with actual governance. The board called it a hiring failure.
It was a diagnostic failure.
The questions I ask that aren’t in the brief
I start every engagement by asking things the brief didn’t ask for.
“Before we look at team velocity — walk me through the last three times a technical decision was overridden after it was made.” That’s not a process question. That’s a governance question. It tells me whether the CTO leads or manages upward anxiety. The answer usually comes with a pause.
“Show me the last significant vendor choice that went against what the technical team recommended.” If it exists, the story it tells about authority and accountability in that organization is almost always the real brief.
I’ve had clients tell me these questions are off-topic. “We hired you for the cloud costs.”
I keep asking anyway. Because the referring pain is never in the cloud bill, and a doctor who only examines where it hurts is going to miss the thing that matters.
What happens when the diagnosis is inconvenient
Finding the problem is not the hard part. Problems are visible once you stop looking where you were told to look.
The hard part is delivering a finding that contradicts the decision the client has already committed to emotionally. That’s when the room gets quiet in an uncomfortable way.
I’ve delivered reports that said the CTO was not the problem. That the architecture was sound given the constraints. That the cloud costs reflected real business growth, not waste. Three times in four, the client takes the report, says it’s very interesting, and proceeds with the replacement or migration they had already decided on.
That’s their right. It’s their company.
But here’s what I want to be clear about: the problem doesn’t go away because you changed the person or the vendor. The structural conditions that produced the symptoms remain intact. In twelve months, you’ll have new symptoms. And someone will recommend a new prescription.
The question isn’t whether your technical situation is a problem. It’s whether you actually want to know what’s causing it. Those two questions have different answers more often than anyone in this industry admits.
The authority problem behind “who makes the call” is explored in Three Seconds. The structural consequence — an IS nobody has properly examined — is in Looking Inside the Walls.
