The Problem Beneath the Problems
If you’ve been following along with recent posts, you may have noticed a pattern.
In From Scripts to Strategy, we explored what happens when developers start thinking bigger—designing systems, not just shipping tickets. That kind of initiative doesn’t survive in low-trust environments. Without psychological safety, those ideas stay in local scripts and side branches, never making it to the roadmap.
In Shut Up, Meg: Why Devs Don't Speak Up, and What It Costs, we talked about silence... not as compliance, but as a signal of burnout and disengagement. When engineers stop speaking up, it’s rarely because everything is fine. It’s because they’ve stopped believing that speaking up will matter.
In The Cost of Carrying Broken Things, we exposed the quiet tax your team pays every day for systems that no longer work, but have been absorbed into the definition of “normal.” What makes those costs persist isn’t just technical inertia; it’s the learned helplessness that sets in when engineers no longer trust leadership to prioritize real problems.
In If It Ain’t Broke, Fix It Until It Is?, we explored the way that trust erodes when management over-manages... how the "continuous reorg culture" damages the gains you want to make.
And in Trust is the New Pizza Party, we said the quiet part out loud: that you cannot bribe your way into loyalty. The real retention strategy is trust... and trust is a pattern, not a perk.
Put simply:
You do not get reliable systems, honest feedback, or continuous improvement in a culture of distrust.
If engineers don’t trust you to hear them, back them, or act with clarity, they’ll stop telling you what’s broken.
Worse, they’ll stop showing you what’s possible.
And if you’re sitting in a leadership role reading this thinking, "But I’m not like that. I do care," go read The Cultural Compartmentalization Paradox. Caring about engineers in your mind doesn’t help if your behavior is sending the opposite signal in every meeting, every decision, every deadline push.
Easy there, Blink... Shots Fired
Hold on, now... this post isn’t about placing blame. It’s about giving you a way back.
A way to build - intentionally, consistently, and concretely - the kind of trust that makes engineering teams thrive.
Because trust isn’t a vibe, and it’s not a bonus.
It’s your infrastructure.
And if yours is broken, everything you’re building on top of it is at risk.
Common Missteps That Break Trust (Even When You Mean Well)
Trust doesn’t usually collapse all at once. It erodes in layers, quietly and incrementally, through patterns that feel normal from the top but corrosive from below.
Here are some of the most common ways leaders break trust with engineers without realizing it:
🧩 Mandating Without Context
Engineers don’t expect to make every decision. But when major architectural shifts, operational changes, tooling decisions, or tech stack mandates show up out of nowhere, it sends a clear message:
We don’t trust you to think. We just need you to comply.
You may have had a good reason. But if that reason isn’t communicated EFFECTIVELY, if you didn’t take the time to explain the “why” behind the “what”... you’re not leading, you’re announcing.
And engineers will take note.
🏁 Prioritizing Speed Over Sustainability
The phrase “we just need to get it out the door” has a half-life of zero. Every time you override engineering concerns in favor of urgency, you're signaling that delivery matters more than durability.
The short-term win almost always comes at a long-term cost:
Fragile systems
Burned-out devs
Institutional avoidance of risk
Do you know who has to shoulder the stress caused by these costs? (Hint: It's not your C-Suite)
Additionally, every time you play the "just get it done ASAP" card, you train your team not to bring up their concerns next time, because they already know how that conversation ends.
🧱 Treating Engineers Like Resources, Not Humans
I once worked in a shop where people - red-blooded human beings with hopes, dreams, desires, and ambitions - were called "resources". It still irritates me to no end: "Hey Bob, can you ask Jeri's team for a resource to work on this project defect?" If I were Jeri, I'd hand you a labelmaker and wish you luck. People are not resources and you remove their personhood when you refer to them as such.
There's a school of thought called "matrix-based organization" where pools of individuals with shared knowledge are treated as interchangeable. On the surface it's a rad idea: if you're in a bind and someone on your project is unavailable, you can just plug & play with another person from their team.
What it completely fails to understand? A little thing called Human psychology.
If you’re constantly reshuffling teams, swapping engineers between projects like interchangeable parts, don’t be surprised when they disengage.
Trust thrives on relationships. Systems knowledge is not just in documentation, but in people. When those people feel replaceable, they stop investing.
🛠️ Confusing Tooling with Trust
I've also seen management try to buy a shiny new platform or rolling out a metrics dashboard in an effort to improve culture. The problem is that these activities don't actually rebuild trust. In fact, if the team is already under pressure, a new way to view metrics can feel more like surveillance than support.
Engineers don’t want more dashboards. They want leaders who ask, “What’s slowing you down?” AND THEN DO SOMETHING ABOUT IT.
It's important to note that these aren’t malicious mistakes. In most cases, they’re made with good intent.
But trust isn’t about intent. It’s about impact.
And if you’ve seen morale dip, feedback dry up, or delivery quality suffer—these missteps might be where the cracks started.
A Practical Guide to Rebuilding Trust with Engineers
You don’t fix trust with a memo. You fix it by showing up differently, over and over again, until the pattern changes.
Here are practical ways you can start today... with no reorg required:
🪑 Show Up in Engineering Spaces (Without Taking Over)
You don’t need to be technical to be present. Join a demo. Listen in on a retro. Drop by a team Slack channel without demanding anything.
When you show up with curiosity instead of authority, engineers notice. And when they believe you’re listening, they’ll start talking.
An important caveat: If you ever use a shred of what they say or demonstrate in a way that blows back negatively upon them, THEY WILL NEVER TRUST YOU AGAIN. It takes a lifetime to build trust and just a few seconds of being a bonehead to lose it forever.
🎙️ Invite Technical Dissent—and Reward It
If you ask for feedback but punish honesty with silence, rework, or politics, you won't get honesty again.
Instead:
Celebrate the engineer who says, “This won’t scale.”
Pause when someone says, “We’re doing this wrong.”
Promote people who raise risks early—not just those who deliver under duress.
Dissent is a form of trust. Don’t waste it.
🧭 Protect Long-Term Thinking
If you want systems that last, you have to defend the time and space required to build them.
That means:
Supporting test coverage and observability even when “it’s not on the roadmap.”
Letting teams invest in the boring stuff: CI/CD, infrastructure, developer tooling.
Saying “not yet” to a feature request when the foundation needs work.
Trust grows when engineers see that you’re prioritizing health over hustle.
🔄 Close the Loop on Feedback
The fastest way to kill trust is to ask for input and never follow up. Engineers have watched too many town halls end in applause and inaction.
When you collect feedback:
Acknowledge it.
Act on it when possible.
Explain when you can’t.
Clarity builds trust—even when the answer is no.
🧪 Model Vulnerability and Learning
Say “I don’t know.”
Say “You were right.”
Say “I didn’t understand how painful that was.”
You don’t need to pretend to be technical. You need to show you’re willing to learn and adapt.
Engineers don’t need you to write code.
They need you to be trustworthy in the face of complexity.
None of these are grand gestures. But that’s the point... Trust isn’t earned all at once.
It’s rebuilt in moments.
Top comments (0)