Should you become an engineering manager?

It wasn't a conscious decision when I became an engineering manager ages ago. I was a tech lead in a growing project, so we started hiring frantically, and I got in charge of new responsibilities like interviewing, onboarding, and then managing. Those responsibilities made me stop coding as a primary function. Then my boss said, “I guess you are the engineering manager now.”

At that time, I was happy because transitioning from senior engineer to engineering manager was the only career progression path for most companies.

Fortunately, the tech industry moved on from this idea. The Staff Engineer role is now a possibility even in smaller companies. So there comes a time in the ambitious senior engineer’s career when they ask themselves:

Should I become a Staff Engineer or an Engineering Manager?

People mostly decide on the former. Staying technical and avoiding bureaucracy at all costs are the main reasons the best engineers call themselves “hackers.” I had trouble promoting people to manager internally due to a lack of interest in the role, while no senior ever refused a promotion to become staff.

Most engineers prefer going into staff because they think it is a role where they can stay technical, avoid meetings, and continue coding. They believe being promoted to the manager role would require someone to give every piece of expertise acquired so far and quit being technical entirely.

However, being an engineering manager is not as dull as it seems. Most of your technical skills won't go to waste. Being a manager allows you to use your learning to develop new skills.

But why do we need managers, anyway?

Some argue that teams do not need a manager at all. While that may be true briefly, if you assemble a team of staff-level engineers for a small project, you can quickly ship without issues. However, it becomes chaotic once the product becomes more complex and more people are involved.

Even in some companies like Valve, which claim to have no managers, people act in lead roles — they are just not permanent.

Having a manager means one person attending meetings representing the technical team instead of six, one person removing uncertainty with product stakeholders by pushing back crazy demands, someone looking at tech debt going too large, and in charge of hiring great team members to scale the team.

The good

The best thing about being an engineering manager is that you are a force multiplier for the team. A good manager balances responsibilities and fills in the team's gaps so engineers can focus on what they know best.

The flexibility of the role ensures that you'll rarely find yourself bored. One week, you might focus on tackling tech debt, while the next week, you could be responsible for hiring. Once things settle down, you can contribute by enhancing the CI/CD process, helping engineers to ship with greater confidence.

Ideally, you should not work too long in just one area if you want to succeed. Work requiring constant attention must be handed off as you scale your product. For example, I sometimes wear the PM hat if my PM is too busy, but if they are busy 100% of the time, it is time to look into hiring. This can also happen when the EM does DevOps or QA.

Product Impact

You will significantly impact the product's outcome. When I was a software engineer, my teammates and I often felt that the product we were building would not have any impact, and we were correct most of the time. Other times, we followed a process we knew was a huge time waster for us and the company. This led to a lot of stress and the best engineers leaving.

In other companies where the manager backed us up, we felt that our voice was amplified and louder than the sum of its parts. We shipped great work, had a growing and healthy squad, and going to work was something we happily did.

Many times in my career, I have successfully pushed for pivoting projects into something else that brought more revenue and avoided doing something else that would take months and had no customer value.

As a manager, you will have a broader impact on every area of software development and shape the final product outcome. Your primary responsibility will be ensuring a successful delivery.

People Impact

A good manager can make a bad company tolerable, and rarely do people decide to start a long, tedious interview process if they feel they are protected during storms. There is a saying that people don’t leave their jobs; they leave their managers.

The well-being of eight hours of the engineer's day will be mostly on you. You are the difference between an anxious Sunday and a happy Monday.

If you like talking with engineers like me, managing is also a great way to get to know people and acquire people skills deeply. I always enjoy doing 1:1s and being able to help them as a manager.

You will also enjoy talking with people, becoming more of a people person, and developing many communication skills. This is especially good in a WFH environment where you don't get to talk with people often. You will meet a lot of people who have interesting hobbies and stories.

Path to entrepreneurship

If you want to start your own company, getting into engineering management is a way to acquire valuable business skills without taking on the risk of starting a company. If you have already pursued entrepreneurship, you will probably hit the ground running in this role. Starting a business will help you develop excellent management skills, and many entrepreneurs become great managers. Some companies specifically target ex-founders when they are hiring, especially when they are starting. Airbnb even has in their values "Be a “cereal” entrepreneur".

