The framing that mentoring is a cost to senior engineers is so common it’s become invisible.

“It takes time.” “It slows you down.” “You’re carrying them while they ramp up.” These statements are true in a narrow, short-term sense. And they completely miss what’s actually happening when mentoring works.

When you take a junior developer and help them become a strong mid-level engineer, you haven’t spent time - you’ve built capacity. That person’s contributions compound for years. They become someone who can carry work you’d otherwise have to carry yourself. They become, in time, someone who can mentor the next junior developer who joins. The value of that investment is hard to calculate precisely, but it’s measured in years and team-years of capability, not in the hours you spent pairing with them.

Mentoring is leverage. It’s one of the highest-leverage things a senior engineer can do, and it gets framed as a sacrifice.

The mechanics of good mentoring are often misunderstood, especially by engineers who became good at the craft primarily through independent work.

The instinct is to explain. Someone asks a question; you answer it. Clearly, thoroughly, efficiently. You’ve transferred the information; they know the thing now.

The problem is that explaining produces dependency. The person learns that when they have a question, you have the answer. They learn to come to you, not to develop the instinct to find answers themselves. You haven’t made them more capable - you’ve made yourself more necessary.

The alternative is to ask back. “What have you tried?” “What do you think is happening?” “Where would you look first?” This is slower in the moment. It feels like you’re withholding help. But you’re doing something different: you’re developing their problem-solving muscle, not just filling in a specific gap in their knowledge.

The best mentors I’ve had asked more than they told. They made me do the thinking, and supported the process, rather than thinking for me.

The other mechanic that matters: give them real work.

Junior developers are often under-challenged. They get the small tickets, the low-stakes fixes, the work that won’t break anything important. The rationale is protective - you don’t want them making costly mistakes on critical systems.

The cost of this protection is that they don’t develop judgment under real conditions. Judgment is built through decisions with real consequences, not through safe practice tickets. You learn to estimate by estimating things that actually matter. You learn to catch your own mistakes by making mistakes in a context where someone notices and gives you feedback.

The version of mentoring that works is: real work, visible support, fast feedback. Not real work thrown over the fence, and not synthetic work in a low-stakes sandbox. Real tickets, real codebase, real review - but with a senior engineer available to pair when stuck, review before merge, and debrief after.

This requires more investment from the mentor than just “let them figure it out,” but it produces better engineers faster.

There’s a failure mode worth naming that’s specific to high-performing individual contributors who become informal mentors: they get impatient.

The work is taking longer than it would if they just did it themselves. The junior developer is going in a direction the senior can see won’t work. The code review has problems that feel obvious.

The temptation is to take over - to either do the thing directly, or to over-specify how it should be done. Both cut off the learning. The junior developer needed to go in the wrong direction and discover why it didn’t work. They needed to write the flawed code and hear the feedback that explains why it’s flawed. That’s the process. Interrupting it to get to the right answer faster is optimizing for the wrong thing.

The impatience is understandable. You’re busy. You have your own work. The fastest path to the correct output is to produce it yourself.

But that’s not the goal. The goal is to produce an engineer who can produce correct output without you. Keeping that goal in view is what separates mentoring from just helping.

The compounding effect is real and worth taking seriously.

A senior engineer who invests in three junior developers over the course of a few years has effectively multiplied their own output. Those three engineers carry work, catch problems, improve the codebase, and eventually mentor the next generation. The senior engineer’s time investment - which felt like a cost in the short term - turns into a capability multiplier that runs for years after the investment was made.

The organizations that understand this build cultures where senior engineers are explicitly expected to develop the engineers around them, not just to produce output themselves. They measure and reward it. They create time for it.

The organizations that treat mentoring as a nice-to-have, something that happens when there’s bandwidth, produce a permanent shortage of experienced engineers because they’re not building the pipeline.

If you’re a senior engineer and you’re not mentoring anyone right now, that’s worth examining.

Not as a moral obligation - as an investment you’re not making.