I've never worked somewhere that lost confidence in its data platform overnight.

It always happens slowly.


It usually starts with something small.

A report that's slightly off. A number in a dashboard that someone in finance cross-references with a spreadsheet and finds doesn't quite match. A pipeline that silently fails and delivers yesterday's data labelled as today's.

Each of these things is noticed. Each is usually explained. Often it's a legitimate edge case, a timing issue, a known limitation that the team meant to fix.

But it's noted. Quietly. By the person who spotted it.

And they tell someone.


The problem isn't the bug.

The problem is what happens next.

If the team fixes it quickly and explains what happened, most people file it away as a one-off. Trust stays intact.

But if the response is slow, or technical, or involves explaining why the number is actually correct if you account for certain factors, something shifts.

The person who asked stops asking. They start checking.

They build a spreadsheet that does what the dashboard was supposed to do. They stop attending the data review meetings because they've already done their own version. They mention to a colleague that they don't really rely on the platform anymore.

That colleague does the same.


Organisations don't lose trust in their technology
through failure. They lose it through accumulation.


What makes this hard to reverse is that the erosion is invisible to the team causing it.

The dashboards are still being viewed. The pipelines are still running. The tickets are still being raised. From the inside, everything looks like it's functioning.

What's harder to see is that the business has already moved on.

They've built workarounds. They've learned to treat the technology as a rough guide rather than a source of truth. They've stopped expecting it to be reliable in the way they once did.

When that happens, the relationship between the data team and the business isn't really a partnership anymore.

It's a formality.


I've come to think the most important thing a data team can do isn't build better pipelines.

It's maintain the conditions that make people willing to rely on them.

That means taking small problems as seriously as large ones. It means communicating when something goes wrong before someone notices. It means treating a stakeholder's doubt as a signal worth understanding, not a misunderstanding to be corrected.

The technology is the easy part.

The relationship with the people who depend on it is what actually determines whether the technology gets used.

And relationships, once damaged, take much longer to repair than pipelines do.