The bad

Mistakes in your team might not be your fault, but they will always be your responsibility.

If your engineer says he can ship something in 2 weeks, but it takes 2 months, it will be your responsibility to be accountable for that deadline. Another example would be if something goes wrong, like the production going offline, it will also be your responsibility to prevent it from happening again. Anything that goes wrong makes you the person accountable for preventing future errors.

That is why the engineering manager needs to be technical. Companies without technical EMs always become a mess because you cannot make hiring, estimation, engineer performance, project trade-offs, and architecture decisions if you don't know how software is done. Even in companies where you do not code, you need to keep up with the trends to stay technical.

Meetings

There will be many meetings, but you get used to them. Meetings are dreadful for engineers because they must reenter the focus zone afterward. However, as a manager, the meetings are the work we attend so the engineers can avoid them.

You will also have a say in whether to attend meetings when you think you are not critical. You have the power (and the responsibility) to make your team meetings more effective.

Should the manager still code?

You will still code, but not as much as you would like. Some days, you will want to go there to do the work yourself. Sometimes, you will also know it would be faster if you did it. Giving to that urge is the most common mistake of newer managers. Your role is not an engineering addition but a force multiplier.

Your deliveries should be outside the sprint delivery because problems may require you to deprioritize your other work to resolve them. Since multiple engineers will be coding, this can be the first thing you can drop, but if you take critical work and then drop it, you will block someone.

The Ugly

Up to senior engineer, getting promoted only depended on your skills. However, for the manager and staff role, the group needs to grow, or someone must quit. That is why moving into a growing company is necessary if you want to be a manager faster.

There are five times more open senior engineer roles than manager roles. A typical team has five engineers and one manager, reflecting the number of open positions.

Accepting an offer is a giant risk because you cannot hop companies as a software engineer can. Companies will not interview you if you stay less than a year in the last job. Some even want more!

Even if you are invited to interviews, they are also tiring. Since the roles change between companies, you will be interviewed by people who think their management style is the only way. So, if you come from a different background, they will flag you as someone who doesn't fit. As explained in the following chapters, there are ways to avoid that.

The other side of the coin

If being interviewed is draining, interviewing people is worse. This critical process cannot be reliably scaled. Generally, the manager interviews first to protect the team’s attention. On average, you interview about 15-20 people before hiring a candidate.

In some interviews, you will discover that the candidate won’t pass in the first 15 minutes (due to obvious issues like cheating) and that the next 30 minutes will be wasted.

Being accountable for decisions you didn’t make

The larger the company, the less power you have to change top-down decisions. If your "boss’s boss’s boss" enforces a bad process on the teams, you will be heavily impacted and powerless to change it.

Even if a bad decision is not your responsibility, the team will hold you accountable for fighting against it. Sometimes, you cannot overcome the decisions, but you can find clever ways to work around them to make both parties happy.

The worst thing is firing people. I have made the call several times in my career, and even in cases where people have given up on the job and are not to be trusted, it never gets easy. But there is no way around it: most people are fired because they are a net negative even after getting feedback and help to improve, requiring another engineer on your team to pick up the slack or endure stress.

Alternatives

Staff Engineer

If the problems above turn you off, consider pursuing the Staff Engineer role. However, it has even fewer open roles than the Engineering Manager position. The staff+ to engineers proportion is 10-1 rather than 5-1.

Even as a Staff Engineer, you must still focus on work other than coding. The technical chapters in this book are still worth reading, like the “Programming Pillar,” since it becomes a shared responsibility between staff and managers. Consider looking at the 1:1s and giving feedback chapters since this is something you also need to master.

The wildcard option: Product Manager

It is rare, but if you want to be less technical, consider moving into product management. The only requirement might be being in a company long enough to be trusted with a lateral move.

The proportion between openings is the same for both roles because both are needed in a team. However, I used to work on teams where the EM served as the PM because the latter was shared, so the EM must also have product skills. If Product Management interests you, read about the Product and Process chapter. The PM owns the former and the EM the latter, but both are responsible for executing well within a team.