You may be wondering why you're suddenly so unhappy. You got the new job, that's great. But there's something missing, some subtle lack of fulfillment.

When you become a manager your happiness feedback loop suddenly changes. We’re all builders at heart, there’s an innate joy in typing up some code and then seeing it run and do a thing. As an IC at any level you have much more immediate feedback loops. But when you become a manager those shift farther out, and become more indirect. My team shipped this incredible new thing that customers love and is driving mad KPI’s. But what did I do? I wasn’t the key player.

The most provocative way this gets put is learn to take credit for other people’s work but what that line is really trying to say is you have to realize that your inputs to success are now different and you have to rewire your mental feedback loops to take joy in them.

Your team shipped a great thing, well why were they working on that in the first place? It didn’t get overbuilt/underbuilt etc. A senior engineer took it upon themselves to help a junior person? Well how did they know that person even needed help, and how did the junior person feel psychologically safe to ask for help to start with. Remember, you’re switching from building current software to future software!

So you have the opportunity to become an engineering manager! That’s cool. Feels like a promotion doesn’t it? Maybe it actually is a promotion in your company - sometimes there are parallel level tracks, sometimes not. Either way - you’ll be responsible for a bunch of people, and make decisions, and oversee something important to the business. Feels good!

But wait a long second and understand one fact: being an engineering manager is not like senior engineer v2. It’s a completely different job. Most importantly: many traits that make you a good senior engineer will make you a bad manager. This cannot be overemphasized.

Story time: on my first day as a new manager I had a queue of people behind me waiting to ask me about something. There was a TPM to clarify some delivery date, there was a PM to make sure I knew the priorities for the sprint, there were a couple of engineers to ask about some technical detail or other. “Look how important I am, and now I’m a manager too. Look at all these people hanging on my every word.”  Truth was, nothing had really changed that day: this was how it had been for a while as we didn’t have a line manager. We had a director with a too-big team, so I’d kind of fallen into an organizing role.

So anyway, day one as a manager. My boss took me aside a bit later, and the first thing he said was, “that needs to stop. You are doing a Bad Job.” It had been a fair while since I’d heard that - I was very used to doing a consistently Good Job. “You’re a bottleneck. Managers fix bottlenecks. You need to fix that.” I was annoyed for two reasons: I saw immediately that he was right, and that I hadn’t figured that out myself. But sometimes we all need a little push.

Something to keep in mind. Not only is the job more ambiguous, but "achieving the next level" doesn't mean you get the next level. To be fair, this isn't always true for IC's either, but the difference is companies will generaly readily promote IC's when they've earned it. For managers there has to be a team or team of team's to manage. So you might be waiting a while.

So back to you, as a new engineering manager. Consider the following statements:

• I want to be making important technical decisions
• I want to be solving hard problems
• I love the craftsmanship of well built systems
• I get frustrated when people make avoidable mistakes
• Good software engineering fixes human error
• This company would run better if we could fix our technical debt

If you are nodding vigorously at more than one of these you might not be ready to be an engineering manager. You may never be. And that’s completely ok: companies need way more capable technical people than they need managers. And if you've gotten this far hopefully by now you realize managing isn't a more senior track, it's a parallel one. It just doesn't start as early in a career as the IC one does.

The reason you may not be ready is that it’s no longer your job to do these things. It’s your job to get other people to do them. Your job is to develop that expertise, but also to put it in its right place with the other important things: what the business needs this quarter and next, what’s slowing you down and creating frustration, who’s doing well and needs recognition, who’s struggling and needs support.

There’s a meme in our industry about “non-technical managers”. Engineers sort of sneerily laugh as they dial back the detail in their updates and explain-like-I'm-five the complex computer words. But the truth is often more complicated than that: many engineering managers are actually engineers who have gone cold turkey.

There’s a good chance they’d love to just be writing code again, because code is great: it’s very binary, it works or it doesn’t, you can feel like you’ve completed a good day’s work. That very rarely happens in management. You’re primarily dealing with people, individually and in groups, and people are qualitative, subjective, irrational and non-deterministic. Success is often measured in vibes and feels, or in group wins. Your part in the whole thing is impossible to measure other than the very occasional bit of good feedback.

