TL; DR:
No cookie cutters allowed
Just because they're doing well doesn't mean you can't have an added benefit
Check out the live stream (or watch the recording) on Monday, July 14th at 7:00 PM Pacific!
How to Mentor Mid-Level Engineers
You’ve been told to mentor someone.
They’re mid-level.
They’re independent.
They don’t seem to need help.
They aren't junior anymore, and they seem to be doing a solid job contributing with a good level of autonomy. So... now what?
This is one of the most common yet least discussed challenges when it comes to the people side of software development:
How do you effectively mentor someone who already seem capable?
It’s easy to feel useless. Or awkward. Or like there isn't really a point to what you're tasked with. You might even start to feel like an imposter because you're not sure how YOU are supposed to be helpful in this situation.
If you're in this position, especially as an IC (not a manager), this one is for you. The first years of my role as an engineering manager, this is what I faced non-stop. I covered this in more in my Code Commute episode discussing mid-level mentorship:
Step One: Clarify Expectations
Before you jump into mentoring mode, pause.
Ask yourself:
Why are you being asked to mentor this person in the first place?
You'd be surprised how often we should probably do this before jumping into something... So while it might seem obvious, it's worth calling out still.
If it came from your manager, do you know what they’re hoping for? Do they even know? Did they explicitly tell you?
It might be:
To give you leadership experience
To help the mentees grow toward senior promotion
To address an issue the mentees aren’t aware of
Just a nudge to start knowledge sharing more across the team
But you won't know unless you ask. And assuming isn't a great recipe for success.
Actionable Tip:
In your next 1:1 with your manager, say something like:
“I’m excited to support these folks (or this person), but I want to make sure I’m focusing on the right things. Was there anything specific you had in mind for their development?”
Don't keep yourself in the dark. And yes, you can apply this same advice to like... everything -- not just because you were assigned mentees.
Building Trust
One common trap is assuming your job as a mentor is to give answers. After all, you have allllll that experience!
But it’s not. At least not at first.
Your initial job is to earn trust and understand context.
Even if your mentees already respect your seniority, don’t assume they trust you -- especially with their challenges, ambitions, or fears. You want both respect and trust.
You earn that trust by:
Being consistently reliable
Following through on what you say
Asking thoughtful questions and actually listening
Showing you care about them, not just your own status, and not just because your manager said so
If you show up to a mentorship session with “here’s what you should do,” and you haven’t invested in trust, it won’t land. Worse, it could backfire.
Actionable Tip:
At the start of your mentorship relationship, ask:
“What does good support look like for you? Want me to be a sounding board, offer advice, help you build something, challenge your thinking?”
This creates alignment and signals that you're there for them, not just to fulfill a checkbox. They might not know the answer right away -- and that's okay. You can always try something and then come back to this question to see how to make adjustments.
But... There's No Clear Goals In Mind!
This is probably the most common scenario.
You ask, “What would you like to focus on? How would you like to grow?”
They say, “I’m not sure.”
You say, “Okay...”
And then nothing happens. The end!
Early on in my career as a manager, I unfortunately fell into this trap. My employees were doing well, so I probably didn't need to get involved, right?
The reality:
Mid-level engineers who are productive and independent can still grow.
They just might not know how, or even what they’re missing.
That doesn’t mean there’s no growth to pursue. It means you need to help them discover it. And the reality is that even helping them navigate things to uncover growth areas could be an enormous value add for them.
Actionable Tip:
Try this reflection-based exercise in a session:
“What part of your current role feels too easy?”
“What part still causes friction or stress?”
“What are you avoiding doing?”
“What part of the codebase or product do you wish you understood better?”
“What would you want to be known for on this team?”
Get them to write their answers down -- you could jump in too and try it for yourself. Lead by example!
Stretching, Not Stressing
If someone is performing well, it’s tempting to leave them alone. They're already doing well, so don't disrupt things... right? But growing them means getting them just a little uncomfortable.
The goal isn’t to throw them into the deep end. It’s to offer a path to expand their comfort zone without overwhelming them.
Some examples of stretch opportunities:
Leading a small cross-team initiative if they're already able to lead projects within the team
Writing a design doc for a project instead of just building out the code for one someone else wrote
Investigating a production issue solo (with support)
Presenting learnings from a project to a broader team
Reviewing someone else’s code in a new domain
... it could look VERY different for each and every individual.
Actionable Tip:
Pick one of these areas and say (in your own words, unless you want to sound like a weirdo):
“I think you’re ready to take a swing at this. Want to try leading next time and I’ll shadow or support as needed?”
It's important to give them some room so that they can get a bit uncomfortable -- but you let them know you're able to support them, and you follow up on that to ensure they truly are supported.
Stay In Sync With Their Manager
This one’s big.
If you’re mentoring someone on your team (or in your org), and you’re not syncing with their manager, you can create some headaches.
Even if your advice is good, it’s a problem if it’s:
Contradicting their manager’s guidance
Misaligned with their performance goals
Unaware of organizational priorities
You’re trying to help. But you might accidentally hurt their trajectory. Ultimately, this creates confusion for your mentee, and it's a sour time overall -- despite ALL of the intentions being positive to try and help them grow.
Actionable Tip:
Use your 1:1s with their manager (it's potentially your manager too, right?) to say:
“Here’s what I’m working on with them. Does that line up with where you’re trying to grow them?”
Also, encourage the mentee to bring up your conversations in their own 1:1s. Approach it from different angles so that there's overcommunication. We want to avoid surprises as much as possible and create alignment.
Avoiding the Cookie Cutter
Here’s where a lot of well-intentioned mentorship fails:
Trying to apply a “framework” to two different people.
Even if both mentees are at the same level, on the same team, and doing similar work -- the way you mentor them should likely be different.
One might be more ambitious.
The other more cautious.
One might be a natural communicator but struggle with architecture.
The other might write flawless code but avoid cross-functional work.
So yes, start with a structure... but if your "framework" is just applying the same actions to each individual then you're likely missing the mark.
Actionable Tip:
Think about your own approach and philosophies when it comes to mentorship:
How are you building trust with your mentees?
What areas have you focused on for your mentees?
Are there things you're avoiding? Blindspots?
It's totally fine if your framework is ACTUALLY a framework to guide you, but if you're mistaking your one-size fits all approach as a framework then it's time to head back to the drawing board.
Mentorship Can Sharpen Your Own Skills
Let’s be real for a second. Mentoring makes you better too.
You’ll get better at:
Explaining complex ideas simply
Observing patterns in others’ behavior
Coaching without controlling (nobody likes a micromanager)
Seeing how growth happens across different personalities
Communicating with empathy and patience
All of these are senior-plus skills.
Actionable Tip:
After every mentorship session, reflect:
What went well?
What didn’t land?
What would I do differently next time?
You’re building your leadership skillset, even if your title never changes.
Mentorship Is Leadership by a Different Name
You don’t need a manager title to be a force for growth and an effective multiplier.
If you’re mentoring someone, you’re leading. If you’re helping someone expand what they believe they can do, you’re having impact.
That impact compounds.
Remember that this isn't a perfect process -- don't expect it to be. Aim to be present, thoughtful, and consistent.
The rest will come.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I'll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!