Mentoring and Coaching Questions

Direct answer
A stretch assignment only works as a growth tool if it's picked deliberately (real stakes, but survivable if it goes wrong), supported actively rather than handed off and hoped for, and evaluated by whether the person can now do something they genuinely couldn't before, not just whether the project shipped.

Picking the assignment

• Look for the specific gap between where someone is and where they want to go, and pick something that exercises exactly that gap: not a bigger version of what they already do well, but the thing they haven't had to do yet (leading ambiguity, owning a stakeholder relationship, making a judgment call without a clear right answer).
• Sanity-check the blast radius: a good stretch assignment has real consequences if it goes wrong, but not consequences the team or the person can't absorb. If failure would be catastrophic, it's not a stretch assignment, it's a bet you shouldn't be making on someone's first attempt.

Supporting through it

• Set explicit checkpoints rather than open-ended availability; someone stretching is often reluctant to ask for help exactly when they need it most, because asking feels like it undercuts the point of the assignment.
• Watch actively for the failure mode where the person becomes overwhelmed or delivery risk climbs mid-assignment. The fix isn't to quietly take it back (that undoes the growth and teaches them stretch assignments are a trap), it's to scope down the ask while keeping ownership intact: shrink the surface area, extend the timeline, or bring in narrow support on the hardest sub-piece, while the person still owns the outcome.

Knowing it worked

• The real signal isn't whether the deliverable shipped; plenty of stretch assignments succeed despite the person, propped up by others. The signal is whether they can now do a similar thing again with meaningfully less support than before.
• Ask them directly what they'd do differently next time; someone who's actually grown from it usually has a specific, concrete answer, not a vague "it was good experience."

Variants worth having ready

• Succession-driven: when someone owning a critical piece of the system is leaving, a stretch assignment can double as a deliberate handoff, usually spread across two or three people rather than one, so the knowledge doesn't just move from one single point of failure to another.
• Developing a mentor, not just a mentee: a technically strong senior who's never mentored can be given a stretch assignment that's explicitly about teaching, not delivery, such as owning a junior's ramp-up plan with the growth of the junior, not the speed of the project, as the success measure.

Worked example
A strong individual contributor wanted to grow into leading larger, more ambiguous work but had only ever executed against fully-scoped tasks. Rather than a bigger version of the same kind of work, the assignment was to own a smaller, genuinely under-scoped project end to end: figure out the actual requirements from a vague ask, make the technical calls, and report progress upward directly instead of through a lead. Support looked like a standing short weekly check-in (not daily oversight) and an explicit agreement that they'd flag it early if they felt stuck, rather than waiting until a deadline made the risk visible.

Partway through, the scope turned out to be bigger than either of us expected, and the person started showing the classic overwhelmed signs: shrinking updates, slipping the weekly check-in. Rather than pulling the project back, the assignment was rescoped down to the highest-value piece, with the harder edge case handed to someone else, while they kept ownership of the core decision and the delivery. They finished a smaller version of the original ask, and more importantly, on the next ambiguous piece of work a few months later, they scoped it themselves without needing the same weekly check-in structure. That second instance, done with much less support, was the actual evidence the stretch assignment had worked, not the fact that the first project shipped.

Trade-offs and pitfalls

• Picking a stretch assignment that's really just "more of the same, but bigger" doesn't build a new skill; it just tests stamina.
• Quietly rescuing someone the moment they look overwhelmed (taking the assignment back rather than rescoping it) protects the deliverable but teaches the person that stretching is unsafe, which discourages them from taking the next one.
• Measuring success by whether the deliverable shipped, rather than by what the person can now do independently, rewards you propping the project up rather than the person actually growing.

Direct answer

Developing independent judgment, not just correct outputs, requires repeated exposure to the same class of decision with you gradually receding from it, and requires the person to narrate their reasoning, not just report their choice. You know it's internalized, not just imitated, when their reasoning transfers to a situation you never coached them on directly, ideally one you weren't even present for.

How judgment gets built and verified

Coach the decision class, not the individual decision. A one-off answer to "should we do X" teaches them what to do this time. Judgment comes from recognizing the same underlying trade-off recurring in different clothes, which means you have to name the pattern explicitly rather than just resolving each instance.

Recede deliberately in stages. Start by explaining your own reasoning out loud when a decision comes up. Then ask them to predict what you'd decide, and why, before you weigh in. Then let them make the call and explain their reasoning to you after the fact. Then stop reviewing it at all. Each stage removes a layer of your safety net.

