My manager offered me a promotion to team lead twice before I said yes. Twice I turned it down.
I liked writing code. I liked owning a system end to end, watching a design turn into a working thing, and fixing it myself when it broke at 2am. Management looked like a demotion in disguise: less building, more meetings, and a calendar full of other people's problems.
I said yes the third time, mostly out of guilt. I figured I would hate it and go back to an individual contributor role within a year.
This is not what happened.
Why Engineers Say No
Ask any group of senior developers if they want to manage people and watch the room go quiet. Most have a reason ready, and it usually falls into one of two buckets.
The first is identity. Your title is Software Engineer. Your value comes from what you ship. Give it up and who are you?
The second is money. Somewhere along the way, engineers absorbed one idea: management is the only path to a bigger paycheck. It is not. At companies which have invested in a real dual-ladder structure, like Stripe, Anthropic, and Databricks, the individual contributor and management tracks pay roughly the same through the senior levels. A Staff Engineer sits at the same level as a Manager. A Principal Engineer sits with a Director. The ladders run in parallel, not one above the other.
So if it is not the money, the resistance is almost always about identity. Mine was.
Nobody Tells You It Is a Different Job
I assumed management was a senior version of engineering. More scope, more say, same skill set with extra steps. I was wrong in a way which embarrassed me for months.
The Pragmatic Engineer newsletter describes the individual-contributor-to-manager shift as learning an entirely different job, not a continuation of the old one. Engineering managers work across four dimensions: technology strategy, business impact, process and delivery, and people. As an engineer, I had been excellent at one of those four. As a new manager, I was a beginner at three of them, on day one, in front of the same people who used to come to me for answers.
My first 1:1 was a disaster. I had spent a decade solving problems for a living, so I tried to solve my direct report's problem in the first five minutes. He did not want a solution. He wanted to be heard. I did not know the difference yet.
What Changed My Mind
There was no single dramatic moment. It built up over about six months, one small win at a time.
The first was a direct report who had been stuck on the same architectural decision for weeks. I did not touch the code. I asked four questions, listened to the answers, and watched him land on the solution himself. He looked prouder of this moment than I ever felt shipping a feature solo.
The second was watching someone I had coached through a rough patch turn into the strongest engineer on the team a year later, and knowing I had a small part in it.
People are messier than code. Code does what you tell it. People bring context, mood, history, and ego to every conversation, and none of it shows up in a stack trace. I used to see this as a downside. Somewhere in my first year as a manager, it became the part of the job I looked forward to most. I went from thinking people are complicated to feeling more engaged by this complexity than I ever was by a clean pull request.
What I Lost, and What Nobody Warns You About
I want to be honest about the cost, because most articles on this topic skip it.
I stopped being the person with the deepest technical answer in the room. Within two years, engineers I managed knew parts of our system better than I did, and this was correct and healthy, not a failure on my part. I had to make peace with being useful in a different way: unblocking people, protecting their time, and making decisions about priorities instead of implementation details.
I also lost the immediate feedback loop of writing code. A pull request tells you within minutes whether it works. A management decision, like how you handle a tense performance conversation or how you structure a team, sometimes takes a year to show whether it was right. This delay was the hardest adjustment. Engineers are trained on fast feedback. Management runs on slow feedback, and you have to learn to sit with the uncertainty in between.
The trade-off is not automatically worth it for everyone, and it should not be. Some of the best engineers I have worked with tried management for a year, decided the slow feedback loop and the loss of hands-on building were not worth the parts they gained, and moved back to a staff engineer role on purpose. This is not settling. This is knowing yourself.
The Fork Is Not Permanent
If you are standing where I stood, here is the part nobody tells you: the decision is reversible.
Switching back from management to an individual contributor role is realistic within about 18 months of making the jump, according to career-track research on the IC vs management path. Wait three years or more and you will need to rebuild your technical credibility, but it is still recoverable. This is not a one-way door. It is a fork you get to test.
I have watched two people on my own teams take the management role, hate it, and go back to being individual contributors with zero stigma attached. Both are now among the strongest senior engineers I know. Neither regrets trying.
If You Are Standing At The Fork Right Now
A few things I wish someone had told me before I said yes the third time.
- Shadow a 1:1 with an existing manager before you decide. Watch what the job looks like on a random Tuesday, not the highlight reel version.
- Do not decide based on pay. If your company has a real dual ladder, the money is not the differentiator. Your interest in people is.
- Expect to be a beginner again. You will be bad at this for a while, the same way you were bad at your first pull request.
- Ask for feedback early, and ask for it from the people who report to you, not only your boss. New managers develop blind spots fast, because the people who see those blind spots most clearly are the ones least likely to volunteer the feedback. This is exactly the gap tools like BAT were built to close, by collecting honest input from the team a manager leads, not only the view from above.
The Question Worth Asking Yourself
I resisted becoming a manager because I thought I was giving something up. I was right about this part. I gave up the daily rush of shipping code myself. I did not expect to gain something I would value more: watching someone else grow because I showed up for them.
If you are turning down this promotion, ask yourself honestly which fear is driving it. Are you protecting an identity built around your code, or have you tested the actual work of managing people and found you genuinely prefer building things yourself? These are two different reasons to say no, and only one holds up once you have tried the job.