Career Development & Mentorship

Your Role in People's Careers

Let me be direct with you: as an Engineering Manager, you are the single biggest influence on whether the people on your team grow or stagnate. Not HR. Not the VP. Not the "learning and development platform" your company pays for. You.

You control what projects someone works on. You decide who gets visibility. You shape what feedback they hear, how often they hear it, and whether anyone is actually paying attention to their trajectory. When you invest in someone's growth, they feel it. When you don't, they feel that too — they just don't always tell you. They tell their friends, update their resume, and quietly start interviewing.

This is not a side task. It is not something you squeeze into the last five minutes of a 1:1 because you ran out of sprint updates to talk about. Career development is core to your job. If you're not actively thinking about where each person on your team is headed and what they need to get there, you are failing at a fundamental part of the role.

That might sound harsh. Good. Because the engineers who leave and say "nobody cared about my growth" — that's on their manager. Every time.

The flip side is just as true. When someone gets promoted and says "my manager believed in me before I believed in myself," that's one of the most rewarding things you'll experience as a leader. It's worth the effort. Every time.

Individual Development Plans (IDPs)

An Individual Development Plan is a living document that captures where someone is, where they want to go, and the concrete steps to get there. When done well, it's a powerful tool. When done poorly, it's a checkbox exercise that sits in a Google Doc no one ever opens again.

Let's talk about doing it well.

What an IDP Actually Is

An IDP is not a performance review. It's not a list of things someone is bad at. It's a forward-looking agreement between you and your report about their professional growth. It answers three questions:

Where are you now? (Current skills, strengths, areas for growth)
Where do you want to be? (In 6 months, 1 year, 2 years)
What's the plan to get there? (Specific actions, experiences, learning, timelines)

How to Create One Collaboratively

The key word is "collaboratively." You are not writing this for someone. You are building it with them. Here's a process that works:

Step 1: Have the conversation first. Before anyone opens a document, sit down (or hop on a call) and just talk. Ask them what excites them. What they want to learn. What kind of work energizes them versus drains them. Where they see themselves heading. Listen more than you talk.

Step 2: Reflect their strengths back to them. Many engineers underestimate what they're good at. Tell them what you see. "You're one of the strongest debuggers on the team." "People come to you when they're stuck on design problems — have you noticed that?" This grounds the plan in reality.

Step 3: Identify 2-3 growth areas together. Not ten. Not one. Two or three areas where focused effort would make a real difference. Maybe it's system design, or public speaking, or learning to influence without authority.

Step 4: Make it concrete. For each growth area, define:

What success looks like — observable, specific outcomes
Actions to take — projects, courses, pairing sessions, reading
Timeline — when you'll check in on progress
Your role — what you will do to support them

Step 5: Write it down. Keep it short. One page is ideal. Two pages maximum. If it's longer than that, it's too complicated to act on.

Step 6: Revisit it regularly. Monthly at minimum. Not just "did you do the thing?" but "is this still the right plan? Has anything changed? What's getting in the way?"

What Makes an IDP Actually Work

The difference between a useful IDP and HR paperwork comes down to specificity and follow-through.

Bad IDP goal: "Improve leadership skills."

Good IDP goal: "Lead the Q3 migration project end-to-end, including running the weekly sync, coordinating with the platform team, and presenting the post-mortem. By the end of Q3, get feedback from at least two stakeholders on communication and coordination."

See the difference? The second one is something you can actually do, measure, and learn from. The first one is a wish.

Growth Conversations

Every 1:1 should have some element of growth in it, but at least once a quarter, you should have a dedicated conversation that's entirely about the person's career. Not the sprint. Not the incident. Not the reorg. Them.

The Framework

Start with the destination:

"Where do you want to be in 1-2 years? What does your ideal role look like?"

Some people will have a clear answer. Many won't. That's fine. Help them explore. Ask follow-up questions:

"What kind of work makes you lose track of time?"
"When you look at people more senior than you, what do they do that you'd like to learn?"
"Is there a role on another team — or even at another company — that you've thought about?"

Then work backward:

"OK, so you want to move toward a tech lead role. What skills do you think you'd need to be ready for that?"

Let them answer first. Then add your perspective. You'll often see gaps they don't see, or strengths they're undervaluing.

Then make it practical:

