Mentoring and Coaching Questions

Direct answer
Two well-chosen SMART goals for a mentee should target different dimensions, not two flavors of the same gap, typically one concrete skill or output gap and one behavioral or collaboration gap, each tied to real upcoming work (not an abstract exercise) with a defined timeframe and a way to verify progress that isn't just your own impression.

Structured elaboration

Picking the goals

• Start from an actual observed gap, not a generic template. Watch the person's real work for a pattern (recurring rework in reviews, difficulty scoping ambiguous tasks, avoiding certain kinds of conversations) rather than picking goals off a checklist.
• Pick goals from different dimensions on purpose. Two goals that are both "write better code" don't cover as much ground as one technical goal and one collaboration or communication goal; below-the-bar performance and stalled growth are rarely single-dimensional.
• Anchor each goal to real, upcoming work rather than an artificial exercise, so achieving it has actual value beyond the goal itself.

Making them SMART without making them hollow

• Specific: named against a real, current gap, not a generic aspiration ("get better at code review" is weak; "flag the two or three highest-risk issues in a review instead of commenting on every minor style choice" is usable).
• Measurable: defined by evidence you can point to later, not a feeling. This doesn't require an invented precision metric; "the last three reviews they gave focused on real risk rather than style nits" is legitimate evidence.
• Achievable: a real stretch, not guaranteed, but genuinely possible in the timeframe given their current level.
• Relevant: tied to what actually matters for their next step, not an arbitrary skill.
• Time-bound: a defined window, short enough to check in on meaningfully, long enough for real practice to happen.

Verifying they were met

Verification should come from something observable in the work itself, ideally corroborated by someone other than just you (a peer's comment, a second reviewer's read), not solely your own subjective sense that things feel better.

Worked example

Situation

A mentee was technically solid but had two recurring gaps: their code reviews tended to focus on minor style points while missing the real risk in a change, and they rarely spoke up in group design discussions even when they clearly had a relevant opinion afterward.

The two goals

1. Review focus: over the next 6 weeks, shift their code review comments toward flagging genuine risk (correctness, edge cases, design concerns) rather than style, verified by a second reviewer independently agreeing their flagged issues were the real risk areas in at least the majority of reviews they gave in that window.
2. Speaking up in design discussions: over the next 8 weeks, raise at least one substantive point live in a design discussion, rather than only afterward privately, verified simply by whether it happened and by a peer noticing the shift unprompted.

Why these two, not two code-quality goals

Picking a technical goal and a behavioral goal together addressed two independent gaps at once, rather than doubling down on the dimension that was already their relative strength.

Result

Both goals gave something concrete to check in on during regular 1:1s, and both had a verification method that didn't rely purely on my own impression, which mattered for making the conversation feel objective rather than a subjective judgment.

Trade-offs & pitfalls

• Goals that sound measurable but aren't actually verifiable. "Be more proactive" dressed up with a number attached is still not a real SMART goal if there's no real way to check it.
• Two goals in the same dimension. Picking two technical goals, or two soft-skill goals, leaves a real gap uncovered and wastes the opportunity a second goal represents.
• Goals set without the mentee's buy-in. A goal the mentee didn't help shape, or doesn't actually agree reflects a real gap, is much less likely to stick, even if it's technically well-formed.
• No connection to real work. An artificial exercise goal ("complete this course") is weaker evidence of growth than a goal embedded in work they were doing anyway.

Direct answer

Decide what to delegate by looking at two things: where the task sits relative to the person's current skill level, and what happens if they get it wrong. Delegate work that stretches them but is reversible or cheap to fix. Keep for yourself work that needs context you can't hand off in time, decisions whose blast radius exceeds the trust you've built with this person so far, or one-off tasks where teaching would take longer than doing it. Treat each handoff as a deliberate intervention, not an offload: pick the task for the specific gap it targets, define what "done" looks like up front, and calibrate how much support comes with it.

Decision framework

Match difficulty to their zone of growth. Too easy and it's busywork with no development value. Too hard with no support and it's discouraging or risky. The sweet spot is a task just past what they've done independently before.

Weigh reversibility, not just difficulty. Prefer delegating decisions that are cheap to undo (a first draft, a component design, a low-stakes customer interaction) over ones that are hard to walk back (a commitment made externally, a change with security or compliance exposure). Trust for higher-stakes delegation gets built incrementally through the reversible tasks.

Compare time-to-teach against time-to-do. If explaining the task well would take meaningfully longer than doing it yourself, and it's a one-off with no repeat value, do it yourself. If it's a skill they'll use again, the teaching cost is an investment that pays back on the second and third time.

Define the support structure explicitly. Delegating isn't handing off and disappearing. Decide in advance: what checkpoints happen, what they can decide alone versus what needs a quick check-in, and what "stuck enough to escalate" looks like.

What you keep. Work that needs institutional context you can't transfer in the available time, early-relationship politically sensitive conversations, and anything where a mistake would damage a stakeholder's trust in the team broadly rather than just cost you some rework time.

Worked example

Say you're leading a project with three distinct pieces. One is well-scoped, reversible, and slightly above where this person has worked before: a strong candidate to delegate as a growth task, with a design check-in before they start building and a review before it ships. Another piece is customer-facing with real cost if it goes wrong: you either delegate it with heavy pairing so you catch problems before they land, or you keep it yourself this round and delegate the next similar piece once trust is established. The third is a one-off internal chore with no growth value: you delegate it purely for your own capacity, not as a coaching move, and you say so, because dressing up busywork as a growth opportunity erodes trust.

Trade-offs and pitfalls

Delegating only "safe" tasks because failure is expensive to you personally caps the person's growth. They never build judgment under real stakes if you only ever hand them things that can't go wrong.

Delegating and then vanishing looks like empowerment but is often abdication. The failure mode shows up late, when it's expensive to fix, because there was no checkpoint designed to catch it earlier.

Over-specifying the implementation defeats the purpose. If you hand someone a task but dictate every step, there's no room left for them to exercise judgment, which is the actual thing you're trying to develop.

The honest trade-off: delegating a stretch task usually costs you more short-term time, in reviewing and coaching, than doing it yourself would. That extra cost is the investment, and it's worth naming rather than pretending delegation is free.

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
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.

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.