Make them narrate the criteria, not just the outcome. If someone can only say "I did X because I figured that's what you'd want," they've pattern-matched to you specifically, not internalized the underlying principle. You're listening for whether their stated reasoning would still hold up in a case where the "obvious" answer is actually wrong.

Verify with a novel or unobserved case. The strongest signal is watching them apply the same reasoning to a situation they haven't seen before, particularly one where you weren't in the loop and only heard about the decision afterward.

Worked example

Someone you're mentoring kept bringing you a specific recurring trade-off as if it were a one-off question each time: whether to fix a flaky, intermittently-failing test or ship a feature that was ready and waiting on it. Each time, you could have just answered the immediate question. Instead you treated it as a judgment gap and built a repeatable heuristic with them: is the flake masking a real intermittent bug or is it environment noise, what's the actual blast radius of shipping with it unresolved, and is there a way to quarantine the test that unblocks delivery without hiding the underlying risk.

Weeks later, a similar trade-off came up and they handled it without asking you first, only mentioning the decision afterward along with their reasoning. Their stated criteria matched the heuristic you'd built together, but in their own words, applied to a case with a different shape than the original one. That, not their confidence in the moment, was the signal it had actually internalized rather than just been remembered.

Trade-offs and pitfalls

Asking someone "do you understand?" tells you almost nothing; people say yes regardless of whether it's true. The only real test is watching the reasoning survive a situation you didn't script.

A subtle failure mode: rewarding a decision because it matches what you personally would have done, rather than evaluating whether the reasoning behind it was sound. If the original case was genuinely a coin toss, insisting they land on your exact answer trains obedience, not judgment.

The deeper trade-off is time and tolerance for being wrong. Actually receding means letting them face real stakes without a safety net, which means tolerating some decisions that turn out wrong in hindsight. That's not a bug in the process; it's the cost of judgment actually being tested rather than simulated.

A mentor who never truly recedes, who keeps reviewing every instance of the decision "just to be safe," never actually finds out whether the judgment transferred, because it's never been tested without the net.

Direct answer

Treat it as an active transfer project with an owner and a deadline, not passive documentation. Inventory what this person uniquely holds, rank it by risk rather than by how interesting it is to write up, transfer the highest-risk pieces through hands-on shadowing rather than just writing, and verify the transfer actually worked by having the successor perform the task for real while there's still time to catch gaps.

Transfer approach

Inventory and rank by risk, not by volume. List what this person actually holds that nobody else can currently do, then rank by what breaks or stalls if it disappears, not by what's easiest or most interesting to document. A fixed departure date means you can't transfer everything equally; risk ranking tells you where to spend the limited time.

Match the transfer method to the kind of knowledge. Procedural and tacit knowledge, how to actually make a judgment call under pressure, how to run something that doesn't go by the book, transfers best through shadowing and pairing, not documents. Declarative knowledge, why a past decision was made, historical context, transfers fine through writing, since there's no live judgment being exercised.

Verify the transfer actually happened, don't assume it. Have the successor perform the highest-risk task for real, a supervised dry run or an actual live instance, while the departing person is still around to catch what's missing. "They read the doc" is not verification.

Build in redundancy, not just a single successor. Naming one person as the new holder of the knowledge just recreates the same single point of failure with a different name on it.

Sequence by time pressure. The runway is fixed and shrinking, so the highest-risk items go first, even if lower-risk items would be quicker or more satisfying to knock out.

Worked example

Someone with deep knowledge of a specific system announces they're leaving in a few months. You inventory what they uniquely hold and rank it by risk: the thing that would cause the most damage if nobody understood it isn't the thing that's easiest to write a doc about, it's a judgment-heavy process that only they've ever run. You assign a primary and a backup successor rather than just one person. For that highest-risk item, instead of relying on a runbook, you have the successor run it for real under supervision before the departure date. During that supervised run, a real gap surfaces, a step the departing person did automatically and never thought to write down, and it gets caught and fixed while there's still time, instead of surfacing for the first time after they're gone.

Trade-offs and pitfalls

A knowledge-dump documentation sprint feels productive but is rarely sufficient on its own. What the departing person chooses to write down reflects what they consciously think matters, filtered through their own blind spots; the things that are automatic to them are exactly the things they won't think to write down.

Waiting until the final weeks to start is a common and costly mistake. Tacit knowledge transfer through shadowing takes real elapsed time to work, so it needs to front-load into the runway, not compress into the last stretch.

