I used to think trust came from big moments: a hard project delivered on time, a call that turned out right, a problem nobody else could solve.
I don't think that any more. The teams I've seen trusted most weren't always the most talented. They were the ones where you knew what to expect. They said they'd do something, and did it. They said something was uncertain, and it was. They said they'd flag problems early, and they did. Trust builds up in small amounts, and it drains away the same way.
How it's earned: kill the optimism
The most common way I've seen teams lose trust isn't dishonesty. It's optimism. Engineers say yes when the honest answer is maybe. Leaders commit to stakeholders before the team has thought the work through. Estimates assume nothing will go wrong.
I saw how big that gap was when I changed how I asked about estimates. Instead of "how many points is this?", I'd ask "if you had to guarantee delivery, how many points would it be?" The second number was almost always higher. The engineers weren't being careless the first time. The first question invited a best case, and the second asked for an honest one.
Every missed date is understandable on its own. The pattern is what does the damage, because it teaches people not to rely on what they're told.
How it's lost: one small number at a time
Data teams have a second way to lose trust, and it's slower. I've never seen an organisation lose confidence in its data platform overnight. It starts with something small: a report that's slightly off, a dashboard number someone in finance checks against a spreadsheet and finds doesn't match, a pipeline that fails silently and serves yesterday's data labelled as today's.
Each one gets noticed and usually explained. What matters is what happens next. If the team fixes it quickly and says what happened, most people file it away as a one-off. If the response is slow, or technical, or an explanation of why the number is actually right once you account for certain factors, the person who asked stops asking and starts checking. They build a spreadsheet that does what the dashboard was supposed to do. They stop coming to the data review meeting. They tell a colleague they don't really rely on the platform any more, and the colleague does the same.
The team can't see it happening. The dashboards still get views, the pipelines still run and the tickets still come in. From the inside everything looks fine, but the business has already moved on.
What I do about it
My job is to keep the gap between what the team says and what actually happens as small as I can. That means being straight about what we know and what we don't, raising problems while they're still small, and treating stakeholders as adults who can handle a realistic picture. It means treating small data problems as seriously as big ones, telling people something's wrong before they find it, and treating a stakeholder's doubt about a number as worth investigating instead of a misunderstanding to correct.
It's also why, after building most of a warehouse at speed, I've spent months proving it's right before asking anyone to rely on it. Fixing a pipeline takes weeks. Getting people to trust it again takes much longer.