Fundamentals of Trust in Engineering

We usually talk about engineering like it's a technical discipline. We focus on the technical aspects — algorithms, data structures, distributed systems, the right partition key, etc.

It's not wrong to think about it this way, but underneath it tells a different story.

Engineering is Based on Trust.

I don't mean that in some philosophical sense. I mean it quite literally. Everything you'd point to as "the work" — the architecture diagram, the CI/CD pipeline, the on-call rotation, the promo packet — is really a stand in for the questions of who and what you can rely on.

Underneath, trust is one specific thing: the moment people stop checking your work. It's permission to not be verified — a teammate who reads less of your code, a manager who double-checks less of your work, a user who keeps clicking without re-reading the terms. Almost everything fast in engineering runs on it. Without that permission even good code gets second-guessed and stalls. With it, mediocre code ships and the team wins anyway. You earn it slowly and lose it fast.

Let me make the case.

The reason your senior teammate can merge a 2,000-line refactor without anyone reading all 2,000 lines isn't that the reviewer is lazy (he def can be though — that's a valid case). What likely happened is that the reviewer skimmed it, checked the parts that worried them, and approved without going through the entire thing. They're able to do that because, in a manner of speaking, they first reviewed the person before even looking at the code.

That's trust.

And nobody starts with it.

The first time someone reviews your PR, they read every line, because they have no model of you yet. They don't know if you test edge cases or if you're the type who swallows the error with a ‘try/except: pass' and then goes to lunch. So they do the full review — the slow, suspicious, nitpicky kind of review. It feels like they don't respect you, but really they just don't know you yet.

Then you do the work. You write the tests. You leave a comment explaining the weird hack instead of making them ask. You flag your own risky change before they find it. You don't argue when you're wrong, and slowly the reviewer's model of you upgrades from "unknown quality" to, "I trust Kirill, this person catches their own mistakes." After that, your PRs will fly through. Now when you say, "this is urgent, I need eyes in the next ten minutes," you get them, because you don't say that unless it's true.

Trust on a team is a line of credit you build through a hundred small deposits, and you can drain the whole account with one withdrawal — one time you say, "it's tested," when it isn't, one time you throw a teammate under the bus in an incident review. People remember the withdrawal far longer than the deposits. Engineers are pattern-matchers by training, so we especially remember any deviations from the normal.

Be the person whose word matches reality. If you say it's done, it's done. If you're going to miss a date, they hear about it while there's still time to react, not after. That's the entire skill, and most engineers underrate it because it isn't technical.

Most engineers think the manager has to earn their trust first, but what actually moves your career is your manager being able to trust you with ambiguity.

A manager's scarcest resource is problems they can hand off and stop thinking about. The engineer they trust gets the vague, high-leverage stuff: "our data costs are out of control, go figure it out". No spec, no ticket, just a problem and someone they trust to come back with a working solution. That's the work that gets you promoted, and it only flows to people the manager doesn't have to babysit.

The engineer they don't trust gets the opposite: small, well-defined tickets, tight scope, and frequent check-ins. The manager can't afford surprises from them. Every surprise is something the manager has to explain to their own boss. If you're unpredictable, it becomes a burden on your manager's credibility.

So when you trust your manager and they trust you, the loop compounds. You bring them bad news early, they don't shoot the messenger, you keep bringing it early, they look good upward because nothing blindsides them, they fight for your promo because your wins are their wins. When the trust isn't there, the same loop runs in reverse and you both slowly conclude the other person is the problem.

I've had both in the past. The good version felt like having air cover. The bad version felt like every 1:1 was a deposition. I remained the same and the code remained the same in both cases. The only variable was trust and that was what determined whether I would spend my days creating something new or just defending myself.

We don't usually use the word "trust" for tools, but I think we should make a change .

Every tool you reach for without thinking is a tool you trust. You type git commit and you trust it won't silently eat half your changes. You run a Spark job and you trust that df.count() is actually the count and not an approximation. You've built an entire career on tools you quietly decided to stop verifying.

You know where I am going with this, right?

AI is that same question, scaled up. When people argue about whether to trust an LLM to write their code, they're really asking what we already answered for compilers, ORMs, and autoscalers: how much can you hand off before you lose track of your own system?

