If you asked me to describe my role in mentoring in a single sentence, it would be this: I try to make my thinking visible so someone else can borrow it, adapt it, and eventually replace it with their own.

Anyone can hand over a fact — “use an index here,” “add a circuit breaker there.” That is useful, but it is the cheapest part of mentoring. The expensive, valuable part is showing how I arrived at the recommendation in the first place: what I ruled out, what trade-off I was weighing, what quiet past failure I was busy trying not to repeat.

A junior engineer who copies my answer has solved today’s problem. A junior engineer who understands my reasoning can solve next month’s problem without me in the room. That, honestly, is the entire point — mentoring should make itself unnecessary over time, at least for the specific skill being taught. If a mentee still needs me in the room a year later for the same class of question, one of us has misunderstood the assignment.

“Mentor” is a single word covering at least four distinct jobs, and knowing which hat a moment actually calls for is half the skill.

I have learned, sometimes painfully, to notice which one a conversation really needs — because reaching for the wrong one (coaching when someone needs a straight answer, or answering when someone needs to struggle a little longer) does more harm than saying nothing at all.

In practice, most mentoring conversations blend two or three of these inside a twenty-minute slot. Someone comes in asking a technical question (guide), but the real issue underneath is “am I even good at this?” (coach). Learning to hear the second question hiding under the first one took me years to develop, and I still miss it sometimes — usually on the days when I am tired and reach for the fastest available answer instead of the right one.

I do not run mentoring sessions from a script, but a few mental models consistently keep me useful instead of just opinionated. These are the ones I have kept because they have survived contact with real people, not because they sound clever in a talk.

3.1 Ask before I answer

My default first move, almost every time, is a clarifying question rather than a solution: “What have you already tried?” or “What does your gut say, and what is making you doubt it?” This does two useful things at once — it respects that the person has usually already done real thinking before they walked in, and it stops me from confidently solving a problem they did not actually have.

3.2 Match support to skill and will (situational mentoring)

Borrowed loosely from situational leadership: someone who is new to a skill but highly motivated needs direction and structure. Someone who is skilled but has lost confidence needs encouragement far more than instruction. Someone who is skilled and motivated mostly needs me to get out of the way and just remove blockers. I try to diagnose which quadrant a person is sitting in this week before deciding how much to say, because “how much to say” is almost always the harder question than “what to say.”

3.3 The 70/20/10 lens on how people actually grow

Roughly seventy percent of growth comes from doing the hard, real work itself; twenty percent from relationships — mentors, peers, feedback; ten percent from formal learning like courses or docs. That ratio quietly reframes my job: I am not the primary source of someone’s growth, I am an amplifier around the edges of work they are already doing. It keeps me from overestimating my own importance in the story, and it pushes me to get people into the hard work rather than talking about it from a safe distance.

The same mentoring move lands completely differently depending on experience level. I have had to unlearn the instinct to mentor everyone the same way I would have wanted to be mentored — because what I actually needed at year one and what I needed at year eight were almost opposites.

Nothing about that table is a rigid classification. People move between rows depending on the topic, the week, and how much sleep they got. A senior engineer taking on their first data-intensive system is, briefly, back to early-career on that specific axis, and treating them like a staff engineer in that moment would just make them feel behind. Calibration is a continuous practice, not a one-time diagnosis.

Stripped of the vocabulary, most of my mentoring happens inside ordinary engineering work, not in separate “mentoring meetings” that show up on a calendar with a helpful label. A few of the concrete shapes it tends to take:

What ties these together is that none of them require a formal “mentor” title to work. They are the ordinary artifacts of engineering — a review comment, a design meeting, an incident channel — being treated as opportunities to make thinking visible instead of just moving tickets across a board.

Most of what I know about mentoring well, I learned by first doing it badly — usually with the best of intentions. A few patterns I now actively watch for in myself:

The pattern underneath all of these anti-patterns is the same: prioritizing my own comfort — the comfort of being seen as helpful, being fast, being right — over the mentee’s actual growth. Whenever I catch myself reaching for one of them, it is almost always because I am tired, not because it is genuinely the right move.

Mentoring does not show up cleanly in a dashboard, but there are honest signals I watch for over the arc of a mentoring relationship rather than inside any single conversation.

• The questions someone brings me get harder over time, not easier — they have quietly stopped needing me for the easy ones.
• They start pre-empting my questions before I ask them: “I know you’ll ask about the failure mode here, so…”
• They disagree with me and hold their ground with a reasoned argument — and I find, embarrassingly often, that they are right.
• They start mentoring someone else, unprompted.

That last signal is the real marker of success for me. Everything else can be faked or accidentally produced by proximity to a good team. Watching a former mentee, in a review or a design meeting, patiently ask a junior engineer the same clarifying question I once asked them — that is when I know something actually transferred, and did not simply sit in one head for a while before evaporating.

I get asked this often by engineers a few years in who want to mentor but feel like they have not “earned” it yet. My honest take: you do not need to be senior to mentor. You need to be one step ahead of someone on one specific thing, and willing to be patient and honest about it.

These are the questions I get most often when engineers ask about mentoring off the record — usually in the hallway, after a talk, or as a “quick DM” that turns into a long thread.

Is mentoring the same as managing?

No. A manager is accountable for someone’s output and has authority over their role. A mentor has no formal authority — the relationship only works because the mentee chooses to engage with it. Some of the most effective mentors I have had were never my manager, and some of my managers were, honestly, not the people I went to for mentoring at all.

How much time does good mentoring actually take?

Less than people expect, but it needs to be consistent. A protected thirty-minute conversation every two weeks, plus being genuinely present during code reviews and design discussions, goes far further than one long session a quarter. Consistency compounds; intensity does not.

What if my mentee wants a different career path than mine?

That is common and completely fine. My job is not to produce a copy of myself — it is to help them get clearer on their own goals, even ones I have not personally pursued, and connect them with people who have. A mentor who can only usefully advise on the exact path they walked themselves is a fairly limited mentor.

How do I mentor someone more senior than me on a specific topic?

This happens more than people admit out loud. Expertise does not map neatly to seniority — someone senior might genuinely need your help with a tool, a technique, or a corner of the domain that you know better. Treat it as a peer exchange rather than forcing it into a hierarchy, and both sides get more out of it.

What do I do when a mentee stops taking my advice?

First, check whether the advice was actually good in their context, not just correct in the abstract. Second, get curious about why — often there is a constraint I did not see. And third, remember that ignoring specific advice is not the same as ending the relationship. A mature mentee will absorb some of what I say, discard some, and adapt the rest. That is a healthy sign, not a warning one.

How do I mentor across remote and time-zone gaps?

Write more, and write it down where it can be re-read. In a remote setting the hallway conversation disappears, and thoughtful asynchronous review comments, small Loom-style walkthroughs, and clearly-scheduled 1:1s carry a disproportionate share of the mentoring load. The medium changes; the underlying practice does not.

If a single page of this piece is all you carry with you, it should be this one — the working notes I would want a version of myself from ten years ago to read before their first serious mentoring conversation.

None of this is a finished discipline. Every mentoring relationship rewrites some small part of how I understand mentoring itself, and the version of this piece I would write in five years is almost certainly going to disagree with parts of the version I wrote today. That is the point — mentoring is the one skill in engineering that gets better mainly by staying humble about it, not by declaring it solved.