I became an Engineering Manager at the start of covid. The company was not hiring, the role needed filling, and I was the person sat in front of them at the time. I had no real idea what the job involved or whether I would be any good at it, and I went in blind. Every time I have since asked another manager how they ended up with the title, that turns out to be the normal story rather than the unusual one. Nobody sits you down and walks you through the fork you are standing at. They just move you across it and hope for the best.
That fork is the choice between staying on the technical track as a Staff engineer, or stepping onto the management track as an Engineering Manager. Most people never treat it as a choice at all. They reach the top of the senior band, someone tells them management is what comes next, and they take it, because the alternative feels like standing still. If you are anywhere near that point in your career, I want to slow the decision down, because the framing you have been handed is wrong, and getting it wrong costs years.
Manager is not the rung above Staff engineer
The most expensive belief in our industry is that Engineering Manager sits one rung above Staff engineer on the same ladder. It does not. They are two different ladders, leaning against two different walls, and the organisation needs both climbed.
One wall is the technical one. Somebody has to hold the architecture in their head, make the calls that outlast any single project, and pull the standard of the engineering up across teams. The other wall is the human one. Somebody has to grow the people, set the direction, carry the difficult conversations, and make sure the work connects to something the business actually needs. Staff engineer is the top of the first wall. Engineering Manager is a serious rung on the second. Neither is a promotion out of the other.
Sarah Allen, a Lead Product Manager I worked with at Yelp, put the distinction in a way that stuck with me: a leader can sometimes be a manager, but being a manager does not always mean being a leader. The title is not the seniority. What you do with it is. Plenty of Staff engineers lead more people, and change more minds, than the managers around them. They just do it without anyone reporting to them.
If you take management believing it is the higher-status version of what you already do, you will spend your first year quietly resentful that the status did not arrive, and confused about why the work feels like a demotion in every way that matters to you. Better to understand the swap before you make it.
What the Staff engineer job actually is
The Staff track is where you go deeper. You are still close to the code, but the job stops being about the code you write and starts being about the decisions you shape. My own frame for how you get there, and what the role then asks of you, is impact and visibility. Impact is tied to vision, to taking a birds eye view across team boundaries and solving the problems that no single team owns. Visibility is who outside your immediate team knows that work is happening and trusts your judgement on it.
The manager voice for this role is one I have used with senior engineers many times. As a Staff engineer I need you to be always taking a birds eye view. I need you to see the problem two teams over before it lands on us, and to have the standing to walk into that team and be listened to.
The reward is depth. You get to stay in the craft, keep your hands near the system, and lead through the quality of your thinking rather than through an org chart. The feedback loop is fast and concrete. The design got better. The proposal was accepted. The system held under load. You can often see the result of your work the same week you did it.
The trade is that you lead without authority. You cannot make anyone do anything. Everything moves through influence, through being right often enough that people come to you, and through the patience to bring others along rather than overrule them. If that sounds like freedom, this may be your wall. If it sounds like being responsible for outcomes you cannot directly control, wait for the next section, because management is that feeling turned up to eleven.
What the Engineering Manager job actually is
I am certainly not the best Software Engineer on my team, or on any team I have managed. I am proud of that. It took me a while to be able to say it without flinching, because everything in an engineer’s career up to that point rewards being the person with the answer. The manager job quietly removes that reward and hands you a different one.
The work is people. In my experience most problems on a software team are people problems wearing a technical costume, and almost none of them are solved by you writing better code. They are solved in a one to one where someone finally tells you what is actually going on. They are solved by noticing that your quietest engineer has stopped pushing back in reviews, and asking why before it becomes a resignation. Meetings are not the interruption to the work. For a manager, the meetings are the work.
You stop being the doer and become the enabler. Your output is your team’s output, which means on your best days you produce nothing you can point to and take home. A career conversation that leaves someone energised is a good day. Shielding the team from a change of plan so they never feel the churn is a good day. Getting an engineer promoted is a very good day, and most of that work happens in a room they are not in. When I go to promote someone, I want the other managers in the calibration to question why we had not done it already, and not be having to convince them. That case is built quietly over months, and the person it is built for rarely sees it happen.
The feedback loop is slow, and this is the part nobody warns you about. You can go a whole quarter without knowing whether you did the job well. The results of good management show up as things that did not go wrong, and you cannot celebrate an absence. This is hard for everyone who makes the move, so if it feels disorienting, that is the job announcing itself, not you failing at it.
The reasons people choose management, and why most of them do not hold
Ask people why they moved into management and you tend to get the same handful of answers. It pays more. It is the next step. Someone left and the team needed a manager. I wanted more influence over the direction. Every one of those is a real reason to be in the room, and not one of them tells you whether you will like the actual work once you get there.
The money reason is the weakest. In a lot of companies now the Staff and Principal track pays comparably to management precisely so that good engineers are not forced to stop engineering to earn more. If money is the whole argument, check the ladder at your own company before you make an irreversible choice on a false premise.
The next step reason is the one I fell for by default, because I was moved into it rather than choosing it. That is not a rare accident. Research from the Chartered Management Institute with YouGov found that 82% of people entering management do so with no formal management or leadership training first (source). Most managers are not chosen for the job. They are the person who was there when the seat opened. If that is the whole reason you are considering it, you are not choosing management, you are letting a vacancy choose for you.
Then there is the comfortable lie that you will still get to code. You will, for a bit, and then you will not, and the ones who cannot let go end up doing two jobs badly and burning out. If keeping your hands in the codebase is non negotiable for you, that is not a flaw. It is a signal, and it is pointing at the Staff track.
How to tell which one is actually you
Frameworks will not make this call for you. Your own energy will. Pay attention to which parts of your current week you look forward to and which you quietly reschedule.
A few honest questions to sit with:
- When you solve a hard technical problem, is the satisfaction bigger than when you help someone else solve theirs? Or has that started to reverse?
- Does a day of back to back conversations leave you drained, or leave you feeling like you did something that mattered?
- When your best engineer succeeds, are you glad for them, or is there a small part of you that wishes it had been your code?
- Do you want to be the person with the answer, or the person who builds a team full of people with better answers than yours?
There are no wrong answers. There is only your answer, and the cost of pretending it is something else for the sake of a title. If you find yourself leaning toward the people side, it is worth understanding what kind of manager you would be before you commit, because there is more than one, and they are not interchangeable. I have written about the five types of engineering manager elsewhere, and you can get a quick read on where you would naturally sit with the engineering manager type quiz. Neither of those decides it for you either. They just make the shape of the choice clearer.
You are allowed to change your mind
The fork feels permanent when you are stood at it. It is not a one way door. I know people who managed for three years, missed the craft, and went back to a Staff role stronger for having seen the org from the other side. I know engineers who swore they would never manage, tried it in a crisis, and found the work they had been looking for the whole time.
You will not get this decision perfectly right the first time, because you cannot fully know a job you have not done. What you can do is make the choice deliberately rather than by drift, know which job you are actually signing up for, and give yourself permission to correct course if the reality does not match. If you do lean into management, the first stretch is its own particular challenge, and I have written a guide to surviving your first 90 days as an engineering manager for exactly that moment.
Final Thoughts
I want to leave you with the thing that surprised me most when I looked into it. There is a paper by Lazear, Shaw and Stanton called The Value of Bosses (source) which found that replacing a bottom performing boss with a top performing one raises a team’s total output by more than adding an extra engineer to a team of nine would. Read that again. A good manager is worth more than another pair of hands on the keyboard. Whatever else you take from this, do not walk into management believing it is the softer or lesser path. Done well, it is one of the most valuable jobs in the building.
That is also the honest catch. Done badly, it is one of the most damaging, and far more people do it badly than admit it. Which is the strongest argument I have for slowing the decision down. Do not take the job because it was offered, or because it pays a little more, or because staying put felt like failing. Take it because the work described above is the work you actually want to do. And if it is not, be proud to stay on the wall you were already climbing.
If you have worked through that and the management side is the one you want, the practical version of what happens next is here: how to become an engineering manager, covering how the promotion decision actually gets made and what the interview is testing.
I would like to hear how you came to your own fork, especially if you crossed it and crossed back. Please do send those stories my way.
