Building Trust With a New Engineering Team

Two weeks into my new role as engineering director, I made my first big mistake. I reorganized the on-call rotation because it "obviously" needed improvement. The old schedule had quirks that seemed inefficient from the outside. What I didn't know was that those quirks were accommodations the team had carefully negotiated—one engineer had a chronic health condition, another was a single parent with specific custody schedules.

The team's reaction wasn't anger—it was something worse. It was quiet withdrawal. Messages got shorter. Eye contact in meetings decreased. I had eroded trust before I'd even finished learning people's names.

That experience permanently changed how I approach new teams. Trust isn't something you bring from your previous role—it resets to zero every time.

The Trust Equation for Engineering Leaders

I think about trust as having four components, borrowed from David Maister's framework but adapted for engineering leadership:

Component	What It Means	How You Build It
Credibility	"They know what they're talking about"	Demonstrate technical depth without showing off
Reliability	"They do what they say they'll do"	Small consistent follow-throughs
Intimacy	"I feel safe telling them things"	Protect information shared in confidence
Self-Orientation	"They care about us, not just themselves"	Make decisions that prioritize team over personal brand

Trust = (Credibility + Reliability + Intimacy) / Self-Orientation

The denominator matters most. A leader with high credibility but high self-orientation is a politician. Engineers detect politicians instantly and respond with strategic information sharing—they tell you what you want to hear rather than what you need to know.

The First 30 Days: Listen More Than Talk

My rule for the first month with any new team: my contribution ratio should be 20% talking, 80% listening. This feels uncomfortable—especially if you were hired to "fix things"—but it's essential.

What listening looks like in practice:

• 1:1s with every team member in the first two weeks, with questions like "What's working well that I should be careful not to break?" and "If you could change one thing, what would it be?"
• Silent observation in existing meetings. Attend but don't drive the agenda.
• Code and document archaeology: Read the last six months of RFCs, postmortems, and architectural decisions. Understand the team's history before trying to write their future.
• Shadow on-call: Sit in on at least one on-call shift to understand the operational reality.

One of my most powerful trust-building moves has been asking: "What did previous leadership get wrong?" This question signals that I'm not here to defend the status quo and that I value their perspective on what needs to change.

Demonstrating Technical Credibility (Without Overstepping)

Engineers respect technical competence, but they resent technical overreach from managers. The line between "credible leader" and "backseat driver" is thin. Here's how I walk it:

Do: Ask thoughtful questions in design reviews that show you understand the tradeoffs. "Have you considered the read/write ratio at our projected scale? This pattern might need a different indexing strategy."

Don't: Dictate implementation details or push your preferred technology stack in the first months.

Do: Pair program occasionally when invited. Share relevant war stories from previous roles when they add context to current decisions.

Don't: Submit code to prove you can still code. Your job is to make the team effective, not to be an individual contributor.

Do: Understand the codebase well enough to have informed opinions about architecture.

Don't: Use your architectural opinions to override the team's decisions before you've earned the context.

The best demonstration of technical credibility is asking questions that nobody else thought to ask—questions that reveal a deep understanding of systems thinking without prescribing solutions.

Small Promises, Consistent Delivery

Reliability is built through small, consistent follow-throughs—not grand gestures. When someone mentions a problem in a 1:1, follow up the next week with what you did about it. When you commit to investigating something, report back within the timeframe you promised.

I keep a simple tracking document for myself:

Promise	To Whom	When Made	When Due	Status
Look into CI flakiness	Alex	Monday 1:1	Next Monday	Completed - filed ticket #4523
Discuss career growth path	Priya	Wednesday	By Friday	Meeting scheduled
Escalate infrastructure budget	Team	Retro	2 weeks	In progress - meeting with VP

This might seem overly formal, but I've learned that forgetting a single commitment in the early days costs disproportionate trust. The team is watching closely to see if your words match your actions.

Creating Psychological Safety

Trust requires psychological safety—the belief that you won't be punished for speaking up. As a new leader, you haven't yet proven that you're safe. You need to actively demonstrate it.

Three practices that accelerate psychological safety:

Reward the messenger: When someone brings you bad news early, thank them publicly. "I'm glad you flagged this now. This gives us time to address it properly." This teaches the team that honesty is valued.

Own your mistakes publicly: Share your own errors in team meetings. Not performative self-deprecation, but genuine accountability. "I underestimated the complexity of that migration. Here's what I should have done differently."

Protect the team externally: When stakeholders are frustrated, absorb the pressure rather than passing it through. Your team should hear "I'm working with leadership on the timeline" rather than "The VP is angry about the delay."

Avoiding Common New Leader Mistakes

Through my own failures and observing others, I've compiled the most trust-destroying behaviors in the first 90 days:

• Reorganizing too quickly: You don't understand the implicit social contracts yet
• Comparing to your last team: "At my previous company, we did X" breeds resentment
• Changing tools immediately: Tool changes signal that you don't trust the team's prior choices
• Playing favorites: Spending disproportionate time with one or two people creates insider/outsider dynamics
• Ignoring history: Dismissing past decisions without understanding the constraints that produced them
• Over-promising to leadership: Committing the team to aggressive timelines before understanding their capacity

The theme across all of these: they prioritize the leader's comfort over the team's stability. Trust comes from demonstrating that you'll prioritize the team.

The Trust Accelerator: Quick Wins That Matter

While you should avoid big changes early, small improvements that address long-standing pain points build trust rapidly. The key is choosing wins that the team has already identified as problems rather than imposing your own priorities.

In my current role, my quick wins included:

• Fixing the flaky CI pipeline that had annoyed everyone for months
• Getting budget approved for ergonomic equipment people had requested
• Removing a weekly status meeting that everyone agreed was useless
• Setting up a documentation template that reduced onboarding friction

Notice that none of these are strategic or controversial. They're small, concrete improvements that demonstrate "I listened and I acted." They also show that you have organizational capital and you're spending it on the team's behalf.

When Trust Is Broken

Despite best efforts, you will occasionally break trust. What matters is how you repair it.

My repair process:

1. Acknowledge specifically what happened and how it impacted the team
2. Don't explain why you did it (this sounds like justification)
3. State what you'll do differently going forward
4. Follow through consistently on that commitment
5. Give it time—trust repairs slower than it breaks

I once accidentally shared salary band information for a role in a meeting where that information wasn't appropriate. Instead of hoping nobody noticed, I addressed it directly: "I made an error sharing that information in this context. That shouldn't have happened, and I'll be more careful about what I share and where." The team respected the directness.

Key Takeaways

• Trust resets to zero with every new team—your reputation doesn't transfer automatically
• In the first 30 days, maintain a 20/80 ratio of talking to listening
• Demonstrate technical credibility through thoughtful questions, not dictating solutions
• Build reliability through small consistent follow-throughs tracked systematically
• Create psychological safety by rewarding messengers and owning mistakes publicly
• Avoid common new leader mistakes: reorganizing too fast, comparing to past teams, changing tools prematurely
• Choose quick wins the team already identified rather than imposing your own priorities
• When trust breaks, acknowledge it specifically, state what changes, and give it time

Building trust is slower than most new leaders want it to be. But the alternative—moving fast without trust—means every decision meets resistance, every change creates anxiety, and your best engineers start looking for exits. The patience you invest upfront compounds into speed later.