If your data is wrong, you're making worse decisions than with no data at all

A few years ago I sat across from a CEO and told him he was looking at bad data and making bad decisions because of it. He didn't argue the point. He said something I've thought about ever since: he'd rather have bad data than no data at all. That was the moment I knew he needed to be replaced. Not because he had the data wrong, but because he had it exactly backwards about which state was more dangerous. He thought a bad number beat nothing. It's the other way around.

Every executive has been told to make data-driven decisions. Almost none have been told what happens when the data is wrong. The whole consensus rests on a premise nobody audits: that the number on the slide reflects something real. The trap that CEO walked into is hiding underneath all of it. A wrong number isn't just a worse version of a right one. It's worse than no number at all. No data leaves your judgment intact: you stay skeptical, you triangulate, you ask the people who would know. A number ends all of that. It carries an authority a hunch never gets, and that authority is exactly what shuts down the instinct that would have caught the mistake. Wrong data doesn't mislead you the way a bad rumor does. It launders a bad conclusion into an objective one and hands it to you with a chart.

No data keeps you honest. Wrong data doesn't.

When you don't have a number, you behave well. You hedge. You treat the decision as a judgment call and you bring judgment to it: pattern recognition, the read of the people in the room, the memory of the last time something looked like this. You hold the conclusion loosely because you know it's soft.

Give the same executive a precise figure and the behavior inverts. The figure feels settled. It gets repeated in the next meeting, then the one after, and somewhere in that chain the caveats fall off. By the time it reaches a decision it is no longer "our best estimate of technology cost per employee." It is "our technology cost per employee." The softness that would have protected you is gone, and nothing replaced it except confidence.

That is the trap, and it is worth being precise about why it's a trap. The danger of bad data is not the error itself. Errors are survivable when you know they might be there. You build in margin, you sanity-check, you wait for a second read. The danger is that good-looking data removes the one defense you had against acting on it: your own doubt. A wrong number you trust does more damage than a right number you question, because the questioning is the part that keeps you safe.

This is also why the problem gets worse, not better, as the tools get smarter. Feed a confident system a broken input and it will give you a confident output, faster and at greater scale than any analyst would dare. The machinery doesn't supply the doubt. It supplies the opposite. Confident and wrong is the most expensive state a business can operate in, and it is the one you back into the moment you stop asking whether the data underneath the decision is real.

Confident and wrong is the most expensive state a business can operate in.

You'd catch the error if you could find the data.

Here is the obvious objection. Fine, so check the number. Verify it before you trust it. Every finance leader believes they could, in principle, run that check. Most cannot, and the reason is the part of this nobody says out loud: the data behind your decisions isn't where you think it is.

Take the most ordinary question a CFO can ask. What does technology cost us per employee? It sounds like something you pull from one system. It is not in any system. The real number is smeared across at least five systems: headcount and roles in the HRIS, software in license management, machines in hardware tracking, space and overhead in facilities, and the per-seat SaaS billing that never made it into procurement at all. No single source holds the answer. The answer only exists if someone joins those systems by hand, and the moment they do, it's a snapshot that's stale the following week.

So when a technology-cost-per-employee figure shows up on a slide, it is one of two things. Either someone did that manual join and the number is a labor-intensive estimate with a half-life measured in days, or, far more often, someone pulled the convenient figure from the convenient system and the number is confidently wrong. You cannot tell which by looking. They render identically.

The same trap sits underneath the questions a CIO has to answer to an audit committee. Who has access to what? On paper, that lives in the identity system. In reality it's scattered across the directory, the individual apps that granted access outside it, the shared credentials nobody logged, and the contractors who were added for a project and never removed. The honest answer to "would you bet the audit on this?" is usually no. Not because anyone was careless, but because the picture was never in one place to look at.

This is why "just verify it" fails as advice. You cannot verify what you cannot locate, and the data that matters most is the data that lives in the most places at once.

The signal that matters is the one you're not reading.

There is a second reason the data is hard to find, and it cuts deeper than distribution. The most valuable signal about how your business actually runs was never written down as a report. It's a byproduct.

Every system your company runs produces exhaust as people use it: who was granted access to what, which licenses got touched and which sat idle, whose calendar fills with meetings and whose empties out, which teams stopped showing up in each other's collaboration. None of it was designed to be read. It accumulates as the residue of normal work. And it is the truest record you have, precisely because nobody was performing for it. A status report is what a team wants you to see. The metadata is what actually happened.