"What experiences would help you build those skills? How can I create those opportunities for you?"

This is where you earn your keep. It's easy to say "you should work on system design." It's valuable to say "the payments rewrite is coming up next quarter. I think you should lead the design phase. I'll pair with you on the initial architecture and make sure you have access to the platform team for questions."

Tips for Better Growth Conversations

Take notes and follow up. Nothing kills trust faster than having the same conversation every quarter because you forgot what you discussed.
Don't assume everyone wants to be a manager. Some of your best people want to go deep on technical problems. That's a legitimate and valuable path.
Push gently when someone says "I don't know." They might genuinely not know, or they might be afraid to say something ambitious. Create safety.
Be honest about what's realistic. If someone wants to be a principal engineer in 6 months and they're a mid-level IC, don't nod along. Help them build a realistic timeline.

Stretch Assignments

A stretch assignment is a project or responsibility that's slightly beyond someone's current skill level. Not way beyond — slightly. You're aiming for the learning zone, which sits between comfort and panic.

Comfort zone: They can do it with their eyes closed. No growth happens here.

Learning zone (the sweet spot): They have to work hard, learn new things, and might struggle. But with support, they can succeed. This is where growth lives.

Panic zone: They're in over their head. They're not learning — they're drowning. This damages confidence and often the project too.

How to Design Good Stretch Assignments

Match the stretch to the person. An engineer who's never led a project doesn't need to lead a company-wide platform migration. Start with a well-scoped feature that requires cross-team coordination. Then increase scope as they build confidence.

Be explicit that it's a stretch. Say it out loud: "I'm giving you this because I think you're ready to grow into it. It's going to be challenging, and that's the point. I'm here to support you." This reframes struggle as expected rather than failure.

Define the guardrails. What decisions can they make independently? When should they check in with you? What's the "pull the ripcord" signal if things go sideways? Knowing the boundaries actually frees people to take more risks within them.

Support without micromanaging. This is the hardest part. You need to be available without hovering. Check in regularly but don't take the wheel. Ask questions instead of giving answers. "What options have you considered?" is almost always better than "Here's what I'd do."

Debrief afterward. Whether it went well or poorly, the reflection is where the real learning happens. What did they learn? What would they do differently? What surprised them? What skills did they discover they had?

Common Stretch Assignments by Level

Junior to Mid: Own a feature end-to-end. Write a design doc. Mentor an intern. Present at a team meeting.
Mid to Senior: Lead a cross-team project. Run a post-mortem for a production incident. Design a system from scratch. Mentor a junior engineer.
Senior to Staff/TL: Influence a technical strategy across teams. Drive an architectural decision. Represent engineering in a product planning meeting. Build consensus on a contentious technical choice.

Mentorship Structures

Mentorship doesn't happen by accident. Or rather — it does, but inconsistently and usually only for people who are already well-connected. If you want mentorship to be equitable and effective, you need to be intentional about it.

Formal vs. Informal Mentoring

Informal mentoring is what happens naturally. Someone asks a more experienced colleague for advice. They grab coffee. They pair on a problem. This is great, and you should encourage it — but it has a bias problem. People tend to mentor others who remind them of themselves. If you rely only on informal mentoring, you'll systematically under-invest in people who don't fit the dominant profile of your team.

Formal mentoring means deliberately pairing people and giving the relationship structure. It doesn't have to be rigid — monthly check-ins, a loose set of goals, and a defined time commitment (say, 6 months) is enough. The structure makes sure it actually happens and that everyone has access, not just the people who are comfortable asking.

This distinction matters enormously, and most people conflate the two.

A mentor gives advice. They share experience, help you think through problems, and offer perspective. Mentors talk to you.

A sponsor advocates for you. They put your name forward for opportunities. They vouch for you in promotion discussions. They recommend you for that high-visibility project. Sponsors talk about you — in rooms you're not in.

Both are valuable, but sponsorship is what actually accelerates careers. And here's the uncomfortable truth: sponsorship, even more than mentoring, tends to flow along lines of familiarity and similarity. As an EM, you are a sponsor for your team whether you realize it or not. Every time you assign a project, recommend someone for a role, or speak about your team members in a leadership meeting, you're sponsoring — or not sponsoring — someone.

Ask yourself: who am I sponsoring? Is it always the same people? Who am I overlooking?

