Mentoring and Coaching Questions

Direct Answer

I've had both versions: a mentoring relationship that ended because the mentee outgrew what I had to offer, which is a good outcome, and one that ended because it wasn't working, which is harder. In both cases I named it directly and early rather than letting it fade out, since an unspoken ending leaves the mentee guessing whether they did something wrong.

Framework

The two endings need different conversations. Outgrowing is success, and the conversation should sound like it: naming specifically what they no longer need from me, and pointing to what comes next, a different mentor with expertise I don't have, more autonomy, a formal program, makes it feel like a milestone rather than a rejection. Not working needs concrete, specific evidence rather than a general impression, and it needs to separate the relationship not working from the person not being good enough; often it's a mismatch, the wrong mentor for this specific gap, not a verdict on the mentee.

Either way, I handle the conversation the same way: say it directly rather than letting the relationship quietly taper, since ambiguity is worse than a clear ending for both people. Come with something concrete, what changed for outgrowing, specific examples for not-working, not vague dissatisfaction. And offer what comes next rather than just closing the door: a different mentor, a different structure, or nothing at all if the mentee is genuinely ready to fly solo.

Worked Example

A mentoring relationship stopped working when the mentee's growth area shifted to something outside my depth, they needed architecture-level judgment I didn't have. Rather than continuing to coach at a level I couldn't actually add value to, I said so directly: named what they now needed that I couldn't give them, and introduced them to someone better suited to that specific gap. The conversation was short and low-drama because it was framed around their need, not around either of our performance.

Trade-offs and Pitfalls

• Letting a relationship fade without naming it leaves the mentee wondering if they did something wrong; silence reads as a verdict even when it isn't.
• Framing "not working" around the mentee's shortcomings when it's actually a mismatch damages their confidence for no reason.
• Ending a mentoring relationship isn't a performance action; it doesn't need documentation or HR involvement unless the underlying issue is an actual performance problem. Conflating the two turns an ordinary mentoring transition into a formal process it doesn't need to be.
• A senior answer separates "the relationship ended" from "the mentee failed"; a junior answer often can't articulate the difference.

Direct answer

Teaching a skill you don't have natural talent for means separating what you know intuitively from what's actually teachable. You diagnose the real gap first, build an explicit, decomposed framework for the skill (even though you perform it by feel), and validate progress by watching the person apply it independently, not by how confident the coaching sessions felt.

Approach to teaching outside your natural strength

