You would never accept a doctor who walks into the examination room, hears you say “my head hurts,” and immediately writes a prescription without touching you.
In medicine, that has a name. Prescribing without examining is a fault. It can cost a doctor their license.
In tech consulting, it’s a sales strategy.
The brief already has the conclusion
I receive these kinds of briefs regularly.
“Our team is slow. We need a process audit.” Translation: confirm that the problem is the team lead and recommend replacing them.
“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.
“Our CTO isn’t performing. We need an outside view.” Translation: we’ve already decided to let him go, we need documentation.
The brief arrives with the treatment already written. My job, apparently, is to administer it.
I have turned down missions for this exact reason. Not out of principle. Because it’s bad medicine. You spend the entire mission justifying a conclusion that existed before you started. You examine the patient only to confirm the prescription. Anything you find that doesn’t support the original diagnosis gets quietly ignored. And at the end, the client gets what they paid for, which was never the truth.
Referred pain
There’s a concept in medicine called referred pain. The injury is in one place. The pain manifests somewhere else entirely. The brain maps it wrong. You treat the shoulder, and the problem is in the heart.
Tech systems have referred pain constantly.
A cloud bill that keeps growing is almost never a cloud problem. It’s usually an architecture decision made three years ago under time pressure, without visibility on what the business would become. The original engineer made a reasonable choice given what they knew. The business scaled in a direction nobody fully anticipated. The architecture didn’t adapt. The bill reflects the gap.
You can hire a cloud optimization consultant and shave 20% off the invoice. You haven’t solved anything. You’ve treated the shoulder.
A CTO who isn’t performing is almost never performing badly on purpose. More often he’s navigating alone in an organization that never gave him the resources to succeed, never established clear authority between technical and business decisions, and is now asking him to deliver transformation while fighting every budget conversation by himself. Replace him and you get a new CTO with the same structural problem.
I’ve had a client replace a CTO because “the architecture was wrong.” The new CTO inherited the same architecture. The architecture hadn’t changed because the decisions that produced it hadn’t changed. The new person quit eight months later.
The part about asking uncomfortable questions
My approach when I start an engagement is to ask questions that don’t seem to be about the brief.
“Before we look at the team velocity, walk me through the last three times a technical decision changed after it was made.” That’s not a process question. That’s an authority question. That tells me whether the CTO actually leads or whether he manages upward anxiety.
“Show me the last significant vendor choice that didn’t go the way the business suggested it should.” Not a technical question. A governance question. Who has actual influence over technical direction?
I’ve had clients tell me these questions are off-topic. “We hired you for the cloud costs, not the org chart.”
I understand the reaction. And I keep asking anyway. Because the referring pain is never in the cloud bill.
What happens when the diagnosis is inconvenient
The hardest part of this work isn’t finding the problem. Problems are usually visible once you stop looking where you were told to look.
The hard part is delivering a diagnosis that contradicts the decision the client has already committed to emotionally.
I’ve delivered audit reports that said the CTO was not the problem. That the architecture was actually reasonable given the constraints and the real issue was a product roadmap that kept changing every quarter. That the cloud costs reflected business growth more than operational waste.
Three times out of four, the client takes the report, says “very interesting,” and then proceeds with the replacement or the migration they had already decided on.
That’s their right. It’s their company.
What I can’t do is write the report they wanted instead of the report I found. That would be prescribing without examining. My name is on it. My judgment is on it. And the patient would still be sick.
The question isn’t whether your tech is performing. It’s whether you actually want to know why it’s not.