Building a Mentorship Culture

Make it normal to ask for help. If senior engineers openly talk about their own mentors and what they learned from them, it signals that seeking guidance is a strength, not a weakness.
Create low-friction formats. Lunch-and-learns, pairing rotations, "office hours" where senior engineers are available for questions. Not everything needs to be a formal program.
Celebrate mentorship. When someone grows because of a mentor's investment, acknowledge both people. Make it visible that this is valued.
Cross-team mentoring. Some of the best mentoring relationships happen across team boundaries. People are more candid with someone who isn't their manager or direct colleague.

Training and Learning

Learning should be part of how your team operates, not a line item in a benefits document that nobody uses.

Conference budgets. Give people a budget and let them choose. Don't make them justify why a conference is "directly relevant to their current project." Some of the best learning comes from exposure to adjacent domains. Make it easy to attend — handle approvals quickly, cover travel without hassle, and don't guilt people for being away from their desk.

Online courses and subscriptions. Pluralsight, Coursera, O'Reilly, Educative, whatever makes sense. Buy team subscriptions. Don't make people expense individual courses and wait for reimbursement. Friction kills learning.

Book clubs. Pick a book. Read a chapter a week. Discuss it for 30 minutes. This works surprisingly well. It gives people a reason to read something they've been meaning to read, and the discussion deepens understanding. Rotate who picks the book. Mix technical books with leadership and communication books.

Internal tech talks. A 30-minute slot every two weeks where someone presents something they learned, built, or investigated. Keep the bar low — it doesn't need to be polished. The goal is knowledge sharing, not TED talks. The person presenting learns the most, because teaching forces you to understand something deeply.

Hackathons and innovation time. Give people dedicated time to explore. A quarterly hackathon, a "10% time" policy, or even just "take Friday afternoon to work on something that interests you." Some of the best internal tools and process improvements come out of these.

Pair programming and mob programming. One of the most underrated learning tools. Junior engineers learn senior patterns in real time. Senior engineers learn to articulate their thinking. Everyone gets better.

Making Learning Part of the Culture

The difference between "we have a learning budget" and "we are a learning culture" is whether people actually use it. Here's how to make it real:

Model it yourself. Share what you're reading. Talk about a conference you attended. Admit what you don't know. If the manager doesn't learn, nobody else will feel permission to.
Protect the time. If learning always gets bumped for "urgent" work, it's not really valued. Block time on the calendar. Defend it.
Remove guilt. Some people feel guilty spending work time on learning. Make it explicit: "Spending a few hours a week learning is part of your job. I expect it."
Connect learning to work. When someone takes a course on distributed systems and then applies it to a real design problem, point that out. It reinforces the value loop.

Growing Your Team Leads

One of the most important things you'll do as an EM is develop future technical leaders. Not just for your team — for the organization. Building a pipeline of capable leaders is a gift that keeps paying dividends long after you've moved on.

Identifying Future TLs

Look for people who:

Naturally help others. They answer questions, review code carefully, and proactively unblock teammates. They do this without being asked.
Think beyond their own work. They care about the team's codebase, not just their feature. They notice patterns, suggest improvements, and think about maintainability.
Communicate well. They can explain complex ideas clearly. They write good design docs. They can adapt their communication to the audience.
Handle ambiguity. They don't freeze when requirements are unclear. They ask good clarifying questions and propose reasonable approaches.
Show good judgment. They know when to push back, when to compromise, and when to escalate. They make trade-offs thoughtfully.

Note what's not on this list: being the fastest coder or the one with the most years of experience. Technical depth matters, but leadership requires a broader skill set.

The Delegation Ladder

Don't flip a switch from IC to TL. Build gradually:

Level 1: Task ownership. They own a well-defined piece of work and are responsible for its delivery. You're still making most decisions.

Level 2: Feature ownership. They own a feature end-to-end — design, implementation, testing, rollout. They make technical decisions within scope. You review and provide feedback.

Level 3: Project coordination. They coordinate work across multiple engineers or a small sub-team. They run standups, track progress, and handle blockers. You're coaching on the leadership aspects.

Level 4: Technical direction. They drive technical decisions for a domain or system area. They write RFCs, lead design reviews, and represent the team's technical perspective. You're focused on alignment and organizational context.

