Engineering Manager

Companies that grew past twenty engineers kept repeating the same pattern. The strongest coder became the team lead, and that one person designed the system, ran the interviews, and sat in the salary conversations. One title, three jobs with almost nothing in common, stacked on one pair of shoulders.

The result looked like this. An outage lands, the lead stays up until three in the morning restarting servers, and the check-in scheduled with a teammate that morning slides to next week. Next week it slides again. The conversation finally happens at the quarterly review, and the engineer hears for the first time what they had been measured on for the past six months. Ask people why they left those teams and the answer was rarely that the work was boring — it was that nobody ever told them where they were headed.

The engineering manager role exists to pull two of those three jobs, people and execution, out of the pile and make them one person's actual work. Knowing what each engineer is good at and where they are stuck stopped being something you did when a quiet afternoon appeared, and became something with a recurring slot on a calendar.

More than half the day goes to meetings and conversations, and the time left for writing code is an hour or two at best, on the days it exists at all.

Five things repeat.

1. One-on-one — a recurring private conversation with one engineer, usually thirty minutes every other week. It is not a status report. It is where the manager hears what is blocked and what the person wants to be doing a year from now.
2. Setting priorities — deciding what goes into the cycle, somewhere between what the product side is asking for and the cleanup the team has been stacking up. Fitting in technical debt work, the deferred cleanup that shows no visible result this week, is part of this.
3. Hiring — opening the role, reading resumes, running interviews. While a team is growing this can eat close to 30 percent of the week.
4. Performance review — twice a year, summarizing each person's results and skills and connecting that to ratings and pay. It looks like a task that lives in review season, but the evidence behind it gets collected in every one-on-one along the way.
5. Clearing obstacles — the incident the on-call engineer can't absorb alone, the work stalled waiting on another team, the question that has been sitting undecided for two weeks.

People misjudge where the time goes. Not one of those five produces something visible by Friday. So a newly promoted manager looks at the week, feels like they built nothing, and picks up a feature with whatever hours are left. Two one-on-ones slip the following week.

The people a manager talks to in a given day fall into four groups.

Engineers on the team take the largest share. One-on-ones, deciding who takes which piece of work, and building the case for someone's promotion all live here.

Product and design come next. What gets built next quarter is the product side's call, but how long it takes is the manager's answer, so a date the two of them have not agreed on does not reach the team.

Then the person who owns technical direction, where the split has to be explicit. What the architecture should be is their call; who takes it and in what order is the manager's. When that line blurs, an engineer asks one question and gets two different answers, so teams usually write down who decides what before the pairing starts.

Last is HR and the executive team. Whether the team gets one more headcount, how wide the compensation adjustments run, whether the team splits next quarter — those conversations happen out of the team's sight. Since engineers never see them directly, carrying back what was discussed, rather than just the outcome, is also the manager's job. If a role got pushed a quarter, they say so at the next team meeting and say why.

"Let's take that one to your next one-on-one."

The topic is closer to one person's situation than something to work through in front of six people.

"I want to put Theo up for promotion this quarter — can you look at the evidence with me?"

Proposing promotions sits with the manager, and the judgment has to be written down rather than asserted.

"I'll handle that one upstairs. Keep the team on the plan."

The manager is absorbing a negotiation between orgs so it never reaches the team's work.

Pagedeck's engineering group is twelve people with one engineering manager. Tuesday afternoons are blocked entirely for one-on-ones. When Mia brings next quarter's plan, the manager answers with the people side attached: Theo is on call for two of those weeks and is effectively at half capacity, and the engineer who joined last month needs another month to be productive. When Grace asks whether to add two more engineers, building the case for that number starts here too.

The most common assumption is that this is where people go when they stop being able to code. Managers push almost no commits, so it reads that way. In practice the volume of code they write drops while the volume they read goes up, because a manager who doesn't know why a decision was made ends up talking about dates and performance with nothing behind it. The involvement moves to leaving comments on design documents and reading reviews; owning a feature with a deadline attached goes to the team.

Leaving the assumption in place costs a team in two directions. Engineers who don't want to let go of the craft avoid the role, and the team runs with nobody watching the people side. Or a manager holds onto the code, and the team sits waiting on decisions that never get made because the person who owes them is deep in a branch. The second version is harder to spot, because from the outside the manager looks busy and productive the whole time.