Operational Insolvency and the Myth of 'Data-Driven'

Operational Insolvency and the Myth of 'Data-Driven'


Data must be operated. Many companies just let it drive them into missed targets.

Two dashboards disagree in the QBR. Finance has one number, sales has another, and the room does what rooms do: someone makes a joke about data quality, someone promises to align offline, and the meeting moves on. Everyone steps around the crack.

Almost everyone. One person goes digging after the meeting (into the report logic, the field history, the actual records) and finds the cause. It isn't dirty data. Both numbers are labeled renewals, and neither is wrong. One counts renewals booked in the period; the other counts renewals effective in the period. They were never the same number.

How did that happen? Both have an author. Someone built the booked-in-period version for a bookings review, where the only date that matters is the day the deal closed. Someone else built the effective-in-period version for a retention review, where the only date that matters is the day coverage started. Each was right for the question in front of it. Neither author set the company's definition of a renewal, and nobody asked them to: the label said renewals in both places, both reports computed correctly, and a stack will carry two answers under one name without complaint.

Every number is a decision about what to count. Almost none of them get decided. They get configured, inherited, defaulted into, then compounded by every dashboard, comp plan, and board deck built on top. The accumulated distance between what your numbers actually count and what everyone believes they count is definition debt, and no organization is debt-free.

The debt accrues silently. It compounds: each new report built on an unexamined definition adds to the balance rather than surfacing it. And it comes due at the worst possible moment: in a room where someone senior asks a simple question and can't get a good answer. Maybe they get two answers. Or one hedged into uselessness. Or a directional one nobody will put their name on. The question doesn't get withdrawn; the decision gets made anyway, on whichever number feels best.

Go back to the two renewal numbers. Booked in the period, effective in the period. For years the gap between them didn't matter, because in a steady book they land within a point of each other, close enough that nobody had cause to look. Then a quarter arrives where renewals cluster differently than the year before, and gross retention appears to drop three points.

The number moved; retention didn't. The renewals landed on the far side of a period boundary that one definition counts and the other doesn't. But the three-point drop is in the deck, the deck is in the QBR, and within a month there's a save motion or new CS headcount aimed at a churn problem that doesn't exist. Nobody made an error. Every number in that deck computed correctly. The number just answered a different question than the one on the table, and nobody caught the metric mirage - the silent hallucination confusing one metric for another.

None of this looks like debt. It looks like working reports. The dashboards render, the numbers are plausible, and nothing throws an error, which is exactly how it differs from the technical debt it resembles. Broken software gets someone paged. Nothing here is broken: it's faithfully computing something, just not the thing everyone thinks.

And the blast radius just widened. Definitions used to travel at the speed of dashboard builds. Someone had to build the report, someone had to read it, and a bad definition had to survive both to do any damage. Now it sits under a semantic layer (or an AI agent) that answers in plain language, on demand, to anyone who asks. The wrong number doesn't wait to be misread anymore: it gets stated, confidently, to everyone who asks, as often as they ask. And pressing for more precision doesn't fix it. Ask AI what the metric actually counts and it answers in the same confident register no matter what. It's as likely to hand back a plausible definition it inferred from the label as it is to flag that the label covers two things. That's the part people have backwards about pointing AI at the tech and data stack: it doesn't close the gap between the people who know what a number counts and the people who don't. It arms the second group, making them fluent, fast, and wrong.

No tool does this for you

There's a practice that pays this balance down, no tool will put it in place for you.

It's knowing what a number represents before anyone bets on it. Confirming what it counts and what it leaves out before putting it in front of someone. Sense-checking that the underlying logic fits this context, this company, this motion, this data, not just the case study it came from.

This isn't pedantry. A pedant argues definitions to win the argument. This is about the real decisions people make with data, and the livelihoods those decisions depend on. A rep's comp. A forecast the board hears. A headcount plan. When you hand someone a number, you're asking them to bet something on it: their credibility, their budget, sometimes their job. That asymmetry makes this an ownership problem, not a quality problem: other people carry consequences for work only you were positioned to check.

No business ends up here on purpose. Unlike financial debt, nobody chooses to take this on. But almost everybody declines to audit, and that decline takes three shapes.

Altitude addiction. Staying high-level, first by preference and then by habit. Strategy decks, frameworks, the 30,000-foot view. The artifacts are real, and the substance underneath them is assumed. Precision is analyst work, so it gets delegated and never checked on return. What's left is a strong opinion about a number and no idea what's inside it: a team betting on a metric nobody in the room actually understands.