Level 5: Team leadership. They operate as a TL in practice — setting technical direction, mentoring others, and partnering with you on team-level decisions. Your role is providing organizational context and removing obstacles.

At each level, debrief regularly. What's working? What's hard? What skills do they need to develop for the next level? Don't rush it — each level builds on the one before.

Supporting Them Through the Transition

The IC-to-TL transition is one of the hardest in an engineering career. Their identity shifts from "person who writes great code" to "person who makes the team more effective." That's disorienting.

Help them by:

Naming the tension: "It's normal to feel like you're not producing enough code. Your job is changing."
Giving them permission to say no to coding tasks that should be delegated.
Coaching them on the new skills: running meetings, giving feedback, navigating disagreements.
Celebrating their leadership wins, not just their technical wins.

When Growth Means Leaving

This is the section most managers don't want to read. But it's arguably the most important one.

Sometimes the best thing for someone's career is to leave your team. Maybe even leave your company. And supporting that transition is a mark of good leadership, not a failure.

Why This Happens

The role they want doesn't exist on your team. They want to do machine learning and you're a payments team. No amount of stretch assignments changes that.
They've outgrown the scope. Your team is five people and they need to lead a larger group to keep growing.
They need a fresh start. Sometimes a different environment, culture, or problem domain is what someone needs.
The company can't offer competitive growth. Startups can't always create staff engineer or director roles. That's reality.

How to Handle It

Don't take it personally. This is about them, not about you. If you react with hurt or guilt-tripping, you'll damage the relationship and your reputation.

Have the honest conversation. If you can see that someone has outgrown the role and you can't offer what they need, say so. "I think you're ready for more than what I can offer here. Let's talk about what that looks like." This builds enormous trust — even if they leave, they'll speak highly of you and your team.

Help with the transition. If they're moving to another team internally, make the introduction. If they're leaving the company, offer to be a reference. Write them a genuine LinkedIn recommendation. Help them think through what to look for.

Protect the team. While supporting the individual, also plan for the gap. Start cross-training. Identify who can absorb responsibilities. Don't let one person's departure create a crisis.

The counterintuitive truth is that when people know you'll support their growth even if it means losing them, they're more likely to stay. Nobody wants to work for a manager who hoards talent.

Real-World Examples

Scenario 1: The IDP That Led to a Promotion

Priya was a solid mid-level engineer. Reliable, good code quality, but she'd been at the same level for two years and was starting to get restless. Her manager, David, noticed she was disengaged in 1:1s and asked directly: "Where do you want to be in a year?"

Priya said she wanted to be a senior engineer but didn't feel like she was making progress. David asked what she thought "senior" meant. She said "writing harder code." David pushed back gently: "At our company, senior means technical leadership and impact beyond your own work. Let's look at what that means specifically."

They built an IDP together:

Goal 1: Lead the design of the notification system rewrite. Write the RFC, run the design review, make the architectural decisions.
Goal 2: Mentor two junior engineers, with monthly check-ins to discuss their progress.
Goal 3: Present at one internal tech talk on a topic of her choice.

David's commitments: assign the notification project to Priya, pair with her on the RFC draft, give her real-time feedback after the design review, and shield her from interrupt-driven work that would fragment her focus.

They checked in monthly. After 8 months, Priya had led a successful rewrite, gotten strong feedback from the juniors she mentored, and done two tech talks (she liked it enough to do a second). When promotion time came, the case was obvious. The IDP artifacts — the RFC, the design review recording, the feedback from mentees — made the promotion packet nearly write itself.

What made it work: specificity, follow-through, and David actively creating opportunities instead of just suggesting them.

Scenario 2: The Engineer Who Stagnated

Marcus was a talented backend engineer who'd been at the same company for four years. He was consistently rated "meets expectations." His code was clean. He shipped features on time. He was pleasant to work with.

His manager, Lisa, was stretched thin — managing 12 people while also handling operational firefighting. Their 1:1s were 90% status updates. When performance reviews came around, Lisa would write "Marcus continues to be a reliable contributor" and move on.

Marcus never received a stretch assignment. He was never asked about his career goals. Nobody paired him with a mentor. When a tech lead position opened on the team, it went to a newer hire who had a manager on a different team — one who had actively positioned her for leadership.

