Mentoring and Coaching Questions

Direct answer

Mentoring is voluntary, growth-oriented influence without formal accountability. Managing includes formal accountability, resourcing decisions, and real consequences. The line moves the moment a mentee becomes a direct report, because feedback that used to be optional advice now carries formal weight, and the relationship gains structural power (comp, promotion, performance record) it didn't have before.

Where the line actually is

What changes when a mentee becomes a direct report

Private growth conversations now double as input to a formal review, whether that's said out loud or not. Advice that was previously optional is now, in practice, expected to be acted on for role reasons. The relationship carries real structural power (comp, promotion, PIP, short for performance improvement plan: the formal HR process for addressing underperformance) that it didn't have as informal mentoring. The hardest part is that "helping you grow" and "evaluating you" now happen with the same person, often in the same conversation, and separating those framings requires being deliberately transparent about which one is active at a given moment, rather than assuming the mentee can tell.

Worked example

A mentee who'd been mentored informally for a while later became a direct report after a reorg. The explicit adjustment made on day one: naming that some future 1:1 time would now include performance topics, not only growth topics, and being upfront about which kind of conversation was happening in the moment, rather than letting the mentee guess which hat was on.

Trade-offs and pitfalls

A common mistake is continuing to run the relationship exactly as before once it becomes formal, without naming the shift, which reads as inconsistent or even manipulative once the mentee realizes "informal advice" now affects their review. A stronger approach names the shift explicitly rather than letting the mentee discover it the hard way. Another pitfall is using "I'm just mentoring you" framing to soften what is actually a directive, formal expectation, which blurs accountability for both sides.

Direct answer

I track a mix of leading indicators I can observe soon and lagging outcome indicators that take months, and I treat any single outcome metric with real suspicion, because most of the obvious ones have confounders that have nothing to do with the mentoring itself. If it isn't working, the signal usually shows up in behavior long before it ever shows up in an outcome number.

Leading indicators (fast, but softer)

• The mentee proactively brings a problem before being asked, rather than only responding when prompted.
• They apply a technique from an earlier conversation without being reminded.
• They can articulate their own reasoning, not just repeat a conclusion.
• They start contributing to others, a strong late signal that something has actually been internalized rather than just followed along with.

Lagging indicators, and why they alone are not enough

Promotion, retention, and performance rating movement all matter, but none of them are clean measures of mentoring on their own. Promotion timing is affected by team budget, level-bar changes, and reviewer variance, not just capability growth. Retention is affected by pay, personal circumstances, and the direct manager relationship, often far more than by a mentoring relationship. Treating either as a dashboard number risks giving mentoring false credit when someone would have succeeded anyway, or false blame when the real cause was entirely outside the relationship. That's the reason to pair outcome numbers with direct, harder-to-fake behavioral signals rather than reporting them alone.

Telling it isn't working, and what to do

