The Revenue Architecture Manifesto · Part Three: What's Actually Happening

Data Trust Is Not a Tech Problem

At some point in the Visibility Debt™ story, somebody buys software. A new CRM. A BI platform. A data warehouse with a dashboard layer and a sales rep who said *single source of truth* out loud, twice, without laughing. The purchase feels like progress — we covered that feeling in the hiring chapter, and this […]

At some point in the Visibility Debt™ story, somebody buys software.

A new CRM. A BI platform. A data warehouse with a dashboard layer and a sales rep who said *single source of truth* out loud, twice, without laughing. The purchase feels like progress — we covered that feeling in the hiring chapter, and this is the same purchase in a different aisle.

Eighteen months later: the new tool is populated, the dashboards are live, and the head of sales still keeps the real pipeline in a spreadsheet. Nothing about trust changed except its font.

You cannot purchase trust. Vendors will keep inviting you to try.

Here’s what actually broke, and notice that none of it is technical.

**The definitions were never agreed.** What counts as a lead. When a deal’s close date moves. What “onboarded” means. Every department answered privately, differently, years ago, and every report since has been a quiet argument between definitions wearing the same column headers. The tool can’t fix this — the tool doesn’t know there’s a disagreement. Neither, officially, does the company.

**The incentives reward selective reporting.** Grade departments separately and you will get numbers groomed separately — each function presenting the version of the truth that photographs best, not because anyone is lying, but because everyone is optimizing what you told them to optimize. Nobody checks whether the department numbers add up to a coherent company, because assembling the coherent picture is nobody’s job. The problem isn’t dishonest people. It’s a structure where the team’s number matters less than any department’s number.

**And honesty got expensive — the oldest problem in this book.** Data trust dies on a specific day in every company: the day someone brings a true, unwelcome number to a meeting and pays for it. Everyone watches what happens to that person. The lesson installs instantly, and it’s permanent: numbers are political objects here. From that day, every report is pre-flinched — rounded toward safety, hedged toward comfort, true-ish. The contract from Chapter 1, now with pivot tables.

So what *is* trust in a number? Strip it down and it’s three agreements, all human:

We share the definition of what this measures. We believe the source it came from. And we can question it safely — including when it’s good news we don’t believe.

Software supports all three. Software provides none of them. A number is trusted when the people around it have made those agreements — which means data trust is a cultural achievement wearing a technical costume, and every “data problem” I have ever been hired to fix turned out to be a trust problem the org had been calling a data problem because tools are easier to blame than incentives.

That’s also why the fix inverts the usual order. Agreements first, dashboards second. The data dictionary before the data warehouse — and understand that a real data dictionary is not documentation, it’s a peace treaty: the departments formally agreeing what words mean so the numbers can stop fighting. Aligned scoreboards, so the company’s number outranks the department’s. And safe passage for bad news, proven publicly, at least once — because the whole building is watching what happens to the first messenger.

Do that, and almost any tool works. Skip it, and no tool ever will.

Your data problem is a trust problem wearing a software costume. Stop shopping. Start negotiating the treaty.

Revenue Architecture Manifesto.
som blurb here