Engineering Manager

Impact: Management / Engineering Management

Manages engineering team; handles hiring, performance management, and career development.

What does an Engineering Manager do?

What the work is really like

You spend most of your time in one-on-ones, sprint planning sessions, and cross-functional meetings with product managers and designers. The code you write drops to near zero. Your job is to make sure the people who do write code have clear priorities, the right tools, and room to grow. You still review architecture decisions and weigh in on technical debt, but you are no longer the one building the system. You are the one deciding what gets built and who builds it.

The day runs on a rhythm of people problems and process friction. Someone on your team is stuck on a gnarly performance issue and needs uninterrupted time. Another engineer is frustrated with the scope of their work and you need to surface it before they leave. A product manager wants a feature delivered two weeks earlier than your estimate, and you have to negotiate without burning goodwill on either side. You translate business goals into engineering priorities and engineering constraints into terms the business can act on.

You also handle the hiring pipeline: reviewing résumés, running interviews, selling candidates on the role, and onboarding new hires in a way that sets them up to contribute quickly. Performance reviews, compensation planning, and career development conversations happen in cycles, and they require more emotional attention than most engineers expect when they move into management. When someone underperforms, you own the hard conversation and the performance improvement plan. When someone excels, you fight for their promotion.

Skills and strengths that matter

You need enough technical depth to evaluate architecture choices, spot bad trade-offs, and push back when a solution is over-engineered or fragile. You do not need to be the best engineer in the room anymore, but you do need to stay close enough to the work to know when someone is stuck for the wrong reasons. Reading code, understanding system design, and keeping up with the tools your team uses all remain part of the job.

The harder skills are relational. You have to give feedback that is clear, specific, and kind enough to be heard. You mediate conflict between engineers who have strong opinions and no patience for compromise. You run meetings that end with decisions, not more meetings. You write project plans, manage sprint capacity, and flag risks before they become fires. Budget planning matters more than you expect: headcount, tooling costs, and infrastructure spend all require you to make a case to finance or your director.

Empathy and pattern recognition separate good managers from mediating ones. You notice when someone's output drops because they are bored, overloaded, or dealing with something outside work. You learn to read a room and know when to let a debate continue and when to call it. You build trust slowly, through consistency and follow-through, and you lose it quickly if you promise things you cannot deliver.

Who tends to thrive here

People who move into this role successfully tend to care more about the team's output than their own code. If mentoring, clearing blockers, and watching someone else solve a problem you could have solved faster yourself give you energy, the work will feel sustainable. If you still want to be the person writing the hardest code, management will drain you.

You need a high tolerance for context switching. Calm under pressure helps. The role comes with stress that does not resolve quickly: open headcount during a hiring freeze, a key engineer giving notice, a project slipping while the business pushes for delivery. You hold that tension without letting it destabilise the team.

People who struggle here often miss the focus and satisfaction of deep technical work. The feedback loop is slower, the work is messier, and you do not ship features so much as ship the conditions for other people to ship features. If you need visible output or prefer problems with clear right answers, management will feel like a step backward.

How people get into the role and grow

Most engineering managers start as strong individual contributors, usually senior engineers or tech leads who have been at the company long enough to understand the codebase and earn trust. A bachelor's degree in computer science or a related field is common, though some people come in through bootcamps or self-taught routes if they have years of solid engineering work behind them. You do not need a business degree, but you will need to learn project management, hiring practices, and how to read a budget once you are in the seat.

The first year is mostly about learning to let go of the code and building new habits around communication and delegation. You start managing a small team, often three to six engineers, and your own manager coaches you through the mistakes everyone makes. By year three or four, you are managing larger teams or multiple squads, handling more complex projects, and influencing product planning at a higher level.

From here, the path splits. Some people move into director roles, managing managers and shaping org-level strategy. Others go deep as staff-plus engineers or move laterally into product management. A few return to individual contributor work after realising management was not the fit they hoped for, and that is common enough that most companies make the transition reversible. Demand for experienced engineering managers remains stable, and the skill set holds as teams grow and software continues to require people who can build both systems and the teams that build them.

From people doing the work

Being an Engineering Manager is a constant balancing act. You're deeply involved in people management, from hiring to performance reviews, while also needing to stay technically sharp enough to guide your teams. It's less about writing code and more about enabling others, removing blockers, and support a high-performing environment. The satisfaction comes from seeing your team grow and deliver impactful products, but it also means dealing with a lot of context switching and unexpected challenges.

Drawn from LeadDev, r/engineeringmanagers, 5-10 years

Attribution: Composite

Composite · Synthesised from LeadDev, r/engineeringmanagers, 5-10 years

A day in the life of an Engineering Manager

People interaction: Extensive
Team vs solo: 85% Team / 15% Solo
Client facing: Sometimes
Impact visibility: Very High
Travel: Occasional
Schedule flexibility: Moderate
Remote work: Hybrid
Typical work hours: 50-60
Stress level: High