My wife recently took a management position for the first time. While my first management role was much different in many ways (I was with a small startup, and she works for a state healthcare system), her mixed feelings reminded me of the roller-coaster ride I felt when I was first put in charge of a team of engineers.

On the one hand, I was excited. This was an opportunity to make a bigger impact on the organization and my teammates’ careers.

On the other hand, I was scared. Many people on the team were older and more experienced, and it felt like my whole career was riding on my performance in that first year. To add to the nervousness, there wasn’t any formal management training or in-house mentorship program because the company was so small. Like most new managers, I figured most things out the hard way, but it took me at least a year to feel comfortable in the new role.

The reality is that moving from an individual contributor (IC) role to a management one is hard, and it requires you to make sacrifices and step outside your comfort zone. There’s a reason that some engineers hesitate to accept or pursue management roles, even when part of them wants that role. In this post, I’ll explore what you give up when you move into engineering management. In addition to my own experience, I’ve included input from a few other professionals who have undergone this transition.

If you’re considering a management path, use this as an opportunity to take stock of your skills and strengths to make sure you’re not giving up everything you love about software development just to be in charge.

Why is the transition to management so hard?

Adjusting to management is difficult because the skills and metrics required for management success are completely different from those for individual contributors.

“Successful people become great leaders when they learn to shift the focus from themselves to others.” – Marshall Goldsmith, What Got You Here Won’t Get You There

As a leader, you’re no longer expected to write the most code, solve the hardest technical problems, or fix the trickiest bugs. Instead, you’re responsible for ensuring that your team can do these things. It’s hard for great engineers to move into management because they like being deeply focused on challenging technical problems, not hopping in and out of a dozen meetings every day.

I’m part of a CTO group in Chicago, and one of the most common challenges we discuss is how to let go of our technical responsibilities and embrace the people-focused roles we now have. Many group members struggle with this because they built the early version of their app single-handedly. It’s tough to let a bunch of other engineers with different backgrounds, opinions, and skill levels jump in and start messing with your codebase.

But as you’ll see, giving things up is an essential part of becoming a manager.

What engineers give up by becoming managers

Far too many engineers take a management role without understanding the tradeoffs, and many end up unhappy because of it. If you want to become a manager, be aware that you’ll have to forgo some of what you probably like most about your field.

1. Focus time

Because context switching is so costly, most engineers crave focus time. Zeke Nierenberg, a former CTO who transitioned back to an individual contributor role last year, told me that giving up this focus time was a huge sacrifice: “When you’re in a management role, you need to prioritize high availability. For me, that meant that my day (and mind) became profoundly fragmented.”

I felt the same way when I was an engineering manager. I enjoyed spending hours lost in a tough problem and coming out the other side with a complete solution. Unfortunately, I also needed to unblock my team so that progress wouldn’t grind to a halt whenever I decided to work on a new feature. Eventually, I figured out that I couldn’t take on projects in the “critical path,” so I’d only work on low-priority or experimental features if I had time.

While managers can (and should) carve out time to do focused work, doing so becomes increasingly difficult as your team grows. Not only do engineers on the team have more questions for you, but so do external stakeholders. As the team’s manager, you need to be the first line of defense so that minute questions don’t interrupt your team’s workflow.

2. Short feedback cycles

I still love the magic of writing code and quickly seeing changes on a website being used by thousands of people. This instant feedback cycle was one of the reasons I enjoyed learning to code, and its absence is one of the biggest differences you’ll see as a leader. Management doesn’t yield instantaneous results; that would be like planting an apple seed and expecting fruit the next day.

“In management, you may give some advice to your team or implement a new policy that will take weeks to surface as good or bad. The feedback loop on management is far longer than that of an individual contributor.” – Tyler Jefford, Engineering Manager at Venmo

Gergely Orosz reiterates this point and cites long feedback cycles as the reason he came up with this checklist for first-time engineering managers unsure of how to measure their success in the new role:

“When you’re an engineer, you get feedback on your code, on your design documents, or how your projects are going. As a manager, you have none of this. There are also often no clear and specific expectations of what you should be doing in this role.”

“Success” is also a lot murkier as a manager. Anthony Garone, a former Engineering Director at Allstate, pointed out that managers rarely get the satisfaction of solving tactical problems every day: “Leadership is all about handling ambiguity and creating long-term gains, which often go unrecognized.”

3. Conflict avoidance

As an individual contributor, you might look at a colleague who’s not pulling their weight and think, “I really wish I could fire that person,” but let me tell you, it’s not fun. As a manager, you are the one who has to actually deliver that bad news.

