Software runs the modern world, but the people who build it are managed, mostly, by people who were never taught how. Engineering management is one of the few jobs where you get promoted into the role with zero training and a vague sense that it will be like the old job, only with meetings. It is not like the old job. Here is what engineering management actually is, what a manager does all week, and the mistakes that quietly sink new managers before their first year is over.

1. What Engineering Management Is (and Is Not)

Engineering management is the job of making other engineers effective. Notice what that definition does not include: it does not say writing the best code, or knowing every technology, or being the person who unblocks the hardest bug. Those are things engineers do. A manager does them only when nobody else can, and even then reluctantly. The manager's output is the output of the team. If the team ships, the manager is doing well. If the team is stuck, demoralised, or burning out, no amount of personal brilliance on the manager's part fixes it.

This sounds obvious and is violated constantly. Most new managers keep doing their old job and treat management as an add-on. The result is a team that does not feel managed, a manager who works sixty hours a week, and a growing pile of unresolved people problems. The first and hardest transition in your career is accepting that your hands no longer build the thing. Your words do.

2. The Two Hats: Technical and People

Every engineering manager wears two hats, and the ratio between them changes with seniority. The technical hat is about judgement: what to build, how to sequence it, when to pay down debt, what good looks like. The people hat is about everything else: hiring, feedback, career growth, conflict, motivation, and the quiet work of making sure nobody on the team is drowning silently.

Junior managers spend most of their energy on the technical hat and learn the people hat through painful mistakes. Senior managers invert this. By the time you manage managers, the technical hat is mostly about asking good questions, because you can no longer verify answers yourself. The trick is not to pick a hat and stick with it. The trick is to know which one the situation demands. A team in a technical crisis needs your technical hat. A team where one person is burning out needs the other, and the technical problem can wait a day.

3. What a Manager Actually Does All Week

The week of an engineering manager looks fragmented, and that is by design. One-on-ones, typically thirty minutes per person per week, are the backbone. This is where problems surface before they become emergencies, where feedback is delivered in small doses instead of annual surprises, and where you learn what your team actually thinks. Never cancel a one-on-one for a meeting. That is the fastest way to teach your team that they are not the priority.

Beyond one-on-ones: planning and prioritisation, because a team without clear priorities invents its own and they will not match yours. Code review and architecture discussions, where the technical hat lives. Hiring, which is the highest-leverage thing a manager does, because every hire multiplies or divides the team's output for years. And a surprising amount of writing: status updates, decisions, post-mortems, because written communication scales and meetings do not.

4. The Mistakes That Sink New Managers

The classic new manager mistakes are remarkably consistent. Micromanaging: checking in hourly, rewriting pull requests, hovering until the team stops thinking and starts asking permission. The opposite failure, disappearing: assuming the team will self-organise and then being surprised when they drift. Both come from the same root, which is not having a clear idea of what the manager is supposed to be doing.

Then there are the subtler ones. Giving feedback only in reviews, so problems fester for months. Hiring for skill and ignoring attitude, then spending a year managing the consequences. Protecting the team from everything, including useful information, which breeds distrust. And the most expensive one of all: promoting your best engineer because they are your best engineer, when they never wanted to manage anyone. The best coder is rarely the best manager, and losing them from the keyboard while gaining a resentful manager is a double loss.

5. Managing Up, Down, and Sideways

New managers fixate on their team and forget the other two directions. Managing up means translating your team's work into terms your own manager cares about: progress against goals, risks, resource needs. It means saying no to requests before they reach the team, which is a core part of the job, not a political favour. Managing sideways means coordinating with product, design, sales, and the other engineering teams, because most failures are not technical, they are handoff failures between teams that never talked.

The skill underneath all three directions is the same: clear communication about expectations. What will be done, by when, and what it will take. Most workplace misery comes from mismatched expectations, and most mismatched expectations come from managers who assumed instead of asking.

6. Do You Even Want This Job?

Before you take the promotion, ask yourself honestly what you are optimising for. If you love the flow of deep work, the satisfaction of a clean design, the dopamine of a green build, management will feel like a long subtraction of everything you enjoy. If you find yourself more interested in how the team works than in the work itself, if you get energy from helping someone else succeed, if you can tolerate meetings and ambiguity and being the messenger of bad news, then it might genuinely be your calling.

The good news is that the transition does not have to be permanent. Many companies now have parallel tracks where a senior engineer earns the same as a manager. Taking a management role for money or status alone is a bet you will probably lose, because the job is hard enough to require real desire, and the money will not compensate for doing work you do not want every day.

The Bottom Line

Engineering management is not a promotion from engineering. It is a different profession, with its own skills, its own failures, and its own version of success. The manager's product is the team. Learn the two hats, protect your one-on-ones, avoid the classic mistakes, communicate expectations in all three directions, and be honest about whether you want the job at all. Done well, it is one of the most rewarding roles in any company, because you get to multiply people instead of adding to them. Done badly, it burns out everyone involved, starting with you. The difference is not talent. It is treating management as something to learn, not something to inherit.

Tags

#management #leadership