Verifying through a real supervised run costs more time, and carries some real risk, compared to just trusting a document. That cost is worth it, because it's the only way to catch a gap before it becomes expensive, rather than after.

Naming a single successor and calling the transfer complete just recreates the original risk with a new name attached. The goal isn't a new single point of failure; it's genuine redundancy.

Direct answer
Three boundaries matter most: confidentiality (what's said in a mentoring conversation doesn't automatically become input to a performance review), favoritism (visible time and opportunity should be fair and roughly trackable, not just felt fair), and the evaluator conflict (mentoring someone you also formally evaluate creates a structural incentive problem, since they cannot be fully candid with someone who scores them). The practical fix is not avoiding all overlap, since it is often unavoidable, it is naming the boundary explicitly up front and having a plan for when it blurs.

Structured elaboration

Worked example
Situation: I was mentoring someone I would later be asked to give calibration input on for a promotion cycle.
Task: keep the mentoring relationship honest without compromising the integrity of the eventual evaluation.
Action: I told them directly, early, that promotion calibration might eventually involve my input, so mentoring conversations and evaluation conversations were separate. When something they shared in a mentoring context, a specific technical mistake, later became relevant to an honest performance discussion, I went back to them first rather than using it silently, and asked how they wanted it handled.
Result: the relationship stayed trustworthy because the boundary was named rather than assumed, even though the overlap between mentor and evaluator could not be fully removed.

Trade-offs & pitfalls
Pretending you can be a purely neutral mentor when you structurally have some evaluator influence is dishonest and erodes trust once it surfaces. Over-formalizing boundaries, a written contract for every casual pairing, feels bureaucratic when the stakes don't call for it, so match the formality to the actual overlap: an evaluator relationship needs an explicit conversation, a casual peer pairing usually doesn't. The senior distinction is naming the boundary before it's tested, not scrambling to explain it after a mentee feels burned.

Direct answer
A mentoring relationship going badly is rarely one big failure; it's usually a slow accumulation of choices, like taking on too much of the work yourself to protect the outcome, that quietly undercut the mentee's growth. The honest answer names a specific relationship, is candid about what you did (not just what the mentee did), and shows what changed in how you mentor afterward.

What "went badly" usually looks like

• Common patterns: being too directive and doing the hard parts yourself to protect delivery; giving feedback too infrequently or too late to be actionable; misjudging the mentee's actual gap (treating a confidence problem as a skill problem, or the reverse); or disengaging when the relationship got effortful.
• A strong answer picks one specific pattern and owns your part in it, rather than a vague "they weren't a good fit."

What separates a senior answer from a junior one

• Junior answers blame the mentee ("they just weren't receptive") or stay abstract ("communication could have been better"). Senior answers identify a decision you made and trace its actual effect: what you did, what it produced, and why it made sense to you at the time even though it was wrong.
• Senior answers also show what changed structurally afterward, not just an apology or a resolution to "communicate better." Concrete changes: an explicit mentoring agreement up front, checkpoints instead of open-ended availability, deliberately handing over ownership even when it's slower.

How to close it out

• End on what you'd do differently now, stated specifically enough that it's clear you'd actually behave differently in the next relationship, not just that you feel bad about the last one.

Worked example
During a stretch project with a hard deadline, I mentored a junior engineer by taking over the riskiest parts myself rather than coaching them through it, to keep the timeline safe. That worked in the short term, but it meant they never built confidence handling ambiguity or incidents on their own, and toward the end of the project they told me directly that they felt sidelined rather than developed. That was the moment it became clear the relationship hadn't done what I'd intended, even though the project itself shipped fine.

What I changed afterward: instead of stepping in when something got risky, I started requiring myself to narrate my reasoning out loud and have the mentee drive, only taking over if there was a genuine, immediate risk. I also set an explicit checkpoint (a short regular sync, not just "come find me") so growth stalls would surface early instead of only becoming visible at the end of a project. The relationship after that wasn't measured by how smoothly the project went; it was measured by whether the mentee could handle the next similar situation without me in the room, which is a slower thing to build but the actual point of mentoring.

Trade-offs and pitfalls

• The tempting failure mode is optimizing for the deliverable (visible and rewarded) at the expense of the mentee's growth (slower and less visible), especially under deadline pressure.
• Being self-critical is necessary but insufficient; an answer that's all remorse with no concrete process change reads as unreflective in a different way.
• Watch for over-correcting into never stepping in, which just replaces one failure mode (too directive) with another (abandoning someone to a mistake they can't yet recover from alone).