Signs it's not working: no observable change in independence over a reasonable window, the mentee still routes every decision through you, flat or disengaged body language in 1:1s, or the mentee saying directly that it isn't useful. Once suspected: ask directly rather than only inferring from behavior, check for a format mismatch (wrong cadence, wrong topics, or the mentee not feeling safe raising what's actually going on), adjust before assuming failure, and if the mismatch is genuinely personal rather than fixable, consider a different pairing without treating that as anyone's fault.

Worked example

After several weeks, a mentee was still checking in before making small, reversible decisions that should have been theirs to make. Rather than assuming a skill gap, a direct conversation surfaced that the actual blocker was fear of being wrong, not lack of ability. The adjustment was explicit permission to make a defined class of reversible decisions without approval, plus a standing offer to review the reasoning after the fact rather than before. Over the following sessions, they started making more of those calls on their own and explaining the reasoning unprompted.

Trade-offs and pitfalls

A junior answer to this question is usually a list of KPIs and stops there. A stronger answer explains why the obvious outcome metrics can lie, and pairs them with behavioral signals that are harder to fake. A common pitfall is over-attributing outcome metrics to the mentoring relationship (selection bias: motivated people who get assigned strong mentors were often already on a good trajectory). Another is waiting too long to check in because outcome metrics take a quarter or more to move, by which point a struggling relationship may have already quietly failed.

Direct answer

Don't position it as mentorship if the person resists that label. Frame the growth area as an opportunity tied to something they already care about, like impact or a problem worth solving, not as a personal deficiency to be corrected. Coach through modeling, shared ownership, and feedback on a specific concrete artifact, rather than direct instruction on their personality or style.

Coaching approach for a resistant, high-competence peer

Respect their self-image and drop the label if it's a trigger. People who resist being seen as needing a mentor often resist the framing more than the actual content. "Let's work on this together" as peers lands very differently than "I'm going to help you grow."

Attach the growth area to a real, concrete stake. Abstract feedback like "work on your communication" is easy to dismiss. A live initiative they're already invested in, where the gap visibly costs them something, like a proposal that keeps losing to weaker ideas because it doesn't land outside their own team, gives the coaching somewhere real to attach.

Coach indirectly: pairing, shadowing, and structured feedback on an artifact. Feedback on a specific document or pitch ("this framing lost the room in the first thirty seconds") is easier to accept than feedback on them as a person. Pairing them briefly with someone strong at the specific skill can model the behavior without you having to lecture it.

Give them ownership throughout. You scaffold (give graduated support that you withdraw as they gain competence); they drive. If it reads as your intervention rather than their initiative, you'll trigger the same resistance you were trying to avoid.

Fade support deliberately and watch for unprompted transfer. The real signal of progress is the specific pattern showing up again on a different initiative, without you being involved that time.

Worked example

A technically excellent peer keeps losing ground on ideas that are objectively strong, because their proposals don't land with people outside their immediate team. Naming this directly as a coaching need would likely trigger defensiveness, given how they see themselves. Instead, you invite them to co-own a cross-team initiative tied to a real problem they care about, briefly pair them with someone experienced at framing pitches for a broader audience, and give feedback specifically on the pitch document rather than on them. On the next initiative, without any involvement from you, they open with the same framing pattern you'd coached into the earlier pitch.

Trade-offs and pitfalls

Naming the growth area too directly with someone who resists the mentee label tends to trigger defensiveness and can shut down the relationship rather than open it.

Over-scaffolding, like writing the pitch for them yourself, solves the immediate case but doesn't build the underlying skill, and it reads as taking over rather than coaching.

This kind of indirect, peer-based coaching is slower and less controllable than direct instruction would be. You're deliberately trading speed for buy-in, and it's worth naming that trade-off rather than pretending it's free.

A real failure mode is mistaking short-term compliance, they did fine on the one pitch you were heavily involved in, for actual skill transfer, without ever testing whether the pattern shows up when you're not there.

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 good 30-60-90 plan moves someone from learning the environment, to contributing under supervision, to owning outcomes independently, with the phase boundaries defined by demonstrated behavior (what they can do unsupervised) rather than by the calendar alone. Track it with a small number of concrete, visible outputs per phase so "on track" is something you can point to, not just a feeling.

The three phases, by what changes

• Days 1-30 (learn and observe): environment setup, codebase or domain orientation, shadowing, and one small real contribution rather than a toy task, so the first change is real but low-risk.
• Days 31-60 (contribute under guidance): own a medium-sized piece of work end to end with a mentor available for review and unblocking, not doing it alongside them line by line.
• Days 61-90 (own outcomes): lead something (a project, an on-call rotation, a smaller onboarding task for the next hire) with the mentor as a backstop, not a co-pilot.

How you know they're on track

• Define the signal per phase in advance, not retroactively: for phase 1, did they reproduce the environment and ship one small real change without major help; for phase 2, is their review feedback shrinking in volume and severity over successive changes; for phase 3, can they make a reasonable decision alone and only escalate the genuinely hard calls.
• Check in on cadence (weekly early on, less frequent later) rather than waiting for day 30, 60, or 90 to find out something drifted three weeks ago.

Adjusting the plan for real constraints

• Limited training resources: when there's no dedicated ramp-up bandwidth (no spare mentor hours, no formal training material), lean harder on asynchronous artifacts: written runbooks, recorded walkthroughs, a curated list of the most representative recent changes, and a lighter-touch weekly sync instead of daily pairing. The phases stay the same; what changes is how much is self-serve versus live.
• Cross-skill ramp: if someone hired primarily for one skill set is expected to also ship in an adjacent one by day 90 (for example, a backend-focused hire expected to ship frontend work), that adjacent skill needs its own explicit milestone inside the plan, not an assumption it'll happen by osmosis. Concretely: days 1-30 stays focused on their strong area to build early confidence and trust; days 31-60 introduces the adjacent skill on a small, well-scoped, low-risk piece with close review; days 61-90 has them own something end to end in the new area, even if smaller in scope than their core-skill ownership.

Worked example
For a new hire joining an established codebase with a small team and no dedicated onboarding budget (the limited-resources case), the 30-60-90 looked like: days 1-30, self-serve environment setup using a written runbook plus a single half-day pairing session, culminating in one small, real bug fix; days 31-60, ownership of one medium feature with async review as the main touchpoint, and a short weekly 15-minute sync instead of daily check-ins; days 61-90, the new hire wrote the onboarding runbook update for the next person, which served double duty as both a real deliverable and a check on whether they actually understood the system well enough to explain it. Being on track was tracked by a short checklist per phase (environment reproducible, first fix merged with normal review effort, feature shipped with review comments trending down) rather than a single blanket "how's it going" check-in.

Trade-offs and pitfalls

• Treating the day boundaries as fixed calendar dates rather than behavioral milestones creates false confidence; someone can hit day 60 without actually being ready for phase-3 ownership, and pushing them into it anyway sets them up to fail.
• Under-supporting the adjacent-skill ramp (assuming a backend engineer will "pick up" frontend without an explicit milestone) is a common way cross-skill onboarding quietly fails; it needs the same structure as the primary skill, just smaller in scope.
• Compressing the plan under limited training resources by cutting phase 1 short (rushing into real ownership before the environment and codebase are understood) trades a faster-looking ramp for more review overhead and rework later.