Skip to content
Institute of Technical Leadership
All blog posts

Leading People

Your Best Engineer Is About to Resign and You Haven't Noticed

Principal Architect · 26 May 2026 · 5 min read

She resigned on a Tuesday afternoon, in a fifteen minute slot she'd booked as "quick chat". I was genuinely blindsided. That was the whole problem, and it took me another year to work out why.

People don't go quiet before they leave. They go quiet, and then they leave

We're all trained to look for the wrong signals. We watch for someone getting snappy, missing stand-ups, taking odd days off, suddenly wearing a shirt. By the time you see any of that, the decision was made weeks ago and they're managing the exit, not the job.

The real signal is subtraction, and it's almost invisible because nothing bad happens. Your strongest engineer stops arguing in design reviews. Their pull request comments get shorter and more agreeable. They stop sending you the Sunday night message about the thing they noticed in the logs. They say "sure, whatever you think" in a meeting where six months ago they'd have taken the pen off you and redrawn the diagram.

Every one of those changes makes your week easier. That's the trap. The moment a difficult, brilliant person becomes easy to manage, something has usually broken, and it broke a while back.

Good people don't get quiet because they stopped caring. They get quiet because caring stopped paying. They raised the same architectural concern three times, watched it get parked three times, and did the arithmetic.

The gap between what they cost and what they're worth

Here's a shape I've seen repeatedly. An 11-person data team inside a pharmaceutical manufacturer. One engineer, maybe eight years in, is the only person who properly understands the batch release pipeline: how it fails, why the retries are the way they are, which of the two upstream teams to call at 2am.

She asks for a step up to a lead role. It goes into a cycle. The cycle moves twice a year. Her manager tells her, honestly, that it's "being looked at". She waits two cycles. Nothing lands.

She leaves in March. Her replacement starts in July, because you lost six weeks agreeing the hire with finance and another eight to notice periods. The new person is good and takes five months to be useful on the batch release pipeline, because nobody wrote any of it down, because she was always there to ask.

So the actual cost is roughly nine months of a critical capability, two incidents that ran longer than they should have, and two more engineers who watched all of this happen and drew a conclusion about how you get rewarded here. The cost of keeping her was a title, a conversation with HR, and maybe a few thousand a year.

Nobody was villainous in that story. Everyone followed the process. That's what makes it the common one.

What the conversation actually needs to be

The exit interview is where all this comes out, which is the single most wasteful piece of theatre in our industry. The information arrives on the day it becomes useless, and it arrives for the benefit of a manager who no longer has the person.

Have the exit interview eighteen months early instead. Not as a survey. As a direct question, asked in a one to one, with the diary blocked so neither of you is checking the time.

Try: "If you were going to leave in the next year, what would be the reason?"

It's a blunt question and it works precisely because it's blunt. It gives permission. Most people won't say "I'm looking", because they're not, yet. What they'll say is the thing that's been irritating them for four months and has never been safe to put in words. The on-call rota that never got fixed. The fact that the greenfield work keeps going to the newer hire. The promotion that was mentioned in a hallway in October and never again.

Then there's the part that matters more than the question. You have to come back to it. If they tell you something on the 12th and you say nothing by the end of the month, you've taught them that talking to you is a waste of breath, and you've made it worse than if you'd never asked.

Coming back doesn't mean fixing it. Half the time you can't. "I asked, and the answer is no, and here's why, and here's the one part of it I can actually change" is a respected answer. Silence is not.

Counter-offers are an admission, not a strategy

When someone resigns and you suddenly find the money, the title, or the interesting project that was impossible last quarter, you've confirmed their worst suspicion in public. It was always available. It just needed a threat.

Most people who accept a counter-offer leave anyway within the year, and the ones who stay have learned exactly how this place responds to pressure. So has everyone else on the team, because they always find out.

The counter-offer isn't the failure. It's the receipt for a failure that happened months earlier, when someone told you what they needed and you filed it under things to look at when the quarter calms down.

Monday morning

Pick the two people on your team you'd struggle most to replace. Not the two you like most. The two whose departure would cost you six months.

Then write to your own manager, this week, in writing, and say who they are, what each of them has asked you for, and what it would take to keep them. Put a number on it if there is one. Ask for a yes or a no by a date.

You may well get a no. That's fine, a no is information and you can take it back to the person honestly. What you can't do is sit on it, decide it's unwinnable, and then be surprised on a Tuesday afternoon.

Principal Architect

Founder of the Institute of Technical Leadership, writing from two decades of technical delivery.

This is the kind of thing we teach properly in Foundations of Technical Leadership.

Foundations of Technical Leadership is 25 self-paced lessons, with templates you can use the same week.