Technology should make a company harder to lie to itself

Technology should help a company see reality more clearly, make decisions sooner, and turn those decisions into action.

I started as an engineer in the dot com era. I still think like one.

When a system behaves differently from what you expected, you normally get closer to it. You look at the logs, inspect the data, reproduce the problem and work out which assumption was wrong. You don’t solve it by asking five people to summarise what they think happened.

Over the years I have realised that I approach organisations in much the same way.

Most companies don’t have an information problem in the literal sense. They have more dashboards, reports, presentations, documents and meetings than anyone could reasonably consume. The harder problem is knowing how faithfully all of that represents what is actually happening, and how much interpretation has accumulated before the information reaches the person expected to act on it.

That became much more obvious to me in high growth environments. At Glovo, for example, you could sometimes ask what looked like a simple business question and get different answers depending on the system, team or definition you started from. We had plenty of data. What was less clear was who owned the version that mattered and whether everyone meant the same thing when they used the same word.

I came to see that as much more than data quality. It was an ownership problem, and ultimately a decision quality problem. Since then I’ve become slightly obsessive about fidelity.

Getting closer to the source

A recent example brought this back to me.

We were looking at an automated customer experience. One of the headline measures looked pretty good. A high proportion of conversations were staying within the automated journey, which could reasonably be interpreted as the system doing its job.

But another measure didn’t really fit the story, so I asked for the underlying data.

I rarely ask “why?” five times as a ritual. I’d rather see the export. The first thing I normally check is painfully basic: how many rows are there, and what are the first and last timestamps?

In this case, an export that was supposed to represent a much longer period had silently capped at 10,000 rows. It covered less than two days.

Then we found a field in the underlying data that wasn’t represented in the dashboard at all. It told us more about whether the customer had actually achieved what they came to do.

The more interesting discovery came after that. A lot of the conversations being handed over to people weren’t failing because the AI needed to sound more human or reason more intelligently. In many cases it knew what should happen. It simply wasn’t connected to the system required to do it, didn’t have permission to take the action, or had run into a policy boundary.

Those findings point towards very different investments. One sends you towards more model work. The other sends you towards APIs, workflows, permissions and business rules.

I also liked that the analysis cut both ways. Some criticism of the technology wasn’t supported by what we found, and I was happy to defend the team on that. At the same time, the comfortable headline metric was clearly overstating how well the experience was working. Good analysis shouldn’t validate the position you arrived with. It should make your understanding more accurate.

Abstraction is useful, but it has a cost

None of this is an argument against dashboards or executive summaries. Organisations couldn’t function if every decision required an executive to open a database.

Abstraction is necessary, but every time we abstract something we make a trade. A customer interaction becomes a metric. The metric becomes a dashboard. The dashboard becomes a slide. The slide becomes one sentence in a meeting. Each step makes the information easier to consume, while also creating another opportunity to lose context.

The leadership skill is knowing when the abstraction is good enough and when you need to go down a level.

If somebody tells me performance improved by a multiple, I want to understand the baseline. If an analysis says it covers two weeks, I’ll usually check whether the timestamps agree. If we’re told a capability exists, I want to know where it exists, who owns it and whether the underlying system works the way the description suggests.

Sometimes the answer is simply that we don’t know yet. I prefer that to turning an assumption into a fact because it appeared on a sufficiently polished slide.

This is part of what I meant when I wrote that thinking is the one thing you cannot outsource. You can delegate analysis, and you should. You can use partners, analysts, AI and agents to process enormous amounts of information. But somebody accountable for the decision still has to understand enough of the underlying reality to form their own judgement.

The further away you get from the source, the easier it becomes to rent somebody else’s interpretation.

The uncomfortable question

I don’t think the quality of the questions should depend too much on the seniority of the room.

That doesn’t mean challenging everything. I find performative contrarianism quite tedious. If your default position is that everyone else is wrong, you’re probably not showing independence of thought. You’re just introducing another bias.

What matters is whether the challenge can be traced. Can I point to the data, the system, the document, the customer interaction or the person closest to the work? Have I separated what we know from what we believe? Do I know which parts haven’t been established at all? And am I willing to accept an answer that proves my original view wrong?

The last part is where this becomes difficult, because it’s much easier to demand rigour when the problem sits in somebody else’s organisation. The real test is whether you apply the same standard when the evidence points towards your own team, your own architecture or a decision you previously supported.

If you only go looking for fidelity when you expect the evidence to support you, you aren’t looking for fidelity. You’re looking for ammunition.

There is a connection here to something else I’ve written about: leadership owning the seams between teams, systems and decisions. Information quality often lives in exactly those seams. Teams can own individual systems, metrics and processes, while the gap between them remains nobody’s problem.

One team’s definition meets another team’s workflow. A local metric looks healthy but creates the wrong global conclusion. A dashboard compresses away something important. Everyone may have done their job correctly, yet the organisation ends up with a picture of itself that is slightly wrong.

That is how self deception usually starts. Not through dishonesty, but through accumulated interpretation.

Reality, truth and fidelity

I’ve been using three words internally to think about technology architecture: truth, structure and expression.

I want to be quite precise about the first one.

Reality is what is actually happening. Customers are doing something. Products are moving. Transactions are succeeding or failing. Inventory is physically somewhere. Decisions are being made.

Truth, in the way I use it in this model, is the company’s representation of that reality: the data, context, history and decisions it can reliably access and agree on.

Fidelity is how closely the two match.

There will always be a gap. Companies are moving systems made up of people, software, incentives and thousands of decisions. Reality doesn’t wait for the dashboard to refresh. But you can design an organisation to reduce that distance through clear ownership, reliable data, shared definitions, understandable interfaces and systems that expose what is happening without forcing every team to reconstruct it for themselves.

This is some of the least glamorous technology work, and also some of the most valuable.

Nobody celebrates a company because its definition of inventory is consistent across systems. You notice when it isn’t: when the customer gets the wrong promise, when a planning decision is made against stale information, when two executives arrive at a meeting with different numbers, or when an AI agent confidently acts on the wrong version of reality.

The invisible foundations matter precisely because, when they are good, most people don’t have to think about them.

Knowing when to stop looking

The search for better information can also become another way of avoiding a decision.

There is always another cut of the data, another scenario, another working group and another meeting you could have before committing. At some point, additional analysis is very unlikely to change what you should do.

My threshold depends a lot on reversibility. If we can act, observe what happens and change course cheaply, I’d rather make the decision and learn. If the decision is hard to reverse and one of the core assumptions still rests on somebody’s interpretation of a dashboard nobody has really challenged, I’ll keep digging.

I don’t see fidelity and speed as opposites. In a well run organisation, one should enable the other.

Good foundations should make decisions easier. Better internal understanding should reduce the amount of time spent reconciling competing versions of the same thing. Work should leave something behind so that the organisation doesn’t rediscover the same truth every time it encounters the same class of problem.

I wrote recently that the next thing should be easier than the last. I think the same should be true of decisions. A company should become better at understanding itself each time it does something difficult.

AI raises the cost of being wrong

AI makes this more urgent, although I don’t think this is fundamentally an AI argument.

AI didn’t create fragmented data, fuzzy ownership or broken handoffs. It is simply making them harder to ignore.

For years, a gap between reality and the company’s version of reality might have resulted in a misleading report or a poor meeting. Somebody might eventually notice, ask a question and correct it.

We’re now asking software to interpret that same context and, increasingly, to act on it.

An agent doesn’t instinctively know that two systems use different definitions of a customer. It doesn’t know that the policy it found is obsolete unless that history is available. It doesn’t know that everybody in the company quietly distrusts a particular metric. It sees the context we give it.

AI also makes expression cheap. We can create another interface, analysis, workflow or agent very quickly. But cheap expression sitting on top of weak truth doesn’t make the company more intelligent. It can simply make its confusion executable.

That is why the sequence matters to me. Truth has to be dependable. Structure has to preserve the meaning, logic, permissions and ownership around it. Expression can then move much faster.

AI increases the leverage of that architecture in both directions.

A company that can see itself

The longer I work in technology, the less interested I am in technology as a separate subject. What interests me is what the company becomes capable of doing because of it.

Can it see what is actually happening? Can it distinguish a fact from an inference? Can people get close enough to the source when something doesn’t add up? Can a difficult question survive the hierarchy? Can the organisation make a decision without waiting for certainty, and then learn quickly enough to improve the next one?

Technology has a fairly fundamental role in all of this because it mediates more and more of what a company can know, remember and act upon.

So yes, I think good technology should make a company harder to lie to itself.

I don’t mean deliberate dishonesty. Most organisational self deception is much more mundane. A locally sensible metric becomes the headline. An assumption survives one meeting too many. A temporary process quietly becomes the way things work. A number gets repeated often enough that nobody remembers where it came from.

The danger is the distance these things create between reality and the decisions being made about it.

A large part of the technology job, at least as I see it, is to keep shortening that distance.