Should you become an engineering manager?

Becoming an engineering manager wasn't a conscious decision for me when it happened years ago. I was a tech lead on a growing project, and we started hiring frantically. I took on new responsibilities like interviewing, onboarding, and eventually, managing the new hires. These responsibilities meant I wasn't coding as my primary function anymore. 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 defined career progression path at most companies.

Fortunately, the tech industry has largely moved on from this approach. The Staff Engineer role is now a viable path, even in smaller companies. So, ambitious senior engineers often reach a point where they ask themselves:

Should I become a Staff Engineer or an Engineering Manager?

Most engineers lean towards the Staff role. Staying technical and avoiding bureaucracy are key reasons many engineers prefer this path. I've personally had trouble promoting engineers to manager internally due to a lack of interest, while I've never seen a senior engineer refuse a promotion to Staff.

Many engineers prefer the staff path because they believe it allows them to stay technical, avoid meetings, and keep coding. They assume becoming a manager means abandoning their hard-earned technical expertise entirely.

However, being an engineering manager isn't as dull as it might seem. Most of your technical skills won't go to waste. Being a manager allows you to leverage your background while developing entirely new skills.

But why do we need managers, anyway?

Some argue that teams don't need managers at all. While that might hold true for a short period, perhaps with a small team of very senior engineers on a simple project, it rarely lasts. It often becomes chaotic once the product grows more complex and more people get involved.

Even at companies like Valve, which famously claimed to have no managers, people naturally step into lead roles—they just aren't permanent positions.

Having a manager means one person can represent the technical team in meetings, saving valuable focus time for the rest of the engineers. A manager clarifies requirements with stakeholders, pushes back on unrealistic demands, keeps an eye on growing tech debt, and takes charge of hiring great people to scale the team.

The good

The best thing about being an engineering manager is becoming a force multiplier for your team. A good manager balances various responsibilities and fills the team's gaps, allowing engineers to focus on what they do best.

The flexibility of the role ensures you'll rarely be bored. One week, you might focus on tackling tech debt; the next, you could be spearheading the hiring process. Once things settle down, you might contribute by improving the CI/CD pipeline, helping engineers ship code with greater confidence.

Ideally, to succeed and scale effectively, you shouldn't stay bogged down in one specific area for too long. Work requiring constant attention should be delegated as your team and product grow. For example, I sometimes wear the Product Manager hat if my PM is overloaded, but if they're consistently swamped, it's a sign we need to address the resourcing, perhaps by hiring another PM or adjusting responsibilities. The same applies if the EM is constantly filling in for DevOps or QA roles.

Product Impact

You'll have a significant influence on the product's outcome. When I was a software engineer, my teammates and I often felt the products we were building wouldn't have much impact—and often, we were right. Other times, we followed processes we knew were huge time-wasters for both us and the company. This led to stress and sometimes caused the best engineers to leave.

In contrast, at companies where our manager backed us up, we felt our collective voice was amplified and actually heard. We shipped great work, had a growing and healthy team, and going to work was enjoyable.

Many times in my career as a manager, I've successfully pushed for pivoting projects towards approaches that brought more revenue or prevented initiatives that would have taken months with little customer value.

As a manager, you gain a broader perspective, allowing you to influence software development practices and ultimately shape the product. Your primary responsibility becomes ensuring successful delivery.

People Impact

A good manager can make even a challenging company environment tolerable. People rarely decide to endure a long, tedious job search if they feel supported by their manager. There's a common saying: people don’t leave companies; they leave managers.

The well-being of your engineers during their workday rests heavily on you. You can be the difference between an anxious Sunday night and a motivated Monday morning.

If you enjoy connecting with engineers, management provides ample opportunity through things like 1:1s. It's a role where you naturally develop stronger communication and people skills, getting to know diverse individuals with interesting stories and hobbies. This is especially valuable in remote work environments where casual interactions are less frequent.

Path to entrepreneurship

If you dream of starting your own company, engineering management offers a way to acquire valuable business skills without the immediate financial risk of launching a startup. If you've already pursued entrepreneurship, you'll likely hit the ground running as an EM. Experience starting a business often translates into excellent management skills, which is why many entrepreneurs transition successfully into EM roles. Some companies, especially early-stage startups, specifically target ex-founders when hiring. Airbnb even includes "Be a 'Cereal' Entrepreneur" in its values.

The bad

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

If an engineer estimates a task will take two weeks, but it ends up taking two months, it falls on you to manage the missed deadline and its consequences. If production goes down, it's your responsibility to ensure it doesn't happen again. Ultimately, when things go wrong, you are accountable for learning from them and preventing recurrence.

