Let Them Go — Mentoring Engineers, Part 10
Mentoring Engineers · Part 10
A senior engineer tells their lead, a little awkwardly, that the platform team has asked them to help redesign the deployment pipeline. It would mean leaving the product team. The lead's first reaction, which they don't say out loud, is a list: the Q3 roadmap depends on this engineer, two juniors rely on their reviews, and the lead spent three years helping them get this good. What the lead says is, "Let's talk about timing." The conversation about timing goes on for four months. The engineer stops bringing it up. Eight months later they leave the company for the same kind of role somewhere else, and the lead loses the engineer and the two juniors' reviewer anyway.
Every mentoring relationship that works reaches this point. The mentee gets good enough that what they need next isn't something you can give them on your team. How you handle it decides whether you keep them in your network, and often in your company, or lose them completely.
The working claim: the end of a mentoring relationship is a phase you can plan for, not a loss to delay. The research on mentoring has described it as a phase for decades. Engineering teams mostly treat it as a surprise.
Before you start
List your current and past mentees. For each, note roughly where the relationship is: just starting, actively growing, or one where they now rarely need your input.
For anyone in the third group, write down the next opportunity that would stretch them. Note whether it exists on your team.
Check your company's internal transfer policy. Many teams don't know what it allows until someone asks.
Step 1: Recognise the shift with observable signals (10 min)
Kathy Kram's 1983 study of mentoring relationships described four phases: initiation, cultivation, separation and redefinition. Separation is the point where the junior person needs more independence and the relationship's structure changes. Redefinition is where it becomes something closer to a peer relationship, or ends. Her finding was that separation is normal and often uncomfortable for both people, and the discomfort is not a sign that something has gone wrong.
In engineering, separation has clear signals. Track them in your 1:1 notes:
Signal | What you'll notice |
They bring decisions, not questions | "I'm going with X, here's why" instead of "what should I do?" |
They disagree with you, and are sometimes right | Their alternative turns out better, and you can name the cases |
Others go to them before you | Juniors and other teams ask them first |
Your 1:1s get shorter | Fewer topics need you, and the remaining ones are about career, not work |
They mention wanting something your team doesn't offer | A domain, a scale, a kind of problem |
Test you can run: over your last five 1:1s with a long-standing mentee, how many items needed your input to resolve? If it's close to zero, you're in separation, whether or not either of you has said so.
Step 2: Change the shape of the relationship, explicitly (10 min)
When the signals show up, say so out loud, and propose a different arrangement. Something like: "You don't need me for day-to-day decisions any more. I'd like to move our weekly 1:1 to every two weeks and spend it on where you're going next, not what you're working on."
The new shape is less advice and more sponsorship (Part 5): putting their name forward, opening doors, and connecting them with people who can teach them what you can't. You go from teacher to sounding board and advocate.
Not saying it causes a slow mismatch. The mentee is ready for a peer relationship, and the mentor keeps running a teaching relationship. The mentee experiences that as being held back, even when the mentor means well.
Step 3: Support the move out of your team (15 min)
This is the hard fork, and the opening scenario shows the cost of getting it wrong. When a strong engineer's next growth step is on another team, a lead has two options:
Option | Short term | Long term |
Delay ("let's talk about timing") | You keep their output for a few months | They often leave the company, and you lose their output, their network and the goodwill |
Support ("let's plan the handover") | You lose their output on your team | They stay in the company, stay in your network, and other strong engineers see that growth is possible here |
The delay feels safer because its costs come later and are harder to see. A practical way to support the move without leaving your team exposed:
Agree a date with them and the receiving team, usually four to eight weeks out, not open-ended.
Write down what only they know. Systems they're the main expert in, decisions only they remember. That list tells you how concentrated your team's knowledge was. That's a risk the move reveals; it doesn't create it.
Hand over to people, not to a document. Pair them with whoever takes on each area, and have them review that person's first few changes.
Stay connected. Agree they'll be a reviewer or adviser on one system for a quarter if the receiving team agrees.
Test you can run: if your strongest engineer moved teams next month, what would be on their "only I know this" list? If you can't answer, write it with them now, whether or not they're leaving. It's your bus-factor audit.
Step 4: When they leave the company (10 min)
Sometimes the next step isn't available anywhere in your organisation: a different domain, a bigger scale, a startup, or simply more money. When they tell you, the relationship will be judged on your first reaction.
Don't make them feel guilty, and don't make a counter-offer you can't sustain. Ask what they're going to learn there, and whether there's anything you can do to help: an introduction, a reference, an honest view on the offer. Offer to stay in touch, and mean it.
Then do the knowledge handover from Step 3, compressed into their notice period. Write down what the departure revealed about your team (concentrated knowledge, a lack of next steps for senior people) and act on it, because the next strong engineer will hit the same ceiling.
Step 5: Redefine, or let it end (5 min)
After separation, Kram's research describes redefinition: the relationship becomes something closer to peers, or fades. Both are fine. A light-touch rhythm works for those who want to keep in touch, such as a short call every six months to trade notes on what each of you is working on. Former mentees become peers, references, sources of new hires, and sometimes mentors to people you couldn't reach yourself.
Don't force it. Calling yourself someone's mentor years after they stopped needing one, or expecting regular check-ins they didn't ask for, turns a good relationship into an obligation.
Step 6: Use the capacity it frees (5 min)
You can only mentor a few people deeply at once. When a mentee graduates, that capacity goes back into the team. Decide on purpose who gets it next. The people who most need a mentor are often the least likely to ask for one: new joiners, career changers, and people who don't see anyone like themselves in senior roles (Part 9).
Worked example: two departures, handled differently (composite scenario)
Context. One engineering manager, two senior engineers, eighteen months apart, both ready to move on.
The first departure. It went like the opening: the manager delayed an internal move for months, citing roadmap risk. The engineer left the company. Their exit conversation was polite and brief. Two systems had no other expert, and one of them caused a weekend incident a month later while the team worked out how it behaved.
What the manager changed. They started reviewing the separation signals in 1:1 notes every quarter, and kept an "only I know this" list for each senior engineer, updated every quarter whether or not anyone was leaving.
The second departure. A senior engineer asked about joining the data platform team. The manager agreed a six-week date with the receiving team the same week. The "only I know this" list already existed, and three of its five items had been shared during the previous quarter. The engineer reviewed their successor's changes for a month after moving.
What happened. No incidents during the handover. The engineer stayed in the company and, a year later, referred a strong candidate back to the manager's team. Another senior engineer on the team later said that watching the move go smoothly was part of why they'd stayed: they could see that growth didn't require leaving.
Lesson. The second move cost the team a strong engineer, just as the first did. Only the second kept the engineer, the knowledge and the trust.
Trade-offs to make deliberately
Choice | You gain | You risk |
Raise the separation conversation early | The mentee plans their growth with you, not around you | Prompting a move sooner than you'd like |
Support internal moves quickly | Retention in the company, a reputation as a team people grow on | Short-term delivery gaps, which the "only I know" list reduces |
Counter-offer to keep them | Keeps their output for now | Often only delays the departure if the real reason is growth, not pay |
Keep in touch after they leave | Network, referrals, peer advice | Your time, so keep it light |
Common failure modes
"Let's talk about timing." Open-ended delay is often how internal moves turn into resignations.
Never naming separation. The mentee is ready for a peer relationship; the mentor keeps teaching.
Treating departures as personal. It ends the relationship at the point it could have turned into a long-term one.
No knowledge handover. The departure reveals concentrated knowledge, usually through an incident.
Letting the capacity drift. The next person who needs a mentor doesn't get one.
Final takeaway
A mentoring relationship succeeds when the mentee no longer needs it. Recognise separation from the signals in your 1:1s, change the relationship's shape out loud, and when their growth is on another team or another company, support the move with a date and a real handover. Your next action: for your longest-standing mentee, count how many items in your last five 1:1s actually needed you. If it's close to zero, have the conversation from Step 2 this month.
This is the last part of the Mentoring Engineers path. To keep going, browse the other paths in the Learning Center.
Sources
Kram, K. E. (1983). Phases of the Mentor Relationship. Academy of Management Journal, 26(4), 608–625.
Ibarra, H., Carter, N. M. and Silva, C. (2010). Why Men Still Get More Promotions Than Women. Harvard Business Review, September 2010. (On the difference between mentoring and sponsorship.)
Continue the Mentoring Engineers path
Previous — Part 9: Mentor Across Difference
Start again — Part 1: The First 30 Days for a New Engineer
Part of the Mentoring Engineers learning path. Related: Run Effective One-on-Ones.
