Mentoring Isn’t a Side Quest—It’s the Real Game
Mentoring is one of the highest-leverage things you can do in your career.
Reaction to Chapter 2 of The Manager’s Path
Let’s get one thing straight:
Most engineers think mentoring is optional.
Like…
“Yeah, I’ll help the new guy when I’m not busy.”
Which basically means: never.
Chapter 2 of The Manager’s Path politely disagrees.
I won’t be polite:
👉 Mentoring is one of the highest-leverage things you can do in your career.
And if you’re ignoring it, you’re slowing down not just your team—but yourself.
The Lie We Tell Ourselves About Mentoring
We treat mentoring like a “nice-to-have.”
“I’m too busy”
“I’m not senior enough”
“They should figure it out themselves”
Sounds reasonable. It’s also wrong.
The book makes it clear: mentoring is not charity—it’s force multiplication.
You help one engineer today…
You avoid 50 problems tomorrow.
Mentoring = Scaling Yourself
Here’s the part that hit hard.
As engineers, we obsess over scaling systems:
Caching
Load balancing
Distributed architecture
But when it comes to people?
We hoard knowledge like it’s a secret API key.
Mentoring is basically:
Turning yourself into a distributed system.
Instead of:
You solving 10 problems
You get:
5 people solving 50 problems
That’s not feel-good leadership. That’s efficiency.
The “Alpha Geek” Trap
The book calls out a specific anti-pattern:
👉 the “Alpha Geek”
You’ve seen this person:
Knows everything
Solves everything
Becomes the bottleneck for everything
At first, they look like a hero.
Long term?
They’re the reason the team can’t scale.
Because instead of teaching, they:
Gatekeep knowledge
Jump in to “save the day”
Stay indispensable (on purpose or not)
💡 Hot take:
If your team can’t function without you, you’re not a leader—you’re a liability.
Good Mentors Don’t Just Answer Questions
One subtle but powerful idea from the chapter:
Mentoring is not about giving answers.
It’s about growing thinking.
Bad mentoring:
“Here’s how you fix it.”
Good mentoring:
“What have you tried?”
“Why do you think that failed?”
“What would you do differently?”
It’s slower in the moment.
But way faster in the long run.
Mentoring New Hires: Your First Impression as a Team
The chapter highlights mentoring for:
Interns
New hires
Junior engineers
And this is where most teams mess up.
We expect new hires to:
Ramp up fast
Ask good questions
Be productive quickly
…while giving them:
Outdated docs
Zero guidance
“Just explore the codebase” energy
The book suggests involving them in improving onboarding itself—like updating documentation as they learn.
Which is honestly genius.
💡 Fresh eyes + confusion = better docs for everyone.
Mentoring Is a Skill (And Most of Us Are Bad at It)
Nobody teaches engineers how to mentor.
So we default to:
Explaining too much
Explaining too little
Getting impatient
Taking over
Good mentoring requires:
Empathy
Communication
Patience
Awareness of different learning styles
Basically… all the things engineers pretend don’t matter.
The Real ROI of Mentoring
Let’s talk selfish benefits (because those matter too):
Mentoring helps you:
Think more clearly
Communicate better
Prepare for leadership roles
Build influence without authority
And here’s the kicker:
👉 Mentoring is the bridge between IC and manager.
If you can’t grow people, you won’t survive management.
The Part That Stings a Bit
This chapter quietly challenges your identity.
If you define yourself as:
“The smartest one in the room”
“The one who solves the hardest problems”
Then mentoring feels like:
👉 giving that up
But that’s the point.
You’re not supposed to stay the hero.
You’re supposed to build a team full of heroes.
Final Thoughts
Chapter 2 doesn’t scream. It nudges.
But if you read between the lines, it’s saying:
Your value as an engineer is not just what you produce—
it’s what you enable others to produce.
So next time someone asks you for help:
Don’t rush it
Don’t dismiss it
Don’t solve it instantly
Take a bit more time.
Because that “slow” conversation?
That’s how you build fast teams.