I know people who signed property contracts without reading the diagnostic report. Not naive people. Smart people with good judgment and functioning careers, who spent months finding the right property, found it, and then treated the due diligence as a bureaucratic formality that stood between them and the decision they’d already made.
The crack was in the report. Page 11. Forty thousand euros they hadn’t planned for.
They’d been shown the property. They liked it. The rest was detail.
Nobody reads page 11
I am searching for a space for a project. Every visit starts the same way. Before we discuss price, before we discuss layout: who ran the diagnostics, when, and can I read the full report?
I’ve walked away from properties that looked perfect on the surface. Right neighborhood, right price, right light. But the asbestos survey was from 2009. The electrical assessment was marked incomplete. The structural report had a note that the inspector himself described as “requiring further investigation.”
That note is the whole story. When the inspector says further investigation, he means: I found something I couldn’t resolve. That’s not a minor remark buried in an appendix. That’s the professional who examined the building telling you there’s something he couldn’t see clearly and that warrants a specialist.
In property, the diagnostic is legally mandatory. The system forces the look because the regulators understood, correctly, that almost nobody does it voluntarily. Without the legal requirement, the market would run entirely on presentation.
In tech, there’s no legal requirement. You can hire a new CTO, launch a full rebuild, raise a funding round, sign an enterprise contract — without anyone having examined the actual state of your information system. Nothing stops you. Nothing forces the look.
And so most companies don’t look. They buy on presentation.
The real reason nobody looks
I want to be direct about something that rarely gets said: most leadership teams avoid the IS audit not because they don’t know it exists, but because they sense what it will find.
They’ve been managing around problems they can’t name for months. Deliveries that take longer than they should. Decisions that require five people to coordinate something that should require one. Specific initiatives that always get blocked at the same point. They know something is wrong. They don’t know exactly what.
Commissioning an audit makes the invisible visible. And once it’s visible, you’re obligated to address it. Or you’re explicitly choosing not to, which is a different kind of accountability.
The survey creates obligation. Not commissioning it preserves optionality — the comfortable fiction that maybe it’s not that bad, maybe it resolves itself, maybe next quarter the context will be better.
I’ve seen this explicitly. A CEO who told me, directly and without embarrassment: “I know we have technical debt. I’d rather not know exactly how much until after the fundraise closes.” He wasn’t ignorant. He was managing his information exposure deliberately. The fundraise closed. He called me three months later. The technical debt had not respected his timeline.
What the survey actually reveals
The reaction I see most often when I deliver a technical survey isn’t panic. It’s relief.
The executive has been living with a weight he couldn’t name or locate. Specific decisions kept taking longer than expected. Certain questions couldn’t be answered without involving four people and taking two weeks. There was a pattern, a recurring friction, that he’d learned to route around because he didn’t know what was causing it.
The survey names it. Gives it edges and a scope. Turns “there’s something wrong with the way we make technical decisions” into “your authentication layer is tightly coupled to your billing module, which means any change to pricing logic requires a full regression test across two systems that have no separation of concerns.”
Before the name, it’s anxiety. After the name, it’s a project. Projects are manageable. Anxiety is not.
The survey didn’t create the problem. The problem existed long before we looked. The survey changed it from the vague category to the specific one, and specific problems have solutions.
The decision to proceed anyway
Here’s where I need to be honest about what happens after the survey, because it’s not always what you’d hope.
I’ve had clients who read the report, understood it completely, and decided to proceed with the acquisition or the launch anyway. Knowing the roof needed replacing. Having read page 11 this time.
That’s not necessarily wrong. You can buy the house with the roof if the price reflects it and you’ve allocated the budget. You can launch on architecture with known debt if you’ve modeled the risk and have a remediation plan with real dates on it.
What’s not acceptable is the CEO reading the executive summary, asking two questions, and announcing that they’re proceeding with the product launch because the fundraise timeline doesn’t allow a four-month architecture pause — and then being surprised eight months later when the architecture breaks at the worst possible moment.
Technical debt doesn’t respect launch timelines. It surfaces at maximum load: the product launch, the enterprise contract, the press mention that brings ten times normal traffic. The system held through the testing environment. It holds through the pilot. It fails the day you need it most, because the day you need it most is the first time it’s under production conditions at production scale.
At that point it doesn’t cost four months. It costs eight months, a botched launch, a client who left, and three engineers who are quietly updating their CVs.
What you’re deciding when you don’t look
Not reading the report is a decision. It’s a decision to proceed with a known information gap, dressed as an oversight.
I’m taking time on a current project to look properly before we commit. Some people in the room think we’re moving too slowly. They’re counting the weeks we’re not producing deliverables.
I’m counting the problems we won’t have in eight months. That math always comes out the same way.
The question isn’t whether to commission a technical survey of your IS. The question is whether you’re prepared to act on what it finds, including the findings that are inconvenient for the decisions you’ve already leaned toward.
If the answer is no — if you know in advance that the survey won’t change what you’re going to do — then you’re not missing a diagnostic. You’re missing the organizational honesty to admit you’ve already decided.
That’s a different problem. And it doesn’t have a technical solution.
Why executives avoid the diagnostic is covered in Prescribing Without Examining. Why the same kitchen breaks every time is in The Kitchen.
