AI is breaking how your team builds trust

Senior engineers earned influence by solving hard problems. Is this changing?

Apr 07, 2026

👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.

To accelerate your growth see:

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

You’ve got a Senior Engineer or Tech Lead who used to be the gravitational centre of your team. When things broke, they fixed them. When nobody could figure out why the service was choking, they found the problem. When architectural decisions needed to be made, people looked at them.

Now they come to you frustrated. “Nobody listens to me anymore.” Or worse, they don’t come to you at all - they just disengage.

What happened is subtle. The mechanism that senior engineers used to build trust (being the person who solves the problems nobody else can) has been undercut. Not eliminated. Undercut. And most managers haven’t adjusted to what that means for their team’s decision-making.

The old trust-building loop is broken

For the last twenty years, experienced engineers earned influence through a specific loop. Someone gets stuck on a gnarly problem. They ask the senior person. The senior person either solves it or points them in the right direction. Over time, this creates a track record. The track record creates trust. The trust creates influence. The influence shapes architectural decisions, technical direction, team norms, etc.

I wrote about a version of this when looking at why your best engineers stay silent in meetings - the flip side of the same coin. When people don’t ask questions, seniors can’t demonstrate what they know. The trust loop never starts.

AI tools have introduced a new variable to this equation. Your mid-level engineers aren’t stuck as often anymore. They paste the error into Claude, get a plausible answer, and move on. They don’t need to walk over to the senior engineer’s desk (or ping them on Slack). The problem gets solved, or at least appears solved, without the experienced person ever being involved.

This isn’t a complaint about AI. The tools of course are genuinely useful. I use them daily. But the second-order effect is that your senior engineers are losing their primary stage for demonstrating competence. And without that stage, their influence erodes.

It happens slowly. First, fewer people come to them with questions. Then their suggestions in design reviews get more pushback. Then someone says “well, Claude suggested a different approach” in an architecture discussion, and suddenly a decade of hard-won pattern recognition is competing with a tool that sounds confident about everything and has zero context about your system’s actual failure modes.

This isn’t actually about AI

If you’re managing a team where this dynamic is emerging, your first instinct might be to address the AI part. Set guidelines for when to use AI versus when to consult the team. That’s fine, but it misses the deeper issue.

The real problem is that most technical authority on engineering teams was built on a single foundation: being the person who can solve things. That was always fragile. What happens when that person goes on holiday? What happens when they switch teams? What happens when the codebase changes enough that their knowledge becomes stale?

AI just accelerated an existing vulnerability. Your senior engineers’ influence was already narrower than they thought. It was tied to a specific activity - debugging, firefighting, knowing where the bodies are buried, rather than to the broader set of skills that actually make someone worth listening to.

And as a manager, you probably reinforced this without realising it. You praised them for saving the day. You pointed to them as the “go-to person”. You built a system where their value was visible primarily when things went wrong.

What AI can’t do (and your seniors need to lean into)

There’s a specific set of capabilities that no AI tool can replicate, and it maps almost exactly to what distinguishes a good senior engineer from a fast coder. If you’re managing someone who’s losing influence, help them redirect their energy toward these:

Predicting failures that haven’t happened yet. An LLM can tell you how to implement a message queue. It cannot tell you that this particular team tried a similar approach eighteen months ago and it fell apart because the on-call rotation couldn’t handle the operational overhead. That kind of judgement is worth more now than it was before AI. But it only works if the person communicates it well enough to be heard.

Reading organisational context. The reason a proposed architecture is wrong might have nothing to do with technology. Maybe the team that would own the new service is already stretched thin. Maybe the VP who championed the last migration is still bruised from how it went. Maybe the compliance team will block it in three months. This is stakeholder management, and it’s where experienced people should be spending their energy.

Building consensus across teams. This is the one that separates a good senior from a great one. When every engineer on the team can point to their own AI-generated solution and say “this is the right approach” someone needs to be the person who gets everyone rowing in the same direction by being the person who understands what each team needs and can find the design that satisfies the most constraints.

The shift I’m describing isn’t new - it’s the same transition that happens when any IC moves toward staff-level work. The difference is that AI is forcing it to happen faster, and on people who might not be ready for it.

What you should do as the manager

If you’re noticing this pattern you can’t just wait for it to sort itself out. It won’t.

Stop rewarding firefighting. If the primary way your team recognises seniority is “who saved us during the outage”, you’re building a brittle authority model. I’ve written about the gap between shipping fast and understanding deeply - this is the leadership version of the same problem. Start recognising people for the decisions that prevented fires, not just the ones who put them out.

Create structured venues for experience to show up. If casual hallway problem-solving is disappearing (and it is, between remote work and AI), you need to replace it with something intentional. Design reviews where the senior engineer isn’t approving designs but asking the questions nobody else thought of. Architecture decision records where the “why not” is documented alongside the “why”. I put together a technical decision framework that gives this kind of structured discussion a format - it’s worth trying if your team’s design conversations have become a free-for-all.

Coach your seniors on influence without authority. This is the hardest conversation to have, because it feels like you’re telling someone that being good at their job isn’t enough anymore. But that’s kind of the truth. The ability to get buy-in when you don’t have a title that forces compliance is a skill, and it’s one that many technically excellent people haven’t had to develop until now. If you’ve got someone who’s struggling with this transition, a few 1:1 conversations focused specifically on how they’re building influence can make a real difference.

Address “but the AI said” head-on. When someone dismisses another engineer’s recommendation by citing an LLM, that’s a team norms problem, not a technology problem. You wouldn’t accept “well, some blog post said otherwise” as a counterargument in a design review. The same standard should apply. The team should be debating the merits of approaches, not their provenance. Establish that in your code review culture and your design review norms.

The opportunity hiding inside this shift

There’s a version of this that works out well. Not the one where your seniors fight against AI and lose. The one where they stop competing on “I can solve this faster than you” and start competing on “I can see around corners that you can’t”.

The engineers that navigate this transition successfully all do the same thing: they stop being the oracle and start being the navigator. They trade “here’s the answer” for “here are three paths, and here’s the thing the AI can’t tell you about each one”. They stop trying to be indispensable for what they know and start being indispensable for how they think.

That’s an evolution from the person who fixes the code to the person who shapes the system. If you’re managing a team, your job is to help your experienced people make that jump. Before they get frustrated enough to leave. Before the team loses the institutional knowledge that, AI or not, no amount of context windows can replace.

I spent years building tools for exactly these kinds of leadership transitions. If you’re an EM wrestling with how to develop your senior engineers’ influence skills, the EM Field Guide covers this in the chapter on stakeholder management and difficult conversations - it’s 55 pages of the playbook I wish someone had handed me a decade ago when I was starting off as a manager (and failing at most things).

If you enjoyed this article, consider subscribing to get:

✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide