Do you really want to be an Engineering Manager?
Myth versus reality: understanding the requirements and trade-offs.
I didn’t know I wanted to be a Tech Lead, or that I’d be any good in the role. I’d been a Senior Software Developer for several years when my manager pulled me aside one day and told me he thought I’d make a good leader and that he’d promote me to having direct reports if I wanted to go that route. At the time, I was so content with slinging code, grokking docs, shaving yaks, hunting down Heisenberg’s, and butting heads with designers and project managers on the frontline that the idea of leading a team hadn’t really crossed my mind. But we had a weird work culture where it was considered anathema to say no to any management suggestion — it could get you excommunicated to another team, or ostracized and passed over for special projects, and you’d be blackballed as a non-team player. The head of HR literally used to make a point of saying “The word ‘no’ does not exist at our company.” So of course I said yes and hoped for the best.
As it turned out, my manager was one of the good ones and his instincts were correct. I really enjoyed learning how to read people and how to support them. I took the challenge very seriously and had to put in a lot of effort on my own because there was no formal leadership program or much in the way of company-directed training. I had to lean on my “soft skills” much more than at any other point in my career and through trial and error came to recognize that my team had a host of human needs that stretched beyond tools, time management, and coding proficiency and that I instinctively wanted to help solve these problems. Even though I’m an introvert, I discovered hidden reserves of energy and a latent passion for deploying empathy that allowed me to thrive and make genuine connections in our small team setting.
But I honestly struggled in the new role because of how it had me juggling too many (non-complimentary) responsibilities at once. As Team Lead/Manager, I had taken on the duty of weekly 1:1s with team members, and official management activities like conducting annual 360 feedback, bi-annual company alignment check-ins, quarterly salary reviews, weekly code reviews, and organizing team meetings and events. The number of meetings I had to attend myself as part of a larger group with other leaders and stakeholders grew by 100%. At the same time, I was still expected to be a major contributor to our codebase and development standards, own our team roadmap, be the primary developer on some large projects, oversee architecture decisions, and hire and onboard any new team members. To pour salt in the wound, the “promotion” didn’t come with any kind of immediate raise. Part of the myth of management is that becoming a manager is an instant status boost and launches you on a course to becoming the CTO one day. But most of the time this simply isn’t true: management in the tech industry is a lateral move into a new career path, not a step up the ladder. You have to prove yourself all over again by establishing your proficiency and delivering results before earning new salary increases. And not every manager will go on to middle management and beyond, in fact, many line managers flame out and decide they don’t like the job and end up going back into a pure development role.
For better or worse, I stuck it out for years, trying and mostly failing to strike the right balance. Sometimes I was able to direct a lot of energy toward empowering and cultivating the team but would neglect my coding responsibilities and fall behind in projects, or conversely, I would get so heads-down in a development task that I wouldn’t be accessible for days and I’d be late for 1:1’s or miss them completely because I’d unconsciously dismissed the calendar notification as a nuisance while staring at my IDE and wrestling with some programming problem. This is why I spent the last two years in that role trying to convince my manager to assign someone else as Tech Lead instead and to allow me to be a dedicated Engineering Manager. As I’ve written about before, the Tech Lead and the Engineering Manager are really two distinct roles with very different requirements and one person can’t reasonably perform them both at the same time without causing more problems than they solve. It wasn’t until my job title finally changed to Engineering Manager that I felt truly empowered in my role and able to focus on the important work I wanted to do.
Code or people: choose one
So if you’re reading this and you’re considering a move into engineering management or have been offered an opportunity to take on that role, the first question to consider is: do you want to lead people or do you want to write code? Think carefully about this. Understand that a great manager needs to index on people, not code or tools. It’s a completely different mindset — one that’s more about encompassing the needs and perspectives of others rather than being rewarded for the impact you have as a technical problem solver. If you want to avoid the trap of being expected to wear both hats at once, you should clarify with your employer how they define the role. If you're lucky, your employer will comprehend the difference between a tech-focused team leader of peers and actual people management. If you’re not lucky, you may have to grin and bear it for a while like I did and gain as much experience as you can while learning about yourself and the role, or you can always wait for a better opportunity to come along.
You need to be aware of your own biases and make sure you don’t try to influence the direction of your team so much that individual autonomy begins to decay.
I can’t hammer this home enough: as Engineering Manager you should not expect to be writing much, if any, of the code on your team. Any manager who is still dictating the code and coding standards for the team is either in the unfortunate predicament outlined above or is being led astray by toxic beliefs about what makes a good technology leader. You’re not measured on your own individual contributions to the codebase anymore; you’re measured in how well the team performs overall, how much work the team completes, and to what extent the team meets or exceeds its goals. You have to let go. You have to delegate. You have to be okay with trusting other people to do the work — even when they approach the work in a way that is different from the way you’d handle it. You need to be aware of your own biases and make sure you don’t try to influence the direction of your team so much that individual autonomy begins to decay. If you do assert your own ideas too much, this will lead to a kind of agency atrophy whereby your team will cease to know how to perform when you’re not there to explicitly guide them. Turn your team into robots that only follow your orders, and guess what? They won’t know what the heck to do when you’re out sick or take a vacation. That won’t end well for anyone. In the same vein, you really need to try not to become the single source of information or domain knowledge for anything that the team is responsible for. It’s fine to have a good understanding of everything your team is working on, but you shouldn’t be the go-to person for critical knowledge of any systems under your purview. Why? This also erodes the autonomy and confidence of your team to be able to operate on their own without you needing to be present at all times, flipping switches and pulling levers as if they are just worker bees that you control. Your reports need to be armed with all the knowledge they need to thrive in their roles. They don’t need you to be the gatekeeper to sacred knowledge or to act as an oracle they must all go through in order to achieve anything. Be a conduit, not a blocker, to your team.
Welcome to the dark side
As an Engineering Manager, you’ll be exposed to a lot more office politics, you’ll be interfacing with middle managers, other engineering managers, and other stakeholders on a regular basis and you will learn things about the inner workings of the company that you don’t like. You will encounter chaos and discord at the higher levels and you are bound to become somewhat disillusioned. This is normal. Truth is, corporate America is completely dysfunctional and many executive leaders get to lofty positions not by merit but because of tenure, networking, and in some cases simply kowtowing to the CEO. As soon as you step into a leadership role, this dark underbelly will start to be exposed to you and you’ll need to learn how to navigate the culture, deal with the surprises, and compartmentalize the contradictions and ethical concerns — all without becoming angry, uncivil, or too jaded to keep doing your job. Most importantly, you will need to shield your downstream team from the worst of it so they can carry out their work undistracted by things outside their control. You’re peeking behind the curtain now but if you want to keep your employees happy it’s best if they remain somewhat removed from and ignorant of these upper-level realities.
It’s more about empowering your team than gaining power for yourself.
And it’s not just the internal culture flaws that you must filter for your direct reports, there will also be many operational hurdles. You’ll run into schedule conflicts with other teams, you’ll encounter unsympathetic stakeholders who blame your team for being too slow or for blocking them, there will be leadership changes and reorgs that temporarily throw everything into disarray, there will be disagreements with project managers over timelines and scope, there will be sudden strategic pivots that sideline or scupper your current project, and key priorities that shift without warning. Another myth dispelled here is that as a manager you will have more power and influence in your organization. Sorry to tell you that you’ll be up against just as much inertia as ever before. It’s more about empowering your team than gaining power for yourself. Try to focus on that and don’t let the often demotivational and unsupportive executives at the top get you down. Part of your job as the line manager is to constantly stay balanced while the ground beneath you is erupting into lava, finding creative ways to minimize the disruption to your team in terms of productivity and morale. Have you ever heard the euphemism “be a shit umbrella”? Yeah, that.
Some other challenging aspects of the role include:
Delivering critical feedback to direct reports: you may have been their peer in the past, but now you’re in a position to influence their career for better or worse. You have to give guidance on any areas where they need to improve or any rough edges that need ironing out with the goal of a smooth-running team. You need to become comfortable with uncomfortable conversations.
Dealing with interpersonal conflicts among team members: you may have an impulse to become a referee but sometimes that only makes things worse. You may have to get HR involved and things can escalate in unpredictable ways. You will feel responsible even if matters are out of your hands. HR may not resolve the problem and it may just bounce back to you. You will sometimes be swimming in murky waters and faced with all kinds of ambiguity.
Meeting fatigue. Whether you are in-office or meeting on Zoom, your meeting time is going to shoot up. You’re going to have days when you’ll pray for the next meeting to be canceled just so you can rest your brain or get to work on something interesting that you keep having to neglect.
You’re probably going to miss coding and may be envious of some of the cool projects your direct reports get to work on and accomplish. You have to fight the urge to step in and take over, even if your instincts tell you the team may not be approaching the project in the most optimal way. You can guide and mentor but you also have to leave room for people to learn from their own mistakes.
You will need to hire people and may have to fire someone. The former is an arduous task that can take a lot longer than you might think and requires a whole set of interviewing and analysis skills that may not come naturally to you at first. The latter can be emotionally charged, and I won’t lie, can leave you with lingering trauma and self-doubt.
Decisions, decisions, decisions: sometimes you’ll run a democracy and allow everyone on the team to weigh in on a decision that needs to be made, but other times you’ll have to make a decision on your own that could impact someone’s career or the outcome of an important project, and you’ll own the consequences — good or bad.
Shift your perspective
As an individual contributor, you may have spent a percentage of your time collaborating with coworkers on a shared codebase. You may have experienced pair programming. You will have spent a good deal of time reviewing code as a team and giving each other advice in GitHub pull requests. And if you worked in a physical office you probably all went to lunch together quite often. Hopefully, you worked on a team with a strong tribal identity and a good amount of camaraderie. As a manager, you’ll still meet with the team and you can still take a peek at the code, but your relationship with your direct reports is now more complex and involves unavoidable power dynamics. Much more of your time will be spent on your own or with people outside of your team: planning future work, reporting up the chain, assimilating company-wide news and information so you can figure out how it impacts your team, organizing team-building exercises or events in advance, working on formal administrative tasks like performance reviews and salary appraisals. You may find that you no longer get invited to lunch so often. The team needs their own space to be human with each other away from the possible scrutiny or judgment they feel is naturally going to emanate from you as the leader.
The personality quirks and qualities that made you a brilliant Software Developer won’t necessarily help you be an effective manager.
You’ll need to dedicate some time to a different learning path than the one you’re used to as an individual contributor. Instead of learning your way around the codebase and systems and helping to envision the future of the applications under your purview, you’ll need to spend a lot more time learning about the overall business, understanding how the financial numbers impact your team, getting to know the different strategies and processes that underpin the business and learning who the key players are in each department. That’s because part of your job is to help your direct reports understand how the work they do ties into the overall goals of the company. Knowing how their work aligns with tangible business objectives helps provide employees with a sense of purpose and a sense of how their work impacts the organization, your customers, and the world. This is much more satisfying for employees than just dropping completed work into a black box and moving on to the next task. They are an important player in the larger game of your business, not just a worker drone. You don’t want employees to feel like tiny, easily replaceable cogs in a vast machine they can never comprehend — that would be dehumanizing and uninspiring.
The personality quirks and qualities that made you a brilliant Software Developer won’t necessarily help you be an effective manager. To stand out in a leadership role you should be humble, honest, open-minded, psychologically strong but flexible, sometimes vulnerable, and always empathetic. You’re not paid to be the smartest person in the room anymore, you’re paid to get the best results out of the people who report to you so that everybody wins. As an engineer you may have indexed heavily on coding prowess and proficiency and you may have been consciously or unconsciously biased against peers who didn’t seem on par with you. You may have believed that coding ability is the most important or the only important skill for a developer to possess. But when you become a manager you need to put your ego aside. You need to understand that a successful team needs all kinds of operators. It’s not enough for your developers to be good at writing code, you need some of them to excel at communicating complexity, advocating for themselves and others, building rapport with coworkers and stakeholders, building vendor relationships, taking ownership of projects and processes, giving great peer feedback, cultivating healthy team norms, and speaking up about important issues that impact their work. And the only way you’ll recognize any of this is if you’re able to observe the team through a leadership lens rather than a purely technical one.
Eye of the tiger
Your on-the-job training and after-work learning will need to change: instead of watching tutorials on new coding paradigms or frameworks, learning design patterns, or practicing leet code or coding kata’s, you will need to start reading books and newsletters on management and leadership and taking online courses on subjects as wide-ranging as:
How to actively listen and engage people in a 1:1
How to present complex ideas and build consensus around them.
How to communicate clearly and concisely without bias.
How to manage up.
How to give timely, effective feedback.
How to conduct efficient, humane interviews.
How to detect and deal with drops in employee morale.
How to be an empathetic, trauma-informed leader.
How to manage people who are neurodiverse.
How to manage introverts.
How to manage employees who are older than you.
How to maintain an inclusive team culture.
How to cultivate psychological safety.
Detecting and avoiding employee burnout.
How to motivate remote teams.
How to encourage team camaraderie.
How to take a team through the stages of forming, norming, storming, and performing.
I would also recommend reading books on work politics, world cultures, psychology, sociology, and religion. You are in the business of understanding and motivating people now, so you need to try to understand what it’s like to see the world through their eyes. A positive work environment requires treating employees like people, not just a resource. You can only do this by making a concerted effort to get to know them as unique individuals and learning what motivates them to be their best at work. This requires making an effort to maximize your communication skills and spending plenty of quality time talking to and listening to your direct reports. This isn’t a job for someone who prefers to spend most of their time working with machines or reading documentation.
The role of Engineering Manager can be hugely rewarding if you’re the right fit, if you go into it knowing what’s required of you, and understand how it differs from software development or the role of Team Lead. I’ve written before about how gratifying it can be to put effort into growing your team and seeing the results. Learning how to be an effective leader who not only delivers results to the company but builds a legacy of being the kind of person people want to follow is a truly transformative experience and worth pursuing despite how difficult it is. However, I’ve witnessed far too many instances where a company has promoted the wrong person into management, which can have far-reaching consequences for years to come. When a team gets an Engineering Manager who is too technically oriented and not able to communicate and empathize with their direct reports on a human level, employees find themselves ranked only by their hard skills and not recognized for the other qualities they bring to the team. In many cases, this happens because the middle managers in tech are themselves part of a broken lineage — unqualified Engineering Managers who in the past were promoted despite having no proven track record as effective leaders — so it is a self-perpetuating syndrome that frankly a lot of companies have been infected with. The solution is to lead by example: get promoted for the right reasons and build a future middle management layer that is made up of human-first leaders instead of toxic techbros or people who are just not self-aware enough to recognize they're not right for the role. Eventually, we need these effective leaders to move up into Director and CTO roles instead of the typically apathetic, zero-sum, cold calculators or CEO “yes-men” we invariably see being promoted into these roles. I think that’s how you build a tech culture that is nurturing, inclusive, as well as highly effective, instead of toxic and only effective because it’s hard for people to quit high-paying jobs. I don't know if there are many good examples of this out there in the world right now, but one can always hope.