Mentoring and Coaching Questions

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.

Direct answer
The strongest mentoring story names a concrete starting point (not "they were new," but what specifically they didn't yet know or couldn't yet do), describes what you actually did differently because of that starting point, and points to a real change in what the person could do independently afterward as the evidence of growth, not just that time passed or that they were nice about it.

Structured elaboration

What "starting from" should actually specify

Vague ("they were junior") is weak. Specific ("they could write correct code but always needed help scoping the actual problem before writing it") is strong, because it sets up a real before and after.

What "what you did" should show

The interesting part isn't a list of activities (pairing, reviews, 1:1s); it's the judgment behind them: why you chose that particular intervention for that particular gap, and what you adjusted when the first approach didn't fully work.

What "how you know they grew" should show

This is the part candidates under-answer. Two things separate a senior answer here:

• Independence as the real signal, not sentiment. The strongest evidence isn't "they thanked me," it's a concrete example of them handling something on their own that they previously couldn't, ideally something you didn't have to prompt.
• Reframing your own impact as leverage, not personal output. A senior candidate can articulate that developing someone else who can now independently do the work is a multiplier on team capacity, arguably more valuable than the same hours spent on your own individual output, because it compounds. That's a different, and stronger, claim than "I helped someone and it felt good."

The real tension: mentoring time vs. delivery

Mentoring genuinely competes with your own delivery time, especially early in a relationship when the payoff hasn't materialized yet. A senior answer is honest about this rather than pretending mentoring is free: it names a moment where mentoring time actually cost something (a deadline got tighter, you did more of the work yourself that cycle) and explains the judgment call for when it's right to deliberately scale mentoring back temporarily to protect a real deadline, versus when protecting the mentoring time is the higher-leverage call even under pressure.

Worked example

Situation

I mentored someone who was technically capable but consistently needed help before they'd start: given an ambiguous problem, they'd wait for someone to scope it into clear steps rather than attempting that themselves.

Action

Instead of continuing to scope tasks for them, I deliberately started handing over problems one level more ambiguous than they were comfortable with, then worked through their proposed scoping with them afterward rather than before, so the struggle happened on their side first. Early on this slowed things down, and I redid some of their scoping myself before it went further, which cost real time on a couple of deadlines.

Result

Over time the gap between their first attempt at scoping and a workable plan narrowed, until they were handling genuinely ambiguous problems without needing that step from me at all. The clearest evidence wasn't a compliment, it was a specific instance of them independently scoping and delivering something ambiguous while I was out, without anyone asking them to check with me first.

The trade-off moment

Partway through, we had a hard deadline where I made a deliberate call to scope their next task myself rather than continuing the hands-off approach, because the team couldn't absorb the risk of a slower first pass that cycle. I was explicit with them about why, so it didn't read as a loss of confidence in them, just a temporary trade-off.

Trade-offs & pitfalls

• Confusing activity with growth. Listing pairing sessions and 1:1s isn't evidence of anything; a senior answer points to a specific, observable change in independent capability.
• Never naming the cost. A story where mentoring never competed with anything else usually isn't a very real story. Naming a moment you scaled it back, and why, is more credible than claiming it was free.
• Missing the leverage framing entirely. Describing mentoring purely as "helping a nice person" misses the stronger claim: that growing someone else's independent capability is a real multiplier on what the team can deliver.

Direct answer
Adapting mentoring to someone different from yourself means adjusting the mechanism (how directive vs. how hands-off you are, how direct the feedback is, how much structure you provide) while keeping the underlying goal the same, and it requires actively noticing when your default style is a poor fit rather than assuming your own preferences are universal.

Structured elaboration

Adapting by competence and confidence: situational leadership

A useful framework here is thinking in terms of directing, coaching, supporting, and delegating, mapped to how much competence and confidence the person currently has for the specific task at hand (not their seniority in general, since someone senior can still be low-confidence on something genuinely new to them):

• Directing: low competence, needs clear instruction on what to do.
• Coaching: some competence but still needs explanation and encouragement, not just instruction.
• Supporting: solid competence, mainly needs encouragement and a sounding board, not instruction.
• Delegating: high competence and confidence, needs autonomy more than involvement.

The same person can sit in different quadrants for different tasks at the same time, so this is applied per-skill, not as a single label for the whole relationship.

Adapting to feedback-culture differences

How directly to give feedback isn't purely a personal style preference; it's shaped by cultural norms the mentee brings, and treating it as pure style risks an equity failure, not just a communication mismatch. Someone from a background where direct, blunt feedback is the norm may find indirect feedback confusing or even read it as a lack of respect for their ability to handle it; someone from a background where direct public correction is genuinely unacceptable may experience the same blunt feedback as disrespectful or even shaming, regardless of intent. Noticing which context someone is bringing, and adjusting delivery accordingly while keeping the substance intact, is part of doing this well rather than an optional nicety.

Adapting by seniority of the mentee

A junior mentee usually needs more structure, more explicit scaffolding, and more frequent checkpoints. A senior mentee needs something different: less procedural guidance, more of a thinking partner, and often an explicit expectation that they take on some mentoring of others themselves, since developing that skill is frequently the actual next step in their own growth, not something to route around.

Worked example

Situation

