3 ways Senior Engineers can lose your trust (and how great managers respond)

When your most experienced team members become your biggest challenge.

👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

They got promoted because they were great. They solved the hard problems. They knew the codebase inside out.

But something’s changed. The engineer you counted on most has become the person you trust least. And honestly, you’re wondering if maybe you’re the problem.

I strongly believe that senior engineers break trust differently than junior ones. Junior engineers mess up because they don’t know better. Senior engineers mess up because of the choices they’re making. That’s what makes it so damn hard to fix.

Let me walk you through the three patterns I have identified within the past decade working as an Engineering Manager, and what actually works when you’re dealing with them.

1. Delivery

Sarah was brilliant. Best engineer on the team BY FAR. But she had this habit: she’d commit to delivering a project in two weeks, go quiet for a while, then at the end become visible again with reasons why it was going to take longer.

Senior engineers don’t miss deadlines because they can’t code. They miss them because they can’t say no.

They take on a critical project and get involved in a couple of other initiatives at once. They promise aggressive timelines because they genuinely believe they can pull it off. Instead of raising flags early, they hope they can still make it work.

This absolutely kills trust fast!

When a junior engineer misses a deadline, you adjust their workload. When a senior engineer does it repeatedly, you start doubting everything.. every estimate, every commitment, every technical decision. Your entire planning falls apart.

Now how should you deal with this type of situation as a manager?

Don’t just give them more time. Don’t reduce their load without talking about the real issue.

Do this: As soon as you notice it, name the pattern directly in your next 1:1.

“Hey, I’ve noticed the last three projects have taken significantly longer than we planned. This is creating problems for the whole team. Let’s figure out what’s going on.”

Frame it as a problem you’re solving together, not a performance review.

Then dig into the real cause. In my experience, it’s usually one of three things:

• Burnout. They’re saying yes because they think they should, not because they actually can.

• Can’t see the scope. They genuinely don’t realise how big it is until they’re in the middle of it.

• Hero complex. They’re more focused on being the person who saves the day and helps others than the person who delivers predictably.

“What makes it hard to flag risks early? What would help you feel okay saying no upfront?”

Then, you as a manager need to take action. This is critical and actually most managers skip it. You need to help them rebuild credibility through small wins.

Give them one project with a clear scope and work with them to get to a reasonable timeline. When they deliver, acknowledge it. Do it three times.

This isn’t micromanagement. It’s giving them a path back to being reliable.

My mantra: Do what you say you’re going to do, and be nice with others while you do so. For senior engineers I like to add this: being able to do what you say you’re going to do requires you having the courage to say no to some things.

2. Disagreements

You’re in a team meeting explaining a tough decision. Thirty seconds in, your senior engineer rolls their eyes and gets disappointed.

Or worse: they unmute and say, “Has anyone actually thought this through? Because this seems short-sighted to me.”

This isn’t healthy debate. Healthy debate happens before decisions are made.

The eye rolls in meetings. The “I guess we’re doing this” energy. The Slack DMs where they tell other engineers they wouldn’t have made this choice.

Every time a senior engineer publicly dismisses your judgment, they’re not just disagreeing with a decision. They’re teaching the team that your leadership is questionable. They’re giving everyone permission to half-commit.

And the worst part is they usually don’t think they’re doing anything wrong. They think they’re “being honest” or “raising concerns”. They might even see themselves as protecting the team from bad decisions.

You need to have a direct conversation with them.

“I value your input, which is why I want it before we make decisions. But once we’ve decided, I need you to support it, even when you disagree. That doesn’t mean you pretend you loved it. But it does mean you can’t undermine it publicly.”

Get specific: “Last week when you said [specific thing], it came across as dismissive. If you have concerns after a decision, bring them to me first. Give me a chance to address them. But public dismissiveness isn’t acceptable.”

However, you have a role to play if you get reactions from your engineers like this: Create channels for input before decisions are made.

A team with aligned senior engineers who are pretty good will perform better than a team with brilliant senior engineers working against you or each other.

3. Gatekeeping

This one’s sneaky because at first it looks like they’re just really good at their job.

They’re the only person who understands the payment system. They block PRs because “that’s not how we do it” without explaining the right way. Everyone has to Slack them when payments break.

They’ve made themselves indispensable.

And they’re killing your team.

It shows they care more about being important than about the team succeeding.

Real IC seniority (much like management) is about how efficiently problems get solved even without you. Knowledge hoarders measure value by how many problems need them.

A previous team I worked with suffered deeply from that. An engineer, let’s call her Emma, built an entire service alone while the rest of the team was working on a different high visibility project. That was fine.. it was what we decided to do as a team at the time. However, when the rest of the team became available and wanted to gain familiarity with what she had built, Emma was not having it. When someone asked how it worked, she’d give a rushed explanation instead of actually teaching them.

At some point, naturally, Emma went on vacation. Her service broke and alerts were firing. The team spent six hours trying to get a critical fix out because nobody understood the system.

When she got back, she seemed almost... pleased that they’d needed her.

SHOCKING!

Now.. how is a good way to manage a person with this behaviour.

Don’t just ask for documentation. Don’t request knowledge transfer sessions and hope they’ll start sharing.

Knowledge hoarding is linked to identity and fear. People think their value comes from what only they know. Asking them to share feels like asking them to give up their advantage.

You need to reframe what seniority means.

“I want to talk about your impact. Right now, you’re the sole expert on XX service. That actually limits you, because real senior engineers multiply their impact through others. The question is: how do we get you from irreplaceable to force-multiplying?”

“Over the next quarter, I would like you to train two engineers to handle 80% of auth issues without you. Not just creating docs, I’d like to see pairing, PR reviews that teach others, and real ownership of this goal. Success means others solve problems without needing you.”

Link their growth to enabling others: “Getting to the next level means making the team more capable, not just solving hard problems yourself.”

Knowledge hoarders are usually afraid. Afraid that if they’re not the expert, they won’t matter. Afraid juniors will mess up. Afraid sharing will reveal they don’t know everything.

Address it: “I’m not asking you to become less valuable. I’m asking you to change how you create value. Right now you’re a bottleneck. If you enable everyone else to be great, you become irreplaceable in a much better way.”

Final thoughts

Senior engineers lose your trust when they optimise for their own importance over team success.

And you lose the team’s trust when you let these patterns continue.

Your team is watching. They’re learning what’s actually acceptable based on what you do, not what you say. Every day you don’t address these issues, you’re teaching them that seniority means having different rules.

Managing senior engineers who’ve lost your trust is lonely. Maybe they have a great relationships with your boss. Or they’ve been around longer. They’re technically and behaviourally just strong enough that a performance plan is not justified.

But your job isn’t to make everyone happy. It’s to build a team that delivers and trusts each other.

When a senior engineer loses your trust, you have to rebuild it through clear expectations and real behaviour change.

Many managers sadly do nothing and hope it gets better.

It won’t.

Give them a real shot with clear feedback. Set goals and a timeline. Three months is usually enough to see if change is real or just performative.

If they can’t or won’t rebuild trust, this is when you should really start talking with HR and putting a PIP together.

Your best engineers are watching. They’re deciding whether to stay based on whether you’ll hold everyone to the same standard.

Hope that’s a wake up call for some and some action is taken off the back of this post.

That’s all folks!

See you in the next one,
~ Stephane