Most engineering teams think most of their blockers are technical.
Spoiler: they're not.
Not even close.
The brutal truth? The brutal truth? Most engineering teams are hemorrhaging productivity, and they blame a leaky abstraction.
We, as engineers, are hardwired to think our blockers are technical: Legacy Monoliths. Slow CI Pipelines. That one service Aris wrote.
But I'm here to tell you that in a shocking number of cases, the "technical problem" is just a cheeky little distraction. The real issue is far squishier, far more uncomfortable, and it starts with a capital T for Trust.
Low trust doesn't look like a relationship problem; it looks like a system failure.
Let's break down how your lack of faith in your teammates is secretly making your code worse and your life miserable.
1. The High-Trust Paradox: How Mediocre Tech Ships Anyway
Imagine a team of developers who genuinely like and respect each other (yes, it happens). In this magical place, you see things that look like professional miracles:
- Sharing context instead of just aggressively closing a ticket
- Admitting uncertainty on Slack: "Wait, I'm actually not 100% sure how our ml pipeline handles scheduled requests"
- Pairing without a passive-aggressive sub-battle for who is smarter
- Giving honest code review feedback because they know you won't cry in the bathroom
- Documenting because they care about the poor soul who inherits their work in three years (i.e., Future Them)
When these behaviors are the default, the tech stack doesn't matter as much. You could be running a PHP monolith from 2008, but because everyone is relaxed, aligned, and collaborative, you still ship real, measurable value.
The take-home: High-trust teams make messy systems workable.
2. The Low-Trust Contamination: When Perfect Tech Falls Apart
This is where it gets interesting. When trust is in the toilet, engineering issues suddenly look like the result of technical decisions.
| The Alleged Tech Problem | The Actual Trust Problem |
|---|---|
| ❌ PRs stuck in review for a week | Reviewer doesn't trust the author, they're looking for reasons to reject it |
| ❌ Over-engineering the simplest feature | No one trusts that others won't break things later, so they build a moat of complexity |
| ❌ Endless rewrites & framework flips | The team doesn't trust the existing patterns or the engineers who built them (Hi, Aris) |
| ❌ Managers inserting excessive process | Managers don't trust engineers to act autonomously, so they introduce approval steps |
| ❌ "Surprise" production incidents | Engineers saw the warning sign last week but were too afraid to bring it up |
Low trust corrupts every workflow it touches. It turns collaboration into a zero-sum game of self-preservation.
3. The Silent Killers That Turn People Into Code-Hoarders
Trust erosion starts small. One engineer silently fixes a bug instead of coaching the junior who wrote it. One team lead throws a bit of blame around in a postmortem. A successful refactor gets blocked.
Soon, you have a team that is optimizing for Safety over Learning.
The most common culprits that kill psychological safety:
A. The Hero Culture
It's not because the "rockstars" are so good, it's because no one else is allowed to be good. They become a self-imposed bottleneck.
You celebrate the martyr who worked until 3 AM instead of the mentor who coached the team to prevent the fire in the first place.
B. Blame-Driven Postmortems
"Who caused this?" is the most destructive question a team can ask. It ensures the next failure will be even bigger because people will spend all their energy hiding the problem instead of fixing it.
C. Senior–Junior Hostility
Seniors think juniors break things. Juniors think seniors are gatekeeping the good work. Both sides are operating from a place of fear and lack of respect.
The codebase is now a battlefield and every function is a landmine.
4. How to Stop Pretending Your Slow Team Needs More Process
Leaders: when you complain that your team is "slow," "fragile," or "needs a rewrite," what you're actually saying is:
| Leadership Complaint | Trust Diagnosis |
|---|---|
| "Our team is slow" | Low trust prevents engineers from asking clarifying questions early on |
| "Our systems are fragile" | No one trusts each other enough to refactor risky parts |
| "We need more process" | Leadership doesn't trust engineers to self-organize |
Spoiler Alert: Adding more process (more Jira fields, more approvals) is like treating a bullet wound with a bandaid. It fixes the bleeding and guarantees the next infection.
5. Three Ways to Start Rebuilding Trust Today
You don't need a massive team retreat. You just need to change the operating system of how you interact.
1. Make Uncertainty Safe
Stop rewarding the person with all the answers. Start normalizing phrases like:
- "I don't know yet, but I'll find out"
- "That's a good question. Let's look at the docs together"
2. Replace Blame with Curiosity
Postmortems should always start with: "How did the system allow this to happen?"
(Notice it’s not: “Who touched the thing?”)
The focus is on the process and the system, not the person.
3. Reward Knowledge Sharing, Not Gatekeeping
When you promote, prioritize the engineer who makes the team better (the mentor, the documenter, the pair-programmer), not the one who knows all the secrets and refuses to share them (the hero/martyr).
The Final Truth
When people trust each other, teams become faster, cleaner, more stable, more creative, and shockingly more fun.
The best engineers solve technical problems.
(The worst ones write services like Aris.)
The best engineering leaders solve trust problems.
What trust issues have you seen masquerade as "technical debt" on your team? Drop a comment below. 👇
Top comments (0)