It's worth being exact about what this is, because the word "metadata" makes people picture surveillance, and it's the opposite. The signal is who, what, when, where, and how much. Not content. The warehouse supervisor logging thirty-one hours of meetings a week when the role calls for floor presence is a question worth asking. What was said in those meetings is not your business, and it is not the data's business either. The pattern is the diagnosis. The content is noise you don't need and shouldn't want.

That distinction is not a compliance footnote. It is the reason this data is usable at all. The valuable layer, the one that tells you whether the organization is doing what you think it's doing, is exactly the layer you can read without reading anyone's mail. The companies that get this wrong reach for content and end up with a monitoring tool nobody trusts. The signal you actually need was sitting one level up the whole time, in the patterns, where it's both more honest and less invasive.

Four questions that tell you whether a number is real.

Suppose you could see all of it. Suppose the data was located and in front of you. You would still need a way to decide whether to trust any given number, and most executives have never been handed one. Four questions do most of the work.

Provenance. Where did this number originate, before it was cleaned and formatted for you? Every figure that reaches a CFO has been through hands: selected, joined, presented. Curation feels like rigor. It is a filter, and you usually cannot see what it removed or who decided.

Reconciliation. When was this last checked against the system it came from, and by whom? A number that was true once and has drifted since is more dangerous than one that was never true, because it has a track record of being right. Trust accrues to it that the current version hasn't earned.

Completeness. What is silently missing? This is where the quiet errors live: the executive who left six months ago and still holds licenses that every headcount report counts as an active seat, the SaaS contracts running on someone's expense card that the procurement system has never heard of. What's excluded doesn't announce itself. It just makes the number smaller than reality and lets you sleep.

Accountability. Who answers when the number is wrong? If the honest answer is "no one in particular," then it is not data. It is a rumor with formatting. A number nobody owns is a number nobody has checked, and the formatting is doing the work the checking should have done.

None of these four require new technology to ask. They require knowing where the data is and being able to look at it. Which is the problem we keep arriving at.

You can't check what you can't see.

Every thread here leads to the same knot. The reason wrong data is more dangerous than no data is that it acts on you before you can catch it. And the reason you can't catch it is that the data is scattered across a dozen systems that don't talk to each other, most of the real signal is unread byproduct, and the questions that would qualify it require a vantage point no one in the company actually holds.

This is not a discipline problem. Your team is not failing to check the data because they are careless. They cannot check it because checking it would mean manually reconciling the HRIS against license management against hardware tracking against billing, every time, for every number, and then doing it again next week when it's stale. No finance team and no IT team has that capacity, and it would be a waste of them if they did. The work is structural. It needs a system, not more diligence.

Asking IT to be that system is its own mistake. IT can run the platforms. Turning their exhaust into trustworthy executive intelligence is a different job, done with different tools, and most IT teams have neither. The gap is not effort. It is that the layer that would do this work doesn't exist in most companies, so the data stays scattered, the signal stays unread, and the next confidently wrong number reaches your desk on schedule.

What the missing layer actually is.

Here is the part worth sitting with. Money has a system that governs it: ERP. People have one: HRIS. Customers have one: CRM. Each exists because the resource got too expensive and too distributed to run on spreadsheets and instinct. Technology crossed that line years ago and brought the rest of the business with it, and no equivalent system was ever built. The data that signals how the business runs has had no system of record. It just accumulated, unread, across the tools that produced it.

That layer is what's missing, and it is what we are building at ORVO. Not another dashboard competing with the ones you already ignore. It is a layer that reads the signal where it already lives, across the systems that produce it, and tells you whether a number can be trusted before it reaches a decision. We call the category Technology Resource Planning, because it is the same kind of system ERP is, pointed at the resource nobody built one for. To be straight about where it stands: the layer that governs and surfaces this data is live and in use today; the deeper diagnostic reach is in early access, built with our first customers. We would rather tell you that than overclaim.

But the category matters less than the discipline behind it, and the discipline comes first. The CEO I sat across from had the choice wrong. He thought it was bad data or no data, and he picked bad. The real choice was never between those two. It is between data you've qualified and data you haven't, and only one of them earns the word "data-driven." Before the next number reaches your desk, it is worth knowing where it came from, whether anyone has checked it, what it leaves out, and who answers if it's wrong. Because the alternative is not neutral. A decision made on data you haven't qualified is a guess wearing a chart, and you would have been better off knowing it was a guess.