Intellectual anti-rigor. Accepting what sounds right. The definition seems reasonable. The number is plausible. Good enough, ship it. Plausibility gets mistaken for verification because verification is work and plausibility is free. This isn't stupidity. It's avoiding one specific kind of work and calling it efficiency.

Imported validity. Maybe it's the "best practice" playbook. Maybe it's what worked at the last company, or how the B2B sales book by the ABM platform founder says to do it. Pattern-match, apply, move on, with no check of whether this business, this motion, this data even fits the pattern. Validity earned in one context, spent in another as if it carries over. It doesn't carry over.

Three silhouettes cast by one failure: nobody confirmed that the measurements reflect an accurate model of reality.

Avoiding that failure takes a distinct capability: judgment and ownership, welded to data modeling and process engineering. It produces a definition precise enough to survive the post-AI world: one that states plainly what you believe you're counting, then demonstrates what the data actually counts.

A few people in every GTM organization have it. They open a number before they pass it on, and the rest of the operation stands on their definitions. I call that person the Keystone: the stone at the crown of an arch that every other stone leans into. Load-bearing, invisible while it holds, and catastrophic when it goes.

Using data is a tall order

This isn't about being a "details person." Data doesn't drive your business. You must operate the data in order to manage the business, and that is the responsibility that comes with claiming to run on data: the claim that separates accountable management from business theater.

Many businesses treat "data-driven" as a posture instead of a practice, and can't back it up. The definitions underneath their numbers are what you might generously call working definitions: loose where they should be specific, or precise but alive only in an analyst's head or another analyst's SQL, or recorded in a doc nobody reads, or split across three teams who each hold a version and don't know the other two exist. A working definition survives because it's never asked to do anything but participate in a report, and that's a low bar. Charts get generated. Meetings come and go without unlocking growth. In between, nobody asks whether the data describes what specifically needs measuring.

A worked definition is the opposite. It states precisely what you believe you're counting and how, and demonstrates what the data actually counts. And it's gone through the organization rather than one person's head: reconciled across the teams that use it, adopted where the decisions get made, reachable when someone needs to check. Precise, adopted, legible to the person acting on it. That's not a nicer version of a working definition. It's a different outcome, and almost nothing in a normal tech or data stack produces one.

And a worked definition is only the first half. A sound number can still be used dishonestly: stretched to cover a claim it doesn't support, quoted past the conditions where it holds, aimed at the conclusion someone already wanted. That's operational borrowing: spending a number's credibility to land a claim it can't cover, banking the win now against a cost that comes later. Getting the definition right earns you a number you can trust; logical honesty governs what you do with it once you have it: the discipline of letting the number mean only what it means, no more reach than the metric licenses, no unearned confidence, no rounding the argument toward the answer someone wants to hear. Worked definitions and logical honesty are the two things a business actually needs to say it runs on data. Many are coming up short - on one or both - and can't see it, because a working definition looks fine and a motivated interpretation usually sounds fine.

Again, none of these challenges arise on purpose. They arise in spite of capable people showing up and doing the work in front of them, inside a system where nothing forces a definition to be worked or a reading to be checked. That's why it's so common: the absence is silent and invisible.

These invisible costs throttle business growth at two levels. The debt compounds: every report built on a working definition adds to a balance that comes due in some future business review. And in the meantime, the potential gets wasted: decisions get made with business theater featuring data props, the team guessing to market on numbers nobody worked. Freeing the business from these self-imposed headwinds requires sharpening the worked definitions and delivering a logically honest reading. Without those, the business will continue to pay debilitating costs: working harder each year and continuously falling short of targets.

Debt always comes due

Every GTM organization carries definition debt, and most add operational borrowing on top, stretching numbers they've never checked. Both lead to operational insolvency: running the business on figures it can't substantiate. Both stay invisible until someone goes looking, so the only real question is whether you look.

How well does your leadership team understand what your core metrics are actually counting?

Not whether they can recite the number. Not whether they can find it in a dashboard. Understand it: what it includes, what it drops, and the conditions under which it stops being true.

If the honest answer is “not well,” that isn't a failing: it's an invisible debt hinting at operational insolvency. The definition debt is the first loose thread to pull on before you find yourself in a QBR with a senior leader asking a simple question that makes the room go quiet.