Your Engineers Aren't the Problem. Your Management Is.
Why trust and autonomy outperform control every time
Introduction: "Good Inside" – A Radical Perspective
Traditional management sees engineers as tasks to manage, resources to allocate, or problems waiting to happen. But here's a radical thought:
Your engineers are good inside.
They inherently want to do well. They genuinely care about their work and its outcomes. Your job as a leader isn't to control their actions meticulously but to trust their intentions deeply.
Assume competence, assume good intentions. Trust, and watch your team's potential become reality.
The Cost of Assuming Bad Intentions
Consider the cost of distrust. Managers who assume laziness or incompetence inherently create a defensive environment. Engineers become cautious, unwilling to risk mistakes or share ideas. Mistakes get hidden, creativity shrivels, and quality sinks. Managers see every delay or issue as proof of their assumptions, reinforcing negative cycles.
Distrust create micromanagement.
Micromanagement creates resentment.
Resentment creates underperformance.
It's an expensive, destructive cycle. Trust, on the other hand, is cheaper. Far cheaper than fixing the mess distrust creates.
Your Engineers Want to Succeed
The truth that shifts everything is that your engineers want to succeed. They want to deliver great work. Failures or missed deadlines rarely signify negligence or apathy. Usually, they're signals of hidden obstacles, unclear instructions, or unmanaged dependencies.
When you assume positive intent, you change your conversations from interrogations to collaborations.
Instead of "Why isn't this done?" you ask, "What's blocking you?"
Small shift, big impact.
Engineers feel safe, problems surface sooner, and solutions flow faster.
A Real-World Example #1: Navigating a Major Incident
I learned this vividly after one particularly nasty production incident. My team had introduced a change causing significant customer pain. Anxiety and tension filled the air the next morning. I could have stormed in frustrated and disappointed.
But I didn't.
I chose trust.
I arrived calm and supportive, signaling clearly: I know this team didn't cause issues intentionally. We held a blameless postmortem, digging methodically into root causes, gaps in our processes, and preventive measures. No blame, no finger-pointing, only learning.
The impact was immediate. The team felt safe, deeply engaged, and motivated to correct and improve. The incident became a catalyst for growth rather than a scar of shame.
The takeaway? Leaders set the tone. Trust transforms crises from blame-games into constructive breakthroughs.
Psychological Safety as a Driver of Performance
Trust isn't fluffy- it's strategic. The highest-performing engineering teams possess a secret ingredient: psychological safety. Engineers perform best when they're confident they won't be punished for mistakes, doubts, or challenging ideas.
Psychological safety means your engineers won't hide a bug or fake confidence when they're uncertain. They'll speak up early, flag risks proactively, and admit mistakes quickly.
The best engineers aren't those who never make mistakes. They're the ones who aren't afraid to make them openly and learn publicly.
You build psychological safety through trust, transparency, and consistent positive reinforcement. Publicly praise open communication. Treat mistakes as opportunities to refine processes, not as signals of incompetence. The return on psychological safety is outsized productivity, genuine innovation, and a highly resilient team.
Real-World Example #2: Trusting the Team’s Autonomy
Trust also mean empowering your people.
Once, I gave my team a task intentionally large and ambiguous enough to require collaboration. I provided clear context, a deadline, and crucially- I stepped back.
Could they handle it without micromanagement?
They didn't just handle it. They thrived.
Within hours, they'd organically self-organized, divided tasks, collaborated closely, and integrated their solutions. They delivered quickly and effectively. No rigid prescriptions, just trust and autonomy.
This wasn't just efficient, it fundamentally changed my management style. It vividly showed that autonomy coupled with trust unlocks performance. It taught me to resist control, trusting the innate capability of my team.
Practical Framework: Building a Culture of Autonomy and Trust
Here's how you create trust practically:
Clear mandates, minimal micromanagement: Define clear goals and boundaries but leave detailed execution to the team.
Encourage self-organization: Trust your engineers to organize tasks and workflows. Let them own the how.
Offer support without intrusion: Clearly signal your availability for help but avoid unsolicited oversight.
Effective communication phrases include:
"I trust your judgment."
"Let me know how you're planning to approach this and how I can help."
"What obstacles can I remove for you?"
Addressing Skepticism: Accountability vs. Trust
But what about accountability?
Trust doesn't exclude accountability. It reshapes it.
Accountability becomes constructive rather than punitive. It’s about clarity, expectations, and support. Not blame.
Accountability isn’t consequences. It’s ownership.
Leaders must clearly communicate expectations, define success explicitly, and step in firmly (but supportively) when performance consistently falls short. Conversations shift from accusations to explorations: “I know you're capable. Let’s figure out what's hindering you and fix it.”
Trust paired with clarity creates healthy accountability. Engineers grow more responsible, not less.
Tools for Building and Maintaining Trust
Concrete tools to implement immediately:
Regular trust-focused one-on-ones: Prioritize conversations about blockers, motivations, and support. Use these sessions to deeply understand each team member's personal goals, frustrations, and aspirations. Create an environment where honest communication about challenges and mistakes is normalized and encouraged. Regularly ask questions like, “What can I do to support you better?” and “Where do you feel stuck or uncertain?”
Constructive retrospectives: Make team reflections positive, solutions-oriented, and blame-free. Establish clear guidelines at the start of each retrospective emphasizing psychological safety and collective growth. Encourage team members to share openly, acknowledging mistakes without fear of retribution. Ensure retrospectives always conclude with clear, actionable improvements and assigned accountability for follow-up tasks.
Structured peer reviews: Normalize collective responsibility and reinforce mutual trust and respect. Ensure peer reviews go beyond mere compliance checks—encourage reviewers to engage deeply, asking questions that clarify intent and challenge assumptions respectfully. Facilitate training sessions for effective reviewing practices, emphasizing empathy and constructive feedback rather than criticism.
Recognition and public acknowledgment: Regularly and authentically acknowledge individual and team efforts publicly. Celebrate not just successful outcomes but also behaviors that align with your trust and autonomy values, such as proactive communication, innovative problem-solving, and collaboration.
Clear and consistent communication: Establish transparent and consistent communication practices, clearly articulating expectations and deadlines while continuously reminding the team of the trust placed in them. Reiterate regularly that seeking help or voicing uncertainty is a sign of strength, not weakness.
Joke around: Seriously. Be respectful, but don’t be afraid to just have a good time in each other’s company. Teams that laugh together, stay together.
These practices continuously reinforce the assumption of good intent, creating an environment where trust is the foundation for sustained excellence.
Challenges and Pitfalls of Assuming Positive Intent
No strategy is without risk. Assuming good intent doesn't mean ignoring underperformance or tolerating chronic problems. The balance lies in distinguishing temporary blockers from genuine performance issues.
Trust doesn't prevent hard conversations; it shapes their tone and effectiveness. Address performance clearly and honestly, never defensively or angrily. Reinforce accountability with support and clarity.
Recognize when trust is truly broken or abused, address it transparently, and act decisively.
Trust-based management isn't naive; it’s nuanced and vigilant.
Your Engineers Are Good Inside: A Self-Reinforcing Cycle
Trust initiates a clearly defined, self-reinforcing cycle:
Trust creates psychological safety. Psychological safety fuels open communication, proactivity, and effective collaboration. High performance achieved through autonomy and openness further reinforces trust, accelerating continuous upward momentum.
Trust is self-amplifying. Good management leverages this virtuous cycle, creating sustainable excellence.
Conclusion: Trust is Transformational
Your team's potential is immense.
Recognizing their inherent goodness, trusting their intentions, and empowering their autonomy is transformative.
Trust doesn't merely improve results; it fundamentally transforms your team's identity, morale, and long-term performance. Engineers who feel trusted and respected are resilient, motivated, and committed.
Begin today.
Make trust your default position.
Assume your engineers are good inside, and they'll consistently prove you right.
You may also enjoy
Your Team's Boundaries Are Terrible. Here Are 6 Ways to Fix Them.
Introduction: The Reality Check of Boundaries
Happy Engineers Ship. Miserable Engineers Interview Elsewhere.
Engineering teams do not fail because of bad technology choices. They do not fail because of outdated frameworks, slow CI pipelines, or lack of microservices. These are symptoms, not root causes. Teams fail because of demoralization—because the people writing the code stop caring. And when developers stop caring, everything grinds to a halt.
As a product manager that recently absorbed that recently the technical management and FP&A of my software team (my org did some major restructuring), I believe autonomy and trust is needed.
I’ve been trying to “protect” the SDEs as much as possible, and that little change vs former management has moved the needle so much more.
Or maybe since I have an engineering background, I have a deeper empathy of the work.
Anyways, this is an excellent piece and thank you for sharing!