You trust a tool as far as you can cheaply check it — and as far as you can survive it being wrong. My compiler gets complete trust — it's been run through a billion compilations, and when it breaks, it breaks loudly. I trust an LLM to write a regex or a throwaway test, because I can read the output in five seconds and nothing breaks if it's wrong. But I won't let it quietly rewrite a financial calculation I'm not going to check, because there the checking is expensive and a wrong answer can sit there for months doing damage before anyone notices.

So both the hype and the panic miss it. It's the same tooling question we've always had — how much can you check before you trust it — just louder now, and with more on the line.

Pull the lens back and the same principle applies to anything you've built. Every real system stands on other people's systems: a database you didn't write, a cloud API you can't see inside, a package you installed with one command and its thousand transitive dependencies you never opened. You typed pip install once and vouched for all of it.

Dependency trust is transitive, and you signed off on almost none of it. You trust your logging library, which trusts a parser, which trusts a compression routine maintained by someone who stopped answering issues in 2019. You didn't audit that tree. Nobody audits that tree. We trust it because it's popular. We call "four million downloads" diligence when it's really just the crowd agreeing not to check either.

And scale isn't proof of safety. When left-pad got unpublished, eleven lines of code broke half the internet's builds overnight. When Log4Shell hit, every team on Earth spent a weekend proving a negative. The xz backdoor was quieter and worse: the attacker didn't beat the trust model, they earned it — years of clean commits until one maintainer's reputation was the exploit.

With a teammate or a tool, trust comes with some control: you can review the PR, run the tool yourself, build a track record over time. With a dependency you get the downside and none of the authority. When it breaks it's still your pager, your incident, your name on the postmortem, even though you never wrote the line that failed and can't fix it now. All the accountability, none of the control.

So the move can't be "verify it" — you can't, that's the entire reason you're depending on it. The only real lever left is to trust it exactly as far as you can survive it being wrong. Timeouts, so a slow dependency doesn't quietly become your outage. A circuit breaker, so one sick service doesn't take the rest down with it. Pinned versions, so nobody upgrades your trust without you in the room. Vendoring the twenty lines you actually use instead of importing a universe to get them. None of that verifies the dependency. All of it shrinks what happens the day the trust you couldn't check turns out to be misplaced.

The entire value of a data platform is trust in its numbers — that's the actual product, and everything else is just plumbing in service of it.

I watched a team burn three weeks chasing "bad data" in a metrics dashboard. Not that the data was dramatically wrong — it was just off, in the way that makes the business quietly stop trusting the numbers, and hence the team behind them. Every job ran green, every test passed, and the problem was a race condition: two scheduled runs overlapped, hammered the same temp table at once, and one silently overwrote the other. Three weeks of wrong numbers shipped before anyone noticed. The pipeline never once announced it was lying.

A dashboard nobody believes is worse than no dashboard, because having no dashboard means at least noone is being actively mislead. The day an executive catches one wrong number is the day they stop believing all your numbers. From then on every figure you produce gets doubted, every decision routes around your pipelines, and you've become expensive infrastructure that no one acts on.

Which is why the real job of data engineering is manufacturing trust in the numbers. Moving bytes from A to B is the easy part. Every tool we obsess over is really about trust.

Tests, contracts, lineage, freshness SLAs, anomaly detection — every one of them exists so that someone three teams away can use your numbers without re-deriving them from scratch. They're how you turn trust into something mechanical instead of something you have to vouch for in person. A data contract is just a trust agreement made executable, so it survives the next reorg and the next person who inherits the upstream table.

Teams, managers, tools, AI, third-party systems, data. Different subjects with completely different mechanics: you build trust with a teammate through reliability and honesty, with tools through what you can check and how it hold up over time, with users through security and consistency, and with data through tests and lineage.

The "how" may change, but underneath the how, it's always the same result: someone decides they no longer have to check the work. That's what trust is, everywhere. It's slow to earn and fast to lose, and worth more than almost any technical decision you'll make. And the quiet failures, the broken things that look fine, do the most damage because they spend that permission before anyone knows to look.

Once you see it this way, your priorities reorder themselves. The flashy refactor matters less. The boring test that lets a teammate sleep matters more. Saying, "I don't know yet, I'll find out," matters enormously, because it keeps your word worth something.

Be the person, the team, the system whose word matches reality — the one nobody has to verify. Everything else — the architecture, the promotions, the product that survives — rests on that.