From Developer to Engineering Manager: A Two-Stage Path
Navigating the shift from code to leadership with a two-step plan
The following is a guest post by . I invited him to share his thoughts on transitioning from an IC to a management role. He has extensive experience as an engineering leader. And I’ve enjoyed his previous blog posts on leadership.
Tech companies are adapting to new realities. Engineering teams are getting bigger, managers are handling more reports, and AI is reshaping how we write code. A decade or two ago, we debated if developers needed to know how to implement binary tree traversal algorithms. Now we're wondering if they'll need to write basic CRUD APIs from scratch at all.
This environment creates an interesting opportunity: while routine coding tasks might be automated, the need for technical leadership is growing. Someone needs to architect systems, mentor teams, support people in their careers, and ensure we're building the right things the right way.
Before getting into the details, check your motivations. Does leading people excite you? Are you considering this path because of more money, or out of necessity to stay relevant? Make sure you're familiar with the downsides too to avoid a fast track to burnout.
I've seen many engineers navigate this transition successfully - and others who struggled. One path I found to be working is taking a deliberate, two-stage approach: first growing into purely technical leadership, then moving towards people management. While some skip the Technical Lead role, spreading the learning curve over time can make the transition more manageable.
Stage 1: Growing into Technical Leadership
Growing technical leadership skills is safer than jumping straight to management - these skills are valuable whether you end up as a Staff Engineer or an Engineering Manager. Here are key areas to develop while in your current role:
Widened Technical Scope
Increase your knowledge surface area. If you're working on the frontend, look for ways to increase your backend knowledge: pair with an engineer to implement an API for a feature you're using – it'll be a great knowledge-share exercise for both of you.
Technical Leadership
Start thinking about system-wide technical decisions. Write RFCs and architectural decision records (ADRs) to propose improvements. Instead of jumping into a refactor or asking for quick opinions during lunch, write a proposal and reach out to stakeholders. Learn to pragmatically balance immediate needs with long-term health - understand why sometimes the team needs to grow tech debt to ship urgent features.
Project Management
Take full ownership of projects end-to-end. Break down work, identify dependencies, track progress, demo completion, and handle follow-up. Even if you're not delegating yet, this mindset switch of organizing your work will be valuable when you need to do it at scale. Consider volunteering to lead one of the big features in the next sprint.
Developer Experience
Look for ways to improve how your team works. Fix flaky tests, simplify the local development setup, improve documentation of murky areas. Good technical leaders make everyone around them more productive.
Stage 2: Moving Towards Engineering Management
The jump to Engineering Manager is significant. You're impacting the work experience of people reporting to you more than ever before. Ask yourself: Do you genuinely care more about team success than personal achievements? Does helping others grow excite you more than solving technical problems?
If yes, focus on developing these skills:
People Management and Empathy
Start with informal leadership opportunities. Help onboard new team members, run team meetings, participate in hiring interviews. Learn to understand different motivations - what drives one person might demotivate another. You can do a lot without the title: mentor people, give actionable feedback, provide support when they're struggling. Growing your skills in this area can have the biggest impact on your future Engineering Manager career.
Getting Comfortable with Ambiguity
Getting comfortable with ambiguity starts with accepting longer feedback loops. As an engineer, you're used to quick validation - tests pass or fail within seconds. Management decisions can take months to prove right or wrong. Start small: document your decisions and their context, then review them quarterly. Were your assumptions correct? What would you do differently now? This reflection helps build confidence in making calls without perfect information.
Understanding Context
Practice seeing beyond the team's immediate perspective. Some processes might seem pointless until you understand their organizational purpose. Time tracking might feel bureaucratic but it's often crucial for company financial planning (for example, tracking R&D costs for tax purposes). Find time to talk with Product Managers about not just what you're building, but why. Understand who uses your code and how.
Stakeholder Communication
Practice explaining technical concepts to non-technical audiences. Build relationships with Product Managers, Designers, and Support teams. Demo your team's work during sprint reviews – or just talk about it in the break room. Understanding different perspectives helps you make better decisions for everyone.
Making the Move
Start by being explicit about your ambitions with your manager - they can be your best ally, providing challenges slightly outside your comfort zone to ensure you’re learning and growing, giving actionable feedback to your behavior, and sharing valuable context about organizational opportunities.
Remember that becoming an EM requires both you and the organization to be ready. You might have the skills but need to wait for the right opportunity. If you're considering moving companies for your first EM role, look for organizations with a track record of growing internal talent - it's rare for companies to hire first-time managers externally.
Most importantly, remember that management isn't a promotion - it's a career change. The skills that made you a great engineer won't necessarily make you a great manager. But if you genuinely care about helping others succeed, this could be the most rewarding change you'll make.
I have further articles about Individual Contributors becoming Engineering Managers if you want deeper information and more actionable tips on the topic.
A big thank you to for sharing his insights on growing into a management role. Please subscribe to his newsletter and follow him on LinkedIn.
 | A guest post by
|
True words, which I advocate for, "You can do a lot without the title: mentor people, give actionable feedback, provide support when they're struggling."
I really enjoyed this article and can relate to many of the points made. Having transitioned from engineering to Engineering Management myself, I want to emphasize that the most crucial motivation for being a successful EM is genuinely caring about your team.
In my experience, EM work is often more unpredictable than individual contributor roles. Your impact depends on your team's dynamics, which makes the work more complex. This indirect influence means that if you’re not truly motivated by a desire to support and uplift others, it can be challenging to thrive in this role.
I've seen many engineers transition into EM roles for various reasons—some seeking authority or simply wanting to step away from coding. However, those motivations alone aren’t enough to make someone a great EM. It's the commitment to fostering growth in others that truly makes a difference.
Thanks for sharing such an insightful article!