So you want to be an engineering manager
This is a summary of hundreds of conversations I've had with prospective engineering managers about what life looks like as a manager- the purpose and responsibilities of the role, but more importantly- what you actually do every day.

I chat with a lot of younger engineers about their future, career goals, and what kind of work makes them happy. By far, the most frequent conversation I have is about engineering management- what it involves, how to get into it, and whether it's a good fit for them.
I've also worked with people who've been thrown into management without any real guidance or preparation. This can be a really hard situation, because you absolutely need to be able to ask for help, but it can be terrifying as a new manager to admit that you're struggling.
I thought I'd spend some time summarizing the conversations I often have with prospective managers of what I think life as an effective engineering manager looks like. I'll start with the high level purpose, and then we'll get into the details of what day-to-day activities look like.
The whole point is business outcomes
Let's strip away a bunch of complexity and make this really simple. There's one fundamental purpose of an engineering manager: to deliver business outcomes.
Wait, just that one thing? Yeah, though I understand your confusion. It's easy to get distracted by all the things that managers have to do to make this happen:
- recruiting and building teams
- coordinating priorities and roadmaps
- nurturing culture
- owning technology
- managing stakeholders
- growing and mentoring team members
- ...and a million other things
Yes, these are examples of activities that a manager generally has to do to drive business outcomes, but don't conflate the mechanism with the underlying purpose of their role.
Managers are given a lot of power over people, processes, budgets, and other precious resources, and in exchange, they're accountable for what their teams achieve. The management hierarchy depends on this accountability to carry out their strategy across the organization as a whole, and thus managers are essential as points of leverage for senior leadership.
Some cautionary tales
The Machiavellian vibe of this point sometimes elicits doubt, so let me put this in even more stark terms:
An engineering manager whose team consistently delivers successful business outcomes can get away with a lot.
Here's some examples, from my personal experience, that illustrate the extremes of this dynamic:
That guy's a jerk, but he builds a mean product
I once worked (adjacently) with a manager who I personally (quietly) believed to be an asshole, but who had been successfully running a team that was doing some admittedly great product innovation. He was a darling of the executive team, and was given extraordinary leeway to run his team in some quirky and unconventional ways.
I later found out one of the "quirky and unconventional" things he was doing was emotionally abusing the shit out of his team. This had apparently been going on for a while, and while he did eventually get fired, it was only after multiple, excellent engineers left the company (after having the courage to lodge complaints with HR, even in the face of explicit threats of retaliation). Even after all this, he was only actually held accountable once all this started to impact his team's delivery.
A "healthy" team isn't the only goal
Around the same time, I worked with another manager who was very bright and competent, a deeply caring, empathetic leader, and all-around lovely person. She was very experienced in building teams with a great, positive, supportive, collaborative culture of engineering excellence. They had many of the hallmarks of a high-performing team: motivated, engaged engineers who felt empowered to do their best work, and who really enjoyed working together.
But despite her talent for nurturing teams' health and culture, she wasn't particularly connected to our customers' needs, or the technical details of the systems her team was building. This misalignment of focus built up over time and led to some underwhelming results. She eventually lost the trust of her stakeholders, and was managed out as her team got re-orged.
Business isn't about harmony
If you're thinking both these examples are really fucked up- yeah. While I wish businesses were motivated primarily by creating a great working environment, nurturing a culture of respect, creativity, and collaboration- they're not. They're motivated by economic success- and everything else they do is in service to that.
Luckily for us, thought leaders in our industry have discovered that, at least in knowledge work, value delivery strongly correlates with great cultures and empowered, motivated teams. Businesses that build great cultures do so with the belief that it makes them more competitive- and they're often right.
It's really critical as a manager to recognize the nature of this dynamic. Successful managers use the framing of business outcomes to make decisions, articulate their strategy, and execute against their plans.
OK, so what does a manager actually do?
So now that we understand the primacy of business outcomes, let's do a quick, 100 level overview of the mechanisms and activities that an engineering manager generally has to do to deliver them.
Strategy and alignment
Successful engineering managers act as a bridge between their teams and senior leadership, translating the organization's strategy into tactical, incremental goals for their team. This happens through a few different channels:
- Cascading high-level strategy through the management hierarchy
- Helping the team formulate a roadmap that aligns with the strategy
- Facilitating alignment with product management and other business stakeholders
- Facilitating alignment with other engineering and supporting teams (UX, InfoSec, etc)
Managing up
This isn't a one-way flow of information. Effective managers also influence the decisions of their senior leadership, usually because they have visibility into details of the work on the ground- constraints, opportunities, trade-offs- that senior leadership doesn't.
Being able to effectively identify and articulate these constraints in terms that the business understands is often what distinguishes successful managers from the rest. And really effective managers go beyond surfacing impediments- they show up with solutions, and they're able to sell them to senior leadership and other stakeholders.
Facilitating alignment with external teams
External teams are likely have different reporting lines, priorities, processes, and cultures than the team(s) you manage. You don't have any direct power over them- but you depend on each other to get anything done. How do you manage this?
Successful managers build and nurture trusting, positive relationships outside of the team: with senior management, stakeholders, other managers within Engineering and across other functions. There's no trick to this: it requires a lot of empathy, integrity, follow-through, and attention to detail- consistently- over a long period of time. The reputation you build is a huge factor in your ability to succeed.
I can tell you one thing: your CEO does not want to hear that you couldn't deliver an outcome because another team isn't cooperating with you. It's your job to figure that shit out.
- Do you disagree with a product owner about the value of a feature? Work that shit out.
- Does your team's tech lead disagree with another team's on an API integration? Work that shit out.
- Does the VP of marketing want you to take on unsustainable tech debt to hit a PR deadline? Work that shit out.
Horse trading, politics, favors, and even escalation- these are all tools available to you. Making sure the alignment happens is your job.
Team building
Counter to the instincts of many new managers, building a high-performing team isn't about exerting control over people, rather, it's an exercise in system design. As a manager, your job isn't making all decisions and handing them off for execution (a.k.a. "micromanagement" or "command and control"). Your job is to make sure good decisions get made.
You do this by defining processes, culture, policies, and other organizational structures that come together, along with the people you hire, to form a self-sustaining system. You need to continuously optimize this so that team members feel connected to the mission, understand their freedoms and constraints, and are empowered to make decisions.
A good trick for considering how self-sustaining a team should be: how long could the manager of a team be gone on vacation before the team would start to struggle?
A great manager will have established a solid, self-sustaining culture, mature practices, and healthy relationships with stakeholders- that don't depend directly on the manager. A team like this should be able to function for weeks or even months without their manager. You'd expect that beyond that, without someone explicitly nurturing the system, entropy might begin to set in and delivery would begin to deteriorate.
Driving continuous improvement through visibility and accountability
Because there's no "one size fits all" formula for building a system as complex as an engineering team, managers need to guide the team through a process of continuous improvement. As a manager, you'd help to set the wheels in motion- establishing the processes and culture to enable the team to repeatedly self-reflect on their work, identify areas for improvement, and implement them.
As the steward of this process, you need to establish two important controls:
- visibility into your team's operations
- accountability for the team's outcomes, and individuals' contributions to these outcomes
Some examples of visibility mechanisms:
- attending team ceremonies (e.g. stand-ups, planning, retrospectives, operations reviews, etc)
- holding regular 1:1s with team members
- meeting with stakeholders to get feedback on the team
- soliciting direct feedback or through formal performance reviews
- tracking work through management systems (tickets, kanban boards, CI/CD systems, etc), including metrics derived from them (e.g. cycle time, deployment frequency, change failure rate, etc)
In order for these visibility mechanisms to be effective, you'll need to work to establish psychological safety; team members need to feel safe (and encouraged) to speak up, share their ideas, and give honest critical feedback to others (including their manager).
This is much harder than you think. Giving critical feedback isn't easy to do in most cultures, and by default, people will tend to let their disappointment fester into grudges rather than take the social risk of speaking up.
Luckily, there's a lot of great research on how to build psychological safety for teams. A great resource is The Fearless Organization by Amy Edmondson, or this shorter Harvard Business Review article that discusses misconceptions.
While accountability mechanisms are all ultimately derived from the manager's ability to promote/fire, in practice, you utilize this power very, very rarely. 99.9% of the time, accountability is driven through:
- Providing feedback to team members (e.g. praise, encouragement, guidance, or critical feedback)
- Clarifying expectations by updating processes, policies, etc.
- Mediating when misalignment/conflict arises (within the team or with external stakeholders)
- Direct involvement/interventions in various team decisions
In cases of persistent underperformance, you have an unfortunate, but critical, responsibility: ramp up the directness of feedback, engage HR, formulate performance improvement plans, and occasionally manage someone out.
On the other hand, if you're lucky, you'll have people on the team who are growing quickly, having a big impact, and just overall killing it. In most companies, you'll need to do some work to compile documentation recommending a promotion. The process can be a pain, but man, it is super rewarding to be able to tell someone you manage that they've earned a promotion.
Advocacy and removing blockers
As a manager, you're in a unique position to help your teams identify impediments and obstacles- things that are slowing them down or preventing them from finding the best solutions to problems- and help knock them down. Does your team need some new SaaS tool? Is UX constantly late delivering mockups? Are you blocked waiting on InfoSec to complete a security review? It's your job to make sure these obstacles get removed.
Note that I said that it's your job to make sure these obstacles get removed, not that you have to do it yourself. A strong team will feel empowered to reach outside their normal boundaries and work to address external blockers themselves. A really successful team will build their own cross-organizational relationships, reputations, and influence- expanding their ability to solve problems autonomously.
Additionally, really great managers will also recognize that certain patterns of blockers are systemic, and use their influence to address these through broader change, perhaps across multiple teams, or even at the organizational level.
Recruiting
Recruiting is one of the most impactful things a manager does, because the choice of people to add to the team will have huge and lasting effects, often well beyond the manager's tenure.
I don't think I'm the only person who absolutely hates the process of recruiting. It's often grinding, tedious, and stressful. Making the decision to hire someone after one interview can feel a lot like getting married to someone you just met at speed dating. And if your instincts tell you to pass on someone who you're on the fence about, you've just committed yourself to many additional hours of reviewing resumes, interviewing, and debrief sessions.
Hiring the wrong person can cause enormous, long-term problems for you and your team. It can be very, very hard to manage someone out- not just in terms of time, but in disruption to you and your team, not to mention your own emotional energy. Having to fire someone absolutely sucks.
But damn, when you hire the right people, it can be utterly game changing for you and your team.
Career management
Finally, as a manager, you're generally expected to help coach your team members, helping them grow their skills and progress their careers. This is a little different than the type of mentoring that happens in the context of the day-to-day work; it's usually framed in terms of longer term goals. While this depends on their personal goals, it's most often framed in terms of helping them grow towards a promotion.
This is usually an exercise in assisted self-reflection, goal setting, and articulating the skills and behaviors that objectively define the next level of seniority.
It also might entail advocating for someone externally, helping to open doors for them, encouraging others to take chances on them, and put your own reputation up as collateral.
It's surprisingly common for managers to describe 1/1 meetings as feeling like they're a therapist for their team members. There is, admittedly, some overlap. Sometimes employees need to vent, talk them through a difficult situation, and just to know that you give a shit about their well-being.
Figuring out the 1/1 relationships with your team members is a big part of the job- setting appropriate boundaries, figuring out how much emotional energy you can afford with different people, and trying to reconcile your personal empathy and compassion with your responsibilities as a leader.
No seriously, what does a manager do all day?
Fine, it's meetings. Always meetings. So many meetings.
What does this mean in terms of day-to-day work? I'll be honest- it means a metric shit ton of meetings:
- ceremonies: stand-ups, planning, retrospectives, scrum-of-scrums
- 1/1s: career coaching, status check-ins
- brainstorming/design meetings, working sessions
- performance management meetings
- recruiting: interviews, debriefs
- Ad hoc conversations
- ...and a head-exploding amount of other meetings
To a new manager, especially one who was recently a high-performing individual contributor, this can seem wasteful- since meetings don't solve actual customer problems. But as organizations grow, managers are increasingly necessary as conduits of information; they maintain alignment and combat entropy. They make sure that teams aren't just working effectively, but that they're working on the right things.
You absolutely need to be careful about how you use meetings- they're a very expensive way to use people's time. But if you're using them carefully, preparing for them in advance, running them thoughtfully and efficiently, and you're actually achieving alignment and clarity, then it's not a waste of time.
Also writing, too
You'll likely also spend a lot of time creating and consuming written communication and documentation. Some organizations have stronger cultures of knowledge management than others, but at the very least you'll be authoring/editing work management artifacts (e.g. tickets, designs), writing up meeting agendas/notes, sending out status updates, and juggling a whole lot of ad hoc conversations (e.g. in Slack, etc).
Writing is certainly important for all of these cases, but it's also really important as a leader to put additional effort into using writing as a tool to refine and clarify your thinking, especially when your ideas will carry disproportionate weight in the organization.
Staying connected to the practice
Despite the pressures to constantly keep everyone aligned and make sure outcomes are being achieved, you need carve out time keep yourself connected to the actual practice of engineering: customer needs, your teams' backlogs, your tech portfolio, industry trends, best practices, etc. This may take the form of doing some side projects, reviewing code, or even just listening to a ton of podcasts.
You may be tempted to jump in with your team and write code alongside them, but you need to be careful about the dynamics of this. Between the power imbalance making reviews weird, and scheduling conflicts between your primary role and the requirements of taking operational responsibility for one's own code, this can be a bit fraught.
I chose to optimize my career for happiness
If you've read other stuff I've written, you may know that I left management a few years back, and went back to being an individual contributor. This was actually a pretty hard decision for me, but one I'm really glad I made in retrospect.
Life as a manager is characterized by several things I actively sought to minimize as an IC: meetings, interruptions, and multitasking. As an IC, you generally seek to keep your work-in-progress to a minimum, and focus on getting a series of small, incremental things completely done. I never found a way to do this as a manager, since you have to be fairly reactive and attentive to the needs of everyone else around you. You're also responsible to handle lots of requests generated by external teams that don't track (or care) how much WIP they're generating for you.
I found managing much more draining from a social/emotional perspective, which was difficult given my tendency towards introversion. After a few years, I found myself having a much harder time getting out of bed in the morning- in a way I never did when I was writing software every day.
But that's me- some people absolutely thrive in this kind of dynamic, unpredictable environment, and find life in front of a text editor to be much more tedious.
If you're an IC faced with the opportunity to move into management, and you're not sure what to do, I'd encourage you to not only try it, but really dedicate yourself to some deliberate study of the craft for a while. Even if you decide it's not for you, the experience will make you a much more effective IC.