So why is it important? What do good managers actually do? Simply put, they make their teams better. There is other stuff - starting to have influence around your team, making space for them to perform, making their world more predictable, bigging up their achievements. But everything comes back to them, which is how it should be - you are their combined morale and productivity.

Your first job is to not overthink things. Your second job is to just keep the plates spinning. Then dig in and figure out what needs doing. You’re going to feel compelled to take all of this action right away. To make it “your team”. To fix all of the problems you see. To finally be the manager everyone’s always wanted. Don’t. Teams are complex systems. Did you make fundamental changes to your production systems on your first day as a professional engineer? Move quickly, just figure out the lay of the land first, there’s a reason things are the way they are and it’s not always what it appears to be.

If you were already on this team prior to becoming a manager, then this is ostensibly easier. You largely know what’s going on, but you need to go find that layer around the team you may not have had as much exposure to. Spend a lot of time with your boss (your previous skip level) early on, they are your best resource. But go talk to your team's stakeholders, upstream and downstream, build out your broader picture of everything. And don’t forget your team. If you’re new to the team do the same thing, just start with your direct team first!

How Hands On Should I Be? Take 1

More than 0%, less than 100%, and then it’s up to you to figure out what best works for your team, and realize that will change (in both directions) over time. Remember, you’re a leader. No one wants to follow someone who can’t walk the walk, and if you let yourself get too rusty at the functional skills you’ll lose them with how fast our industry changes. But you also have to put time and focus into the actual leading!

There are a few great ways to stay hands on. Code things that are less on the critical path. Focus on improvements that help the rest of the team ship faster, or small “extra credit” projects that provide some incremental business value. As you scale up and it’s less and less obvious what these things are, do pair programming sessions with engineers across your teams. It’s not only going to keep you close to the code but help you build culture and learn things as well.

How Hands-On Should I Be Take 2

As a new manager, you should stop coding. Go cold turkey. It’ll feel terrible and you’ll wonder what the hell it is you do all day, but that’s not a bad thing. You can remain on code reviews if you prefer to, and you should certainly be present for software or architecture design reviews, but your role is to tiebreak. You don’t lead discussions and you shouldn’t be saying much at all.

There are two exceptions to this, and in both cases you’ll still be best served by making it your priority to find people to delegate to. It’s just you may have to hire, develop or attract them from other teams which takes longer.

1. Your team is composed of junior engineers and there is no-one you can lean on.
2. You have been made a TLM (tech lead manager), which some companies have as a kind of halfway house role. This is one of the hardest jobs in tech as it’s impossible to be consistently good at both things. Best approach is to figure it out quickly: stop coding, try to delegate effectively, get out and meet people: see if you enjoy management, or start actively avoiding parts of it. Then you’ll know.

In both cases where you are still writing code you should move yourself into an engineering support function. Improving tooling, fixing difficult bugs or things that slow the team down. Your job is not to build features. You must avoid doing things in code that are critical-path and time sensitive. The golden rule is, if you’re regularly moving or canceling 1-1s, not across what’s going on in sister teams or further across the business, or not representing your team to senior leadership because of technical deadlines, then you’re not doing a good job as a manager.

One of the many joys of being an IC is that you get to be you and that’s it. While you should be cognizant of how you interact with the people around you, your actions carry the weight of, well, you. But when you become a manager that changes. You are you, and you are the company. Your actions carry the weight of both and so you need to view them that way and always be cognizant of it.

Say there’s an initiative from senior leadership you disagree with, but it’s a hard direction they’ve taken. Perhaps something hot button like overhauling the performance review process and values. Even if you might personally disagree with it, it doesn’t matter, the company as a whole has decided which means you are behind it. We are not saying to lie, or be a “company man”, but to realize that it’s part of your job to support these initiatives. Think of it like code formatting or testing standards in code. Everyone might have slightly different feelings on what they should be, but once decided everyone follows them because otherwise they’d be actively working against their team.

You don't have to fully swallow your opinion either, you just have to be cognizant of how it's expressed and to whom. Your peer managers and especially your boss are much more fair game.