That's why engineering managers need to be technical. Teams led by non-technical EMs often struggle because you simply can't make informed decisions about hiring, estimation, performance, project trade-offs, or architecture if you don't understand how software is built. Even if your role doesn't involve coding, you need to keep up with industry trends to maintain your technical grounding.

Meetings

Yes, there will be many meetings, but you get used to them. Meetings can be disruptive for engineers because they break focus time. However, as a manager, attending these meetings is often the work—you're there so your engineers don't have to be.

You'll also have more control over which meetings you attend, declining those where you aren't critical. Crucially, you have the power (and the responsibility) to make your team's own meetings more effective and worthwhile.

Should the manager still code?

You might still code, but probably not as much as you'd like. Some days, you'll desperately want to jump in and do the work yourself, especially when you know it would be faster. Giving in to that urge is one of the most common mistakes new managers make. Remember, your role is to be a force multiplier, not just another individual contributor.

Your coding contributions should ideally be outside the critical path. Urgent issues might require you to drop your coding work unexpectedly. Your coding tasks should be the first thing you deprioritize when needed. If you take on critical-path work and then get pulled away, you risk blocking your team.

The Ugly

Up to the senior engineer level, promotions primarily depend on your individual skills. However, getting promoted to manager or staff roles often depends on organizational factors, like the team growing or an existing leader leaving. That's why joining a growing company can be advantageous if you want to become a manager faster.

There are roughly five times as many open senior engineer roles as there are engineering manager roles. A typical team structure of five engineers to one manager reflects this reality in the job market.

Accepting a management offer is often a bigger commitment than taking an engineering role. You generally can't hop between companies as easily as a software engineer might. Many companies hesitate to interview management candidates with very short tenures (less than a year or even two) on their resumes.

Even when you do get interviews, they can be tiring. Management roles and expectations vary significantly between companies. You'll encounter interviewers with strong, sometimes rigid, opinions about the "right" way to manage. If your background or style differs, they might perceive you as a poor fit. (Later chapters will discuss how to navigate this.)

The other side of the coin

If being interviewed is draining, interviewing others can feel even more so. Hiring is a critical process that's hard to scale effectively. Usually, the manager does the initial screening interviews to protect the team's time. On average, you might interview 15-20 candidates to make one hire.

In some interviews, you'll realize within the first 15 minutes that a candidate isn't suitable (perhaps due to obvious issues like misrepresentation or cheating), meaning the remaining 30-45 minutes feel wasted.

Being accountable for decisions you didn’t make

The larger the company, the less direct power you often have to change top-down decisions. If leadership several levels above you enforces a process that negatively impacts your team, you'll feel the effects acutely and may feel powerless to change it directly.

Even if a bad decision isn't yours, your team will look to you to represent their concerns and push back. Sometimes you can't overturn the decision, but you might find clever ways to work around it, mitigating the negative impact and keeping stakeholders reasonably satisfied.

The worst part of the job, without a doubt, is firing people. I've had to make that call several times, and even when someone is clearly disengaged or performing poorly despite support, it never gets easy. But it's sometimes unavoidable. Often, letting someone go is necessary because their continued presence is negatively impacting the team, requiring others to constantly pick up the slack or endure undue stress.

Alternatives

Staff Engineer

If the challenges above make management seem unappealing, consider pursuing the Staff Engineer path. Keep in mind, however, that these roles are even scarcer than management positions, with a typical ratio closer to one Staff+ engineer for every ten engineers, rather than one manager for every five.

Even as a Staff Engineer, your focus will extend beyond just coding. Much of the technical leadership content in this book, such as the "Programming Pillar" chapter, is relevant, as technical strategy often becomes a shared responsibility between Staff engineers and managers. Skills like conducting 1:1s and giving effective feedback (covered in later chapters) are also crucial for Staff roles, so those chapters are worth reading too.

The wildcard option: Product Manager

It's less common, but if you want to shift to a less technical role, consider moving into product management. A common path requires being at a company long enough to earn the trust for a lateral move.

The ratio of openings for Product Managers is often similar to Engineering Managers, as both are typically needed within a team structure. However, I've worked on teams where the EM effectively acted as the PM because the product role was shared or under-resourced. This highlights why EMs also benefit from strong product skills. If Product Management interests you, check out the "Product and Process" chapter. While the PM typically owns the "what" (Product) and the EM owns the "how" (Process), both collaborate closely to ensure the team executes effectively.