I will never forget the first time I had to put someone on an improvement plan and eventually let them go. I put the decision off for weeks, trying to find ways that the employee was improving so that I could justify keeping them. Eventually, my boss had enough, and I had to let them go. It was the most difficult conversation I’ve ever had.

Nierenberg pointed out that having difficult conversations is a huge part of being a manager. “They don’t happen every day, but there are moments that are profoundly consequential,” he told me. “What you say in those moments can have more impact than ten sprints.”

And not all of these difficult conversations are about work performance either. While some work environments are more drama-free than others, Jefford pointed out that professional relationships are often quite subtle and nuanced: “You might have someone closed off because they are mad at you or another person on the team; or you may have someone crying in your office because of something going on in their life that isn’t about work at all.”

At the same time, if you’re willing to lean into these interpersonal issues, you might enjoy this part of management. Jefford noted that because people are so dynamic and diverse, no “management formula” always works. There’s always something new to learn.

4. Making technical decisions

Many engineering leaders are promoted to management positions after they demonstrate a certain level of technical expertise. The problem is that managers should not be the ones making the difficult technical decisions, especially if they want their teammates to grow and stick around.

“I struggled with letting tech things go. In the first several months [as a manager], I found myself wanting to look at PRs and have my team walk me through the code being pushed. I wanted to make decisions on method names and architecture.” – Tyler Jefford

If you keep thinking of the code as “yours” after moving into management, you’ll prevent others on the team from taking ownership of it. This will be extremely demoralizing and frustrating for your team, as anyone who’s had a micromanaging boss can tell you.

Igor Khoroshilov, VP of Engineering at SOCi, told me that the solution is to think differently about your role: “Your product as a manager is people. Your main goal is to scale through developing your team and setting them up for success when solving problems.”

But for many engineers, it’s not easy to make this mental shift. Making technical decisions is interesting, fun, and (for many) comfortable. Sitting back and allowing other engineers to make changes to the code that you might think are inferior to the changes you would make isn’t comfortable, but it is necessary.

5. Learning new technical skills

Finally, moving into management means that you’ll have less time to devote to acquiring new tech skills. If you are a new manager and you only have so many hours per week to devote to learning new things, it’s unlikely you’ll be able to spend many of them on technical topics.

“Though some engineering managers remain pretty hands-on, many do not continue to code. Even if you continue to code, you’ll most likely be expected to spend a lot more time conducting one-on-ones with your team members, holding meetings with product managers, and interviewing potential engineering candidates…Engineers who pride themselves on the depth of their technical expertise may find this especially challenging.” – ​​Jennifer Fu, Codementor

I tried to stay hands-on with the latest technology for a while after being promoted to a management role. I’d spend a few hours every week on side projects so I could keep my hands on new technology or work on open-source projects with friends. But my life outside of work got more complicated as I entered my 30s. I got married, got a dog, and had a baby. Eventually, I had to let go of coding on nights and weekends.

As an engineering manager, you should see the broader technology trends in your industry and understand the tradeoffs of different solutions. You should be able to hop into the codebase and lend a hand, but you won’t be able to get hands-on with every new framework and tool your team wants to try.

What if you don’t like the tradeoffs you made?

If you take a management role and it turns out that it’s not for you, don’t worry. I’ve known many engineers who moved into management and then back into individual contributor roles without much resistance.

“Anyone can be a leader, even without the title,” Jefford told me. Informal leaders might be just as important to a team’s success as the manager. There are also hybrid roles (e.g., “lead engineer” or “team lead”) at many companies that come with a mix of management and hands-on responsibilities.

On the other hand, maybe you just need more mentorship, training, or coaching. Assuming there are aspects of your management role that you enjoy and feel confident in, it might be worth talking through your challenges with somebody, whether that’s a professional coach, a mentor, or just a friend with a fresh perspective.

If you’re at a large organization, you might have access to in-house management training or mentorship programs, but it’s also helpful to have objective outside resources as well. “You need someone outside of the company to talk to,” Nierenberg told me. “You have blind spots, and a coach can be a side-mirror.”

It took me at least a year to feel comfortable in my first management role, but I’m glad I stuck it out. Stepping into a management role has allowed me to make a larger impact on my company and team. Helping other engineers develop in their careers is easily as rewarding as checking in a few hundred new lines of code, and it’s opened up whole new career opportunities as well.

If you’ve made the transition into engineering management and you have something to share, I’d love to hear it. Leave a comment below or find me on Twitter to continue the conversation.

Tags: career development, management