Making the leap from software engineer to manager feels like a natural progression. You’ve mastered the stack. You’ve crushed your tickets. You’re the person everyone goes to when the production environment is on fire and the database is screaming. So, naturally, the next step is a title change and a seat at the planning table, right?
Not exactly.
Honestly, it’s more of a career change than a promotion. You aren’t just "leveling up." You’re starting over at level one in a completely different game. Imagine spendings ten years learning to be a world-class chef only to be told your new job is to design the restaurant's supply chain and manage the waitstaff's emotional well-being. You aren't cooking anymore. That's the reality most people miss.
The Identity Crisis of the New Engineering Manager
When you're a senior dev, your value is visible. You can see it in the pull requests, the clean architecture, and the lack of bugs. You get that sweet hit of dopamine when the code compiles and the tests pass.
Then you become a manager.
Suddenly, your day is a mess of 30-minute syncs, "quick chats," and spreadsheets. You’ll finish a Tuesday at 6:00 PM feeling absolutely exhausted, but if someone asks what you actually did that day, you might struggle to name a single tangible thing. You didn't ship a feature. You didn't fix a bug. You just... talked. This lack of a "feedback loop" is what kills most transitions from software engineer to manager.
Camille Fournier, who wrote The Manager's Path, often talks about this shift in focus from the individual to the team. If you’re still trying to be the smartest person in the room or the one who writes the most elegant code, you are failing your team. Your job is now to build the machine that builds the product. If you're still tightening the screws yourself, you're just a bottleneck with a fancy title.
The "Maker vs. Manager" Schedule Conflict
Paul Graham wrote a famous essay about this years ago, and it’s still the bible for anyone making the move. Makers—engineers—need long, uninterrupted blocks of time to get into "the flow." One meeting at 2:00 PM can ruin an entire afternoon of deep work.
Managers, however, live on a schedule of blocks. Their job is to be interrupted.
When you move from software engineer to manager, you have to stop resenting interruptions. You are the "umbrella." Your job is to take the hits from upper management, product owners, and stakeholders so your team can stay in that flow state. If you’re grumpy because a junior dev asked you a question during your "coding time," you’re missing the point of your new role.
Skill Sets That Actually Matter (And The Ones That Don't)
Forget your LeetCode skills. They won't save you here.
While technical credibility is important—nobody wants to report to a manager who doesn't understand what a microservice is—it’s no longer your primary tool. You need to develop "soft skills," which is a terrible name for things that are actually incredibly hard to do well.
1. Radical Candor and Feedback
Kim Scott’s framework is basically the gold standard here. You have to care personally while challenging directly. Giving a "needs improvement" performance review is gut-wrenching the first time you do it. You’ll want to sugarcoat it. You’ll want to be liked. But if you aren't clear, you're actually being unkind to the employee by letting them fail without knowing why.
2. Managing Up and Sideways
This is the part nobody warns you about. You aren't just managing your team; you're managing your boss's expectations and negotiating with other department heads. When the marketing VP wants a feature by Friday that your team says will take three weeks, you are the one who has to have that uncomfortable conversation. It’s about trade-offs, not "no."
3. The Art of Delegation
This is the hardest habit to break. You see a bug. You know exactly which file it’s in. You could fix it in five minutes. Instead, you have to assign it to a junior dev and let them take two hours to find it. Why? Because if you fix it, you’ve robbed them of a learning opportunity and you’ve spent your time on a $50 task instead of the $500 strategic planning you should be doing.
The Myth of the "Technical Manager"
Many companies try to create a hybrid role where you spend 50% of your time coding and 50% managing. Honestly? It rarely works.
Usually, what happens is you do 100% of the management during the day and then stay up until midnight doing the coding because you don't want to let the team down. Or, you prioritize the code and your team feels neglected and rudderless. Most successful transitions from software engineer to manager involve a conscious decision to let the "coding muscles" atrophy a bit to let the "people muscles" grow.
Real-World Red Flags: Should You Even Do This?
Not everyone should be a manager. In fact, many of the best engineers I know would be miserable in the role. The industry is finally starting to realize this, which is why we're seeing more "Individual Contributor" (IC) tracks that pay just as much as management roles.
You might want to stay an IC if:
- You get grumpy when you don't write code for three days.
- You find "people problems" annoying or illogical.
- You prefer being responsible only for your own output.
- You think management is just "telling people what to do."
On the flip side, you might be a great candidate for the software engineer to manager pivot if you find yourself more interested in why a project failed than how the code was written. If you naturally mentor others, or if you're the one constantly trying to improve the team's sprint process, those are the signs.
The Financial Reality
Let's talk money. In many Big Tech companies (Google, Meta, etc.), a Senior Staff Engineer earns as much as, or more than, a Director of Engineering. Don't move into management just for the paycheck. The "stress-to-dollar" ratio is often much worse in management. You move into management because you want to have a broader impact on the organization and the people in it.
Surviving the First 90 Days
If you've just accepted the role, your first three months are critical. Don't come in and try to rewrite the entire tech stack or change the team's workflow on day one.
Start with one-on-ones. And don't make them status updates—you have Jira for that. Make them about the person. What do they want to learn? What’s blocking them? What’s the one thing they’d change about the office or the codebase if they had a magic wand?
Your goal in the beginning isn't to lead; it's to listen. You're gathering data. You’re building trust. If your team doesn't trust you, it doesn't matter how good your roadmap is; they won't follow it.
📖 Related: How to put apple watch band on without breaking the connector
Common Pitfalls to Avoid
- Playing favorites: It’s easy to gravitate toward the engineers who code the way you used to. Resist that.
- The "Hero" Manager: Don't swoop in at the last minute to save a project by coding all night. It makes your team feel incompetent and teaches them that you'll always bail them out.
- Vagueness: Being a "nice" manager often leads to being a vague one. Be clear about expectations.
Actionable Steps for the Transition
If you're serious about making the move from software engineer to manager, don't wait for the title change to start practicing.
- Lead a Project: Volunteer to be the "tech lead" for a multi-week feature. This gives you a taste of the coordination, communication, and planning required without losing your IC status yet.
- Read the Classics: Get a copy of High Output Management by Andy Grove. It’s old, but it’s still the most accurate description of what the job actually entails.
- Find a Mentor: Talk to a manager you actually respect. Ask them what their worst day looks like. If their "worst day" sounds like something you’d want to help fix, you’re on the right track.
- Audit Your Time: For one week, track how much time you spend on "people" versus "code." If you hate the people part, stop now.
- Learn the Business: Start attending meetings that aren't about tech. Understand how the company makes money. Managers need to speak the language of the business, not just the language of the IDE.
The transition from software engineer to manager is a total rewrite of your professional operating system. It’s frustrating, often thankless, and requires a level of emotional labor that coding never will. But seeing a junior dev you mentored get promoted to senior? That’s a different kind of "it works!" feeling that, for some, is even better than a successful deployment.