Diagnose before prescribing. "Struggles with X" is rarely one problem. Watch or review their actual attempt and separate the layers: is it a knowledge gap (they don't know the structure), a delivery gap (they know the structure but execution is shaky), or a confidence gap (they know it and can do it, but freeze under real stakes). Each needs a different intervention.

Decompose your own tacit skill into explicit steps. If you're good at something without having consciously learned it as a framework, you have to reverse-engineer your own process before you can teach it. Skipping this step and just saying "do what feels right" doesn't transfer anything.

Practice at graduated, increasing stakes. Start with low-stakes reps where mistakes are cheap and recoverable, then move toward the real, higher-stakes version. Jumping straight to the real thing conflates skill-building with performance evaluation in the person's head, which raises anxiety and slows learning.

Give feedback on the mechanism, not just the outcome. "That worked" or "that didn't work" is much less useful than pointing at which specific move in their approach caused the result.

Worked example

Situation: someone you're mentoring is excellent at the core technical work but has a real gap in a skill that doesn't come naturally to you either, say, communicating findings clearly to people outside the immediate team. Their material was always technically sound, but reviews ran long and the point often got lost.

Task: help them close that gap over a defined stretch, without pretending you have natural talent for it yourself.

Action: you watched a recording of one of their sessions together and separated content problems (no clear headline, too much detail up front) from delivery problems (pace, not anticipating pushback). You gave them a simple structure to practice against: state the conclusion first, then the supporting evidence, then the recommendation. You ran a couple of low-stakes rehearsals where you played a skeptical stakeholder, then let them run the real session solo.

Result: over a few sessions, their reviews needed fewer clarifying follow-up questions from the room, and the structure started showing up unprompted in written material too, not just live presentations. The real signal wasn't how the coaching sessions felt: it was watching them handle a session you weren't part of and hearing secondhand that it landed cleanly.

Trade-offs and pitfalls

A common junior-mentor mistake is trying to transfer your own tacit competence directly ("just do what I do") instead of decomposing it. That fails specifically because the skill you're teaching is one you never consciously learned as steps.

Another mistake: avoiding coaching on gaps you don't personally excel at, on the theory you're not qualified. You don't need to be naturally gifted at a skill to teach its structure. You need to be willing to build the explicit framework, which sometimes non-naturals do better than naturals, because they had to learn it deliberately themselves.

The real trade-off is time. Teaching a skill outside your own strength takes longer to prepare for, because you can't rely on instinct in the room. That prep time is where the actual coaching value gets built.

Direct answer
My mentoring approach starts from diagnosing where someone actually is, not applying one fixed style, and it balances technical guidance with career development by treating them as two separate but connected tracks: technical guidance closes the gap between where they are and what the work in front of them needs right now, while career conversations look further out at where they're trying to go. The mix between the two shifts substantially depending on how experienced the person already is.

Structured elaboration

Diagnosing before applying a style

The first move with any new mentee is figuring out their actual starting point and goals, not assuming based on title or tenure. Two people at the same level can need very different things: one might need technical unblocking, another might already be technically strong but stuck on visibility or scope.

Balancing technical guidance and career development

• Technical guidance tends to dominate early in a relationship or when someone's working in genuinely new territory; it's concrete, has fast feedback loops, and builds the trust that makes career conversations land later.
• Career development becomes a larger share of the time as technical competence stabilizes; someone who's already reliable on the day-to-day work benefits more from conversations about scope, visibility, and where they're headed than from more line-by-line guidance.
• The two aren't fully separable in practice: a well-run technical conversation often surfaces the real career question underneath it (they're not struggling with the code, they're struggling with whether this kind of work is even what they want to be doing).

How the approach changes: newer teammate vs. experienced one

• A newer teammate typically needs a tighter structure: explicit expectations, closer review, and a higher ratio of technical to career conversation, because there usually isn't yet a track record to have a grounded career conversation about.
• A more experienced teammate usually needs the opposite ratio: less hands-on technical guidance (often none at all on execution, more on judgment calls and trade-offs), and more time spent on career and scope, sometimes including the expectation that they take on some mentoring of their own, since that's often the actual next step in their growth.

Worked example

Applying the philosophy

With a newer teammate, most of an early 1:1 might genuinely be spent walking through a specific technical decision they made, only pivoting to career topics once they'd built enough of a track record to have something concrete to talk about. With a more experienced teammate on the same team, the same 1:1 slot might be spent almost entirely on a scope or visibility question, with technical guidance limited to a quick sanity check on a hard trade-off they'd already mostly worked out themselves.

Signal of it working

The clearest sign the ratio was right in either case wasn't a specific number, it was whether the conversation actually used the full time productively: a newer teammate's 1:1 running long on technical questions because they had real ones was a good sign; the same happening with an experienced teammate, repeatedly, usually meant something else was being avoided, often a harder career conversation neither of us had opened yet.

Trade-offs & pitfalls

• Applying the same ratio to everyone regardless of experience. A fixed philosophy that doesn't flex by seniority isn't really a philosophy, it's a script, and it under-serves experienced mentees while potentially overwhelming newer ones.
• Letting technical conversations become a permanent default because they're easier. Technical questions have clear right answers and fast feedback; career conversations are ambiguous and can feel uncomfortable. A senior mentor notices when technical talk has become an avoidance pattern rather than what's actually needed.
• Treating career conversations as an occasional add-on rather than a real track. If career development only comes up during formal review cycles, it usually means the day-to-day mentoring relationship isn't actually addressing it.

Direct answer
Difficult feedback to a mentee works best delivered privately, tied to a specific, observed behavior and its concrete impact, not to the person's character, and followed up on to confirm the message landed and something changed. The delivery mechanics matter less than getting three things right: timing (soon after the behavior, not saved up), specificity (a real example, not a vague pattern), and follow-through (checking back in, not treating the conversation itself as the fix).

Structured elaboration

Before the conversation

• Get the facts straight: what exactly happened, what was the impact, and is this a one-off or a pattern. Vague feedback ("you need to be more careful") is unusable; a mentee can't act on a mood, only on a specific instance.
• Decide the stakes. Not all critical feedback carries the same weight:
  • A routine performance gap (missed a deadline, sloppy code style) can wait for the next scheduled 1:1.
  • An ethical or safety concern (something in the person's work poses real risk if it ships) changes the calculus: it needs to happen immediately, privately, and is often paired with a concrete containment step (pause the change, get a second reviewer), not just a conversation.
• Decide the medium: a private 1:1, not written feedback and not in front of the team, unless the finding also needs to be logged for safety or compliance reasons.

Delivering it

• Lead with the specific behavior and its impact, not a label: "this change would have introduced X" is usable; "this was careless" is not.
• Ask before you assert. The mentee may know something you don't (a constraint you weren't aware of); asking "walk me through the reasoning" often surfaces that before you've over-committed to a judgment.
• Separate the person from the work. The message is "this output has a problem," not "you are the problem."

When the power dynamic is reversed

Feedback isn't always flowing to someone junior. Giving critical feedback to a mentee who is more senior, more tenured, or simply more confident than you requires the same content but a different frame: lead with genuine respect for their experience, be more explicit that you're not questioning their general competence, and expect (and plan for) more pushback. Defensiveness here is a normal reaction to a status threat, not necessarily a sign the feedback was wrong; the skill is staying anchored to the specific evidence instead of either escalating or backing down.

After the conversation

• Confirm shared understanding before ending: ask them to restate what they heard.
• Agree on a concrete next step and a checkpoint to revisit it, not just "let's see how it goes."
• Follow up. Feedback that isn't revisited quietly signals it wasn't actually important.

Worked example

Situation

During a code review, I found a race condition in an interrupt service routine (an ISR, the block of code that runs automatically when a hardware event interrupts normal execution) a mentee had written: a shared buffer was being written from the ISR without disabling interrupts around the critical section (the stretch of code that touches shared data and must not be interrupted mid-update), so a preemption (the interrupt firing and pausing the main code at an unpredictable moment) at the wrong moment could corrupt data intermittently and unpredictably.

Why this wasn't routine feedback

This wasn't a style nitpick. Left unaddressed it was a latent, hard-to-reproduce bug that could surface in the field. That pushed it from "note it for next time" to "we talk today, and the change doesn't merge until it's fixed."

The conversation

I asked the mentee to walk me through what happens if the interrupt fires mid-write, rather than telling them the bug outright. They found the failure mode themselves partway through the explanation, so the fix landed as their own understanding rather than my correction. We then talked through the general pattern (anything touching state shared between an ISR and main-line code needs an explicit critical section) so it would generalize past this one bug.

Follow-through

I asked them to check two other places in the codebase where similar shared state existed, as a way to prove the concept had stuck rather than just fixing the one instance. Both had the same latent issue.

Result

The immediate bug was fixed before merge, and the mentee started flagging similar patterns unprompted in their own future changes, which was the real signal the feedback had generalized rather than just been complied with once.

Trade-offs & pitfalls

• The feedback sandwich dilutes the message. Padding critical feedback between two compliments is a common junior instinct; it often causes the actual point to get lost. Genuine positive feedback is worth giving, but on its own merits, not as camouflage for the critical part.
• Waiting to "collect examples" delays too long. A senior mentor gives feedback close to the event; batching several issues into one big conversation later makes it feel like an ambush and makes each point harder to act on.
• Not distinguishing skill gap from something more serious. A performance gap and an ethical or safety issue call for different urgency and different documentation; treating a safety issue as routine coaching is itself a failure mode worth naming.
• Confusing "they got defensive" with "I was wrong." Especially with a more senior or tenured mentee, defensiveness is a predictable reaction to a status threat. A junior mentor backs off; a senior one stays anchored to the specific evidence while still leaving room for the other person to be right about something they missed.

Direct answer

Without formal authority, influence has to come entirely from credibility and voluntary buy-in instead of any ability to assign work or shape a review. That changes the approach toward explicit opt-in, keeping every session clearly worth their time, and respecting that they can walk away at any point without consequence.

What actually changes

• No mandate over cadence or topics. You can't schedule a recurring 1:1 and assume it happens, each session has to earn its place on their calendar.
• No visibility into their formal goals. You're advising without the context a manager has, so advice has to stay conditional ("here's what I'd consider, given what I know") rather than directive.
• No enforcement of follow-through. They can take or leave anything you suggest with no consequence, which is a feature, not a problem, but it means you can't measure success the way you would with a direct report.
• A boundary with their actual manager. Advice that touches their team's norms, priorities, or performance is their manager's territory. Staying in a peer-advisor lane means flagging that explicitly rather than quietly overriding it.
• No natural checkpoint. A direct-report relationship gets reviewed on a cycle; an informal one only continues as long as both sides keep choosing it, so it's worth periodically checking whether it's still useful rather than assuming it is.

Worked example

A colleague on a different team reached out about a specific hard decision they were facing. The first move was an explicit, opt-in question rather than assuming continued access: whether they wanted a recurring conversation or just help with this one thing. Advice stayed framed as "here's what I'd weigh" rather than a recommendation to just do X, and anything that touched their team's priorities or their manager's likely call was flagged as outside this lane, with a suggestion to raise it with their manager directly instead. A few sessions in, a light check-in confirmed it was still useful before continuing.

Trade-offs and pitfalls

A common mistake is treating an informal mentee like a direct report: being directive, assuming continued access, and not checking whether it's still wanted. The more durable version treats it as an ongoing, consent-based relationship, and requires being comfortable that some advice will simply be ignored with no way to enforce it, which is normal here, not a sign of failure. The other real pitfall is overstepping into another manager's territory, giving performance-adjacent feedback that should go through the person's actual chain instead.