I mentored someone who worked best from a fully worked-out plan before starting anything ambiguous, while my own instinct is to start acting and figure out the plan as I go. Early on, my default approach (throw them a loosely scoped problem and let them work it out) was clearly causing more anxiety than growth; they'd stall rather than experiment.

Action

Instead of pushing them toward my own style, I adjusted the mechanism while keeping the goal (building comfort with ambiguity) the same: gave them explicit structure up front for the first few tasks (a rough plan to react to and revise, rather than a blank page), and deliberately widened the ambiguity only gradually as their confidence grew, checking in on how it felt rather than assuming.

Result

Over time they needed less upfront structure and became noticeably more willing to start from a loosely scoped problem on their own, which was the real signal of the adaptation working: not that they'd adopted my style, but that they'd built their own comfort with ambiguity at a pace that actually worked for them.

Trade-offs & pitfalls

• Assuming your own learning style is the default. The single most common failure here is mentoring the way you'd want to be mentored, rather than the way the specific person in front of you actually learns.
• Treating feedback-culture adaptation as optional politeness rather than an equity issue. Delivering feedback the same blunt way to everyone regardless of their background isn't neutral, it systematically disadvantages people for whom that style reads as disrespect rather than directness.
• Over-adapting to the point of never stretching the person. Adapting to someone's current style is different from leaving them there permanently; part of growth is gradually building comfort outside their comfort zone, not just permanently accommodating it.
• Forgetting that senior mentees need a different kind of adaptation, not just less attention. Assuming a senior mentee needs nothing from you, rather than a different kind of engagement (including expecting them to mentor others), under-invests in someone who still has real room to grow.

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
Ramping someone from day one to their first shipped work is a deliberate sequence, not a single onboarding checklist: assess what they actually already know, give them small real tasks with tight review loops before a full feature, gradually widen the scope of ownership, and define upfront what "shipped" and "done" mean so the finish line is unambiguous. The plan should look different depending on who's arriving, not just be a fixed template applied to everyone.

Structured elaboration

The default arc

• First few days: orient and assess. Don't assume a blank slate; find out what they already know so you're not re-teaching things or, worse, skipping things they actually need.
• Early tasks: small, real, low-blast-radius work with fast, close review. The goal here is confidence and calibration to the team's standards, not speed.
• Middle stretch: progressively larger scope with more independence, review shifting from "check everything" to "check the risky parts."
• First real shipped piece: something end-to-end they own, with you available but not doing it alongside them, and a clear definition of "done" agreed before they start, so success isn't a moving target.

Adapting the plan to who's actually arriving

This is where a generic checklist breaks down, and it's the part that separates a senior answer:

• A contractor under least-privilege or compliance constraints: access is scoped down from day one, so the plan has to work around what they legitimately can't see or touch, and documentation often needs to be more explicit since they can't casually ask around as easily as a full-time hire embedded in the org.
• A career-changer from an adjacent discipline (a backend engineer moving into data engineering, a research scientist moving into production ML): they're not a blank slate, they have real transferable skills. The plan should explicitly identify what carries over and target ramp-up specifically at the actual new-domain gaps, not restart from zero the way you would for someone with no relevant background.
• A cohort of remote interns rather than one hire: 1:1 pairing time doesn't scale to a group. The plan shifts toward a shared structured curriculum, peer learning between the interns, and scheduled office hours, with 1:1 time reserved for the things that genuinely need it.
• A remote hire versus a senior IC joining: a remote hire needs more of everything written down explicitly, since the informal hallway learning that fills gaps for an in-person hire doesn't happen by accident. A senior IC's gap is usually organizational context and relationships, not raw skill, so their plan should be lighter on procedural scaffolding and heavier on introductions, context on how decisions get made, and where the landmines are.

Worked example

Situation

I mentored someone joining as an individual contributor with solid general skills but no exposure to our specific stack or codebase, with a goal of them shipping one real, complete piece of work within their first several weeks.

Action

Week one was mostly orientation and a short assessment task to see where they actually stood, not a generic reading list. From there, I gave them a small real bug fix with a tight review loop so they got fast, specific feedback on our conventions early, before those habits calcified the wrong way. Over the following weeks the scope widened: a small self-contained feature with me reviewing closely, then a larger piece with me available but stepping back from line-by-line review, focusing instead on the riskiest parts of the design.

Result

They shipped a real, complete piece of work end-to-end within the target window, with a review pass that looked much closer to how we review any other team member's work by that point, which was the actual signal of readiness, not just that the calendar had passed.

Trade-offs & pitfalls

• Treating every new hire's plan as the same template. A junior mentor runs the same onboarding for a contractor, a career-changer, an intern cohort, and a senior IC. A senior mentor adapts the shape of the plan to who's actually arriving, because the actual gap being closed is different in each case.
• Under-scoping early tasks out of excessive caution, or over-scoping out of impatience. Both undermine the confidence-building purpose of the early stretch: too small and it's condescending or boring; too large too soon and the first review becomes overwhelming and demoralizing.
• Not defining "done" up front. Ambiguity about what counts as finished either causes needless rework or lets something ship that isn't actually ready, and both erode trust in the mentoring relationship.
• Ignoring the constraints a nontraditional hire is actually operating under. Applying a full-access, in-person, junior-IC plan to a least-privilege contractor or a remote hire sets them up to fail on logistics that have nothing to do with their actual skill.