When there is no case, the problem is not a lack of data
Recently I came across something that happens more often than it should: an organization had already made a decision, but when you tried to ask why, no one could reconstruct what had actually been decided, with what data, under what constraints, and what the impact had been. And that is where the absence of a case appears, which frankly tends to say more about the company than any pretty dashboard.
As a CTO, that worries me more than a bad technical decision. A bad decision can still be reviewed, discussed, and corrected. When there is no case, what is usually missing is not information, but the discipline to leave a trail of what happened and to speak in facts before stories. And when that happens, the quality of collective judgment starts to deteriorate quite quickly.
The difference really matters. Sometimes the problem is simply that a specific data point is missing. But many other times what is missing is the habit of turning a decision into something traceable, something you can later review without making up the context. If you cannot explain why something was done in a certain way, you will hardly learn from that decision. And then the same debates come back, only under different names: efficiency, innovation, technical debt, scalability, or reorganization.
A solid case, when it exists, works exactly the opposite way. It is not meant to shield a position, but to test assumptions. Even a harsh, inelegant, or even unfair observation can be useful if it forces you to revisit resistance and decisions that were already inherited. In a serious technical team, that friction helps refine judgment and leave pride off the table.
That same logic should apply to internal management. If we cannot reconstruct a decision from what happened, its impact, and the way it was governed, the problem is not reporting. The problem is the method. Before asking for more automation, more AI, or more structure, it is worth asking whether the organization really knows what it observes, what it measures, and what it accepts as evidence.
Often the gap is not in the data. It is in the discipline to turn activity into learning. You can add more software, move teams around, or raise the budget and still fail to move what matters. Because what is relevant is not movement itself; what matters is whether the operation becomes clearer, the economics healthier, and execution more predictable.
And here comes the uncomfortable part: when there is no case, it should not be filled in. It should be read as a signal of how the organization is functioning. If the fact cannot be reconstructed, the explanation should not be invented either. First traceability, then judgment. First evidence, then narrative. That is where you truly separate a real decision from pure self-deception management.
