Should you become a manager? I get this question from senior developers more than almost any other career question, and my honest answer is: it depends on what you’re willing to give up.
I made the jump from individual contributor to manager, and the thing that surprised me most wasn’t the new responsibilities. It was the grief. I genuinely missed writing code for a long time. The deep focus, the flow state, the dopamine hit of watching tests go green — all of that gets replaced by meetings, one-on-ones, and a calendar that looks like a game of Tetris someone already lost.
If you’re weighing this decision, here’s what I wish someone had told me.
It’s Not a Promotion. It’s a Career Change.
Charity Majors wrote one of the best pieces I’ve read on this topic. Her core argument: management is not a promotion. It’s a change of profession. You will be bad at it for a while, and if you don’t think you’re bad at it, you probably aren’t doing the job.
That tracked with my experience. I spent my first months as a manager still trying to be the best coder on the team. I’d jump into pull requests, rewrite things that were fine, and then wonder why my engineers seemed hesitant to take ownership. I was doing additive work when my job had become multiplicative.
I wrote about this in my post on what management actually is: a manager’s job is to get better outcomes from a group of people working together. Your role is to improve purpose, people, and process — not to be the best individual performer. That’s a fundamentally different way of measuring your value, and it took me longer than I’d like to admit to internalize it.
What Actually Changes Day to Day
The two biggest shifts nobody prepared me for:
You lose flow state. As a developer, I could block off three hours and disappear into a problem. As a manager, my job is to be interruptible. Charity Majors nails this: “Management is highly interruptive, and great engineering requires blocking out interruptions. You can’t do these two opposite things at once.” This isn’t a scheduling problem you can optimize away. It’s a fundamental change in how your days feel.
Your wins become invisible. When I shipped a feature, the result was concrete. I could point at it. When I helped an engineer work through a difficult technical decision, coached someone through a tough conversation with a stakeholder, or restructured a team’s process so they stopped missing deadlines — those wins were real, but nobody outside the team saw them. If you need visible, tangible output to feel good about your work, management will test you.
On the other hand, some things got better. I started understanding how the business actually worked. I learned why certain decisions were made three levels above me that had previously seemed arbitrary. I got better at reading people and navigating conflict, skills that turned out to be useful everywhere, not just at work.
The Skills That Surprised Me
Everyone told me I’d need to learn delegation and time management. Those are real, but they weren’t the hard part. The skills that actually made the difference were ones I didn’t expect.
The first was asking questions instead of giving answers. My instinct as a senior developer was to solve problems. My job as a manager was to help my team solve problems. That sounds like a small distinction, but it changes almost every interaction. Instead of reviewing a design and saying “here’s what I’d do,” I had to learn to ask “what options did you consider, and what made you choose this one?” It’s slower, and in the early days it felt painfully inefficient. But the team grew faster.
The second was having uncomfortable conversations early. Performance issues, interpersonal friction, misaligned expectations — as a developer, I could ignore these. As a manager, I was the one people looked to for resolution. I learned, mostly through getting it wrong a few times, that having a direct conversation in week one is always better than letting something fester for a month.
The third was knowing when to shield and when to expose. Your team doesn’t need to hear about every reorg rumor or leadership disagreement. But they absolutely need to understand the business context behind their work and the constraints they’re operating within. Finding that line is a judgment call you make every day, and I still don’t always get it right.
When to Say No
Not every senior developer should become a manager, and not every one should do it right now.
If you’re drawn to management primarily because it seems like the only way to advance or earn more, pause. Many companies now have staff and principal engineer tracks that pay equivalently. Will Larson’s Staff Engineer laid out how IC leadership at the senior level carries enormous organizational influence. You can mentor, shape architecture, and drive strategy without managing anyone.
If you genuinely love the craft of writing software and dread the idea of giving it up, listen to that instinct. Some of the most impactful people I’ve worked with were senior ICs who chose to stay technical. They weren’t “just” coders. They were the people who set technical direction, mentored whole teams through their code reviews, and made architectural decisions that shaped products for years.
And if you do step into management and realize it’s not for you, that’s fine too. This doesn’t have to be a one-way door. Charity Majors advocates for what she calls the engineer/manager pendulum: moving back and forth between roles over the course of a career. The best frontline managers, she argues, are the ones who are never more than two or three years removed from hands-on work. And the best senior ICs are the ones who have done time in management, because they understand how people and organizations work.
If You Do Make the Jump
A few things that helped me:
Read The Manager’s Path by Camille Fournier before your first day. It’s the most practical book I’ve found on what the transition actually looks like, chapter by chapter, from tech lead to director.
Find a manager you trust and ask them what their worst first-year mistake was. Every experienced manager has one. Hearing theirs will make you a little less terrified of making your own.
Protect your one-on-ones. It’s tempting to cancel them when the calendar fills up. Don’t. Those 30-minute conversations are where you’ll learn what’s actually happening on your team. They are arguably the most important thing on your calendar.
Accept that your technical skills will atrophy, and decide in advance how you’ll stay grounded. For me, that meant keeping a small side project and doing occasional code reviews — enough to stay literate, not enough to compete with my team.
Resources
- The Engineer/Manager Pendulum by Charity Majors
- The Manager’s Path by Camille Fournier
- An Elegant Puzzle: Systems of Engineering Management by Will Larson
- Staff Engineer: Leadership Beyond the Management Track by Will Larson
- What is Management? — my earlier post on additive vs. multiplicative leadership
Leave a Reply