Marcus didn't complain. He just quietly became less engaged. He stopped volunteering for new work. His contributions shrank to exactly what was assigned. Eventually he left for another company, where his new manager immediately recognized his potential and gave him ownership of a major system redesign.

Within 18 months at the new company, Marcus was promoted to senior engineer and was leading a sub-team.

The lesson isn't that Lisa was malicious. She was overwhelmed and under-resourced. But the result was the same: a talented engineer lost almost two years of growth because nobody invested in his development. And the company lost a strong engineer who could have been a leader there.

Scenario 3: The EM Who Built a Pipeline

Carmen managed a platform team of eight engineers. Over three years, four of her reports were promoted — two to senior, one to staff, and one into a management role on a different team. Two others left for TL roles at other companies (both stayed in touch and referred candidates back to Carmen's team).

Carmen's approach was systematic:

She spent the first month with each new report understanding their career goals and building an IDP.
She maintained a "growth board" — a simple spreadsheet mapping each person's development goals to available opportunities (projects, mentoring relationships, training).
She deliberately rotated project leadership. Nobody "owned" a system permanently. When a big project came up, she asked "who would grow the most from leading this?" not "who's done this before?"
She held quarterly "career conversations" that were separate from performance reviews. Different tone, different agenda. Future-focused, not backward-looking.
She explicitly sponsored her team members in leadership forums. When discussing staffing for cross-team initiatives, she'd say: "Alex is ready for this kind of challenge — here's what he's done to prepare."

When people asked Carmen how she kept losing people to promotions and transfers without her team falling apart, she said: "I'm not losing people. I'm producing leaders. And everyone who sees that pipeline wants to join my team."

She was right. Carmen's team had the highest internal application rate in the engineering org. People wanted to work for her because they knew she'd invest in them.

Common Mistakes

Treating IDPs as HR Paperwork

If you create an IDP because HR told you to, and then never look at it again, you've wasted everyone's time and actively damaged trust. The engineer did the vulnerable work of sharing their goals, and you shoved it in a drawer. Either commit to the process or don't start it.

Only Developing High Performers

It's natural to invest in the people who are already doing great work. They're exciting to develop. They make you look good. But the biggest growth ROI often comes from solid-but-stagnant performers — the Marcus story above. They have ability that's not being utilized. If you only develop your top 20%, you're leaving 80% of your team's potential on the table.

No Follow-Through

You had the growth conversation. You identified the goals. You even wrote them down. And then... nothing. No stretch assignments materialized. No check-ins happened. The engineer learned that you talk a good game but don't deliver. This is worse than never having the conversation, because now there's a broken promise.

Blocking Transfers

When a strong performer wants to move to another team, some managers panic and find ways to slow or block the transfer. "We really need you for this project." "Let's revisit this next quarter." "Are you sure you want to do that?" This is toxic behavior. It might keep them on your team for a few more months, but it guarantees they'll leave the company instead — and they'll tell everyone why.

Projecting Your Own Career Goals

Not everyone wants to be a manager. Not everyone wants to be a staff engineer. Not everyone wants to climb a ladder at all. Some people want to write great code, go home at a reasonable hour, and be really good at what they do. That's legitimate. Don't push someone toward your version of success. Ask them about theirs.

Confusing Potential with Performance

"They have so much potential" is not the same as "they are performing well." Don't hold off on development because someone isn't performing at the next level yet — that's circular reasoning. Development is what helps them get there. Also, don't promote someone based on potential alone. They need to have demonstrated the skills, even if in a limited context.

Neglecting Your Own Development

You can't pour from an empty cup. If you're not investing in your own growth — reading, attending conferences, getting coaching, having your own mentor — you'll eventually have nothing new to offer your team. Model the behavior you want to see.

The Business Value of Career Development

If you need to make the case to your leadership (or to yourself on a busy day) for why career development deserves real time and attention, here are the numbers that matter:

Retention

Replacing an engineer costs 50-200% of their annual salary when you factor in recruiting, interviewing, onboarding, and ramp-up time. The number one reason engineers leave is lack of growth opportunity. Not compensation. Not the tech stack. Growth. Every engineer you retain through genuine development investment saves the company six figures.

Internal Promotion Saves Recruiting Costs

Promoting from within costs a fraction of an external hire. The person already knows the codebase, the culture, the people, and the systems. They ramp into the new role in weeks instead of months. And they bring institutional knowledge that no external hire can match.

When you build IDPs and follow through on them, you're building a bench of people who are ready to step up when positions open. That's cheaper, faster, and lower-risk than going to market every time you need a senior engineer or tech lead.

Team Capability Growth

A team where everyone is growing is a team that can take on harder problems over time. This quarter you can handle a service migration. Next quarter, because you've been developing your people, you can handle a service migration while also redesigning the data pipeline. Your team's capacity expands not because you hired more people, but because the people you have are more capable.

This compounds. A team that grows its skills by 10-15% per year is dramatically more capable in three years. A team that stagnates still needs the same headcount to do the same work, year after year.

Succession Pipeline

What happens when your tech lead leaves? If you've been developing future leaders, the answer is "someone steps up and the team barely misses a beat." If you haven't, the answer is "three months of chaos while we scramble to hire externally."

A succession pipeline isn't just about the TL role. It's about every critical function on your team. Who else can handle incident response? Who else understands the billing system? Who else can run the design review? If the answer to any of these is "only one person," you have a development gap and a business risk.

Employer Brand

Teams known for developing people attract better candidates. Engineers talk to each other. When someone says "my manager actively invested in my career and I grew more in two years there than in five years at my previous company," that's more effective recruiting than any job posting you'll ever write.

Making It Real

Career development isn't complicated. It's just hard because it requires consistent effort, genuine care, and the discipline to follow through when you're busy — which is always.

Start here:

This week: Have a real growth conversation with one person on your team. Not a status update. A conversation about where they want to go and what they need.
This month: Build or revisit an IDP with each of your direct reports. Keep it to one page. Make the goals specific. Define your commitments.
This quarter: Identify one stretch assignment for each person. Match the stretch to their goals. Set up the support structure.
Ongoing: Follow up. Every 1:1 should touch on development, even briefly. "How's the project leadership going? What are you learning? Where do you need help?"

The best managers I've worked with all had one thing in common: their former reports spoke about them with gratitude. "She pushed me when I needed pushing." "He created opportunities I didn't know I was ready for." "She told me when it was time to move on and helped me do it."

That's the legacy worth building. Not the features you shipped or the systems you designed — the people you developed.

Common Pitfalls

Treating IDPs as HR paperwork. Creating development plans because HR requires them and then never looking at them again wastes everyone's time and actively damages trust with the engineer who shared their goals.
Only developing high performers. Investing exclusively in people who are already doing great work leaves the majority of the team's potential untapped. Solid-but-stagnant performers often have the highest growth ROI.
No follow-through on growth commitments. Having the growth conversation, identifying the goals, and then failing to create stretch assignments or check in on progress is worse than never having the conversation — it creates a broken promise.
Blocking internal transfers. Slowing or preventing a strong performer from moving to another team to protect your own headcount guarantees they will leave the company instead, and it damages your reputation as a leader who develops people.
Projecting your own career goals onto your team. Not everyone wants to be a manager or a staff engineer. Pushing someone toward your version of success instead of asking about theirs leads to disengagement and eventual departure.
Neglecting your own development. If you are not investing in your own growth — reading, attending conferences, getting coaching — you will eventually have nothing new to offer your team and will be unable to model the learning behavior you expect from them.

Key Takeaways

Career development is core to the EM role, not a side task. You are the single biggest influence on whether your team members grow or stagnate.
IDPs work when they are specific, collaboratively built, revisited regularly, and backed by concrete actions — not when they are vague aspirational documents filed away and forgotten.
Growth conversations should happen at least quarterly, focused entirely on the person's trajectory — not sprint status or project updates.
Stretch assignments are the primary mechanism for growth. Design them in the learning zone between comfort and panic, with clear guardrails and active support.
Sponsorship — advocating for people in rooms they are not in — accelerates careers more than mentoring alone. Be deliberate about who you sponsor and check for bias.
Supporting someone's growth sometimes means helping them leave your team or even your company. Managers who hoard talent end up losing it entirely.
Investing in career development is one of the highest-ROI activities available: it drives retention, builds internal promotion pipelines, expands team capability, and strengthens your employer brand.
The best managers are remembered not for the features they shipped but for the people they developed.