Mentoring Engineers Without Burning Out

I've mentored over a dozen engineers across three companies. The ones who grew the fastest had one thing in common: they owned their growth. My job wasn't to teach them everything — it was to create the conditions where they could teach themselves.

Structured growth plans. Every engineer I mentor gets a document with three sections: what they're good at now, what they want to be good at in six months, and the specific projects that will bridge the gap. We review it every two weeks. The plan is theirs — I just help them see the path.

Code review as teaching. I don't just point out what's wrong. I explain why it matters, show the alternative, and link to a pattern or principle. A good code review teaches the decision-making framework, not just the fix. Over time, the comments get shorter because the engineer starts catching the same patterns themselves.

The one question. When an engineer brings me a problem, I ask: 'What do you think we should do?' Nine times out of ten, they already know the answer — they just want validation. The tenth time, we work through it together. This builds decision-making confidence faster than any amount of direct instruction.

Mentoring is a force multiplier. Every hour I spend helping an engineer level up pays back ten hours of their future work being better, faster, and more independent. It's the highest-leverage activity a senior engineer can do.