What Great Engineering Managers Actually Do

Most engineering managers were promoted because they wrote good code. That's fine. The problem is nobody explains that the job is now almost entirely different.

I've led teams of up to nine contractors on greenfield platforms, managed training sessions for 60-plus employees at a car finance broker, and done CTO-level advisory work across sectors. The gap between managers who get results and those who create friction is almost never about technical skill. It comes down to one thing: understanding that the role changed the moment the title did.

You're No Longer Paid to Write Code

This is the hardest mental shift. You were the best developer on the team, and now your job is to create conditions where other developers do their best work. Not to review every line, not to rewrite the bits you'd have done differently, and not to stay in the technical weeds because it feels more comfortable than the people stuff.

I learned this on the AYO platform. I was personally delivering 75% of commits while also trying to architect the system, coordinate contractors, and keep a rotating team of nine aligned. That's not management. That's a bottleneck wearing a manager's hat.

The moment I started treating my role as output amplification, things shifted. My job was to make sure nine people could each do their best work, not to be the person who did everything.

The Three Modes Good Managers Operate In

The managers I've worked alongside who were genuinely effective cycled between three distinct modes depending on what the team needed.

The first is direction-setting. Not micromanagement, not vague strategy, but crisp answers to "what are we building and why." On the A2V compliance project, the biggest velocity boost came from getting every department, from compliance to logistics, aligned on what the system was actually for. Once developers understood the business logic, they stopped asking for clarification on every edge case.

The second is obstacle removal. This is unglamorous work. It's chasing down access credentials, untangling a confusing Jira board, having a difficult conversation with a stakeholder who keeps changing requirements, or telling someone their design is good enough and they should ship. If your team is blocked and you're in a meeting, you're in the wrong place.

The third is individual calibration. Every developer on your team has a different ceiling and a different floor. Some need detailed technical guidance. Some need space to fail safely. Some need to understand the business context before they can write good code. Getting this wrong, whether by treating a senior contractor like a junior or leaving a junior to flounder without context, is expensive and demoralising in equal measure.

What Actually Blocks Engineers (And Who Owns Fixing It)

Bad requirements are the number one killer of engineering velocity. Not bad developers. When I was consulting at Intergage Marketing Group, the majority of delivery inefficiency traced back to ambiguous briefs, not poor execution. Developers spend time building the wrong thing, then rebuild it, which looks like a performance issue but is actually a communication failure upstream.

The second biggest blocker is tooling and environment friction. If your CI/CD pipeline takes 40 minutes to run and nobody has fixed it in six months, that's a management failure. Developers tolerate slow feedback loops because they assume someone else is tracking it. Often nobody is. A good engineering manager audits this regularly, treats build time and deployment friction as a genuine cost, and actually fixes it.

Third is context starvation. Developers who don't understand why they're building something make different decisions than those who do. On every architecture review and system design audit I've run, the first thing I assess is whether the team has enough context to make sensible trade-offs. Most of the time, they don't.

The Feedback Problem

Most engineering managers are either too vague or too blunt. "Good job on that PR" is worthless. So is a six-paragraph critique delivered in a public Slack channel.

Useful feedback is specific, timely, and attached to an outcome. "The approach to caching here will cause issues when we have more than one instance running, here's why, and here's how I'd fix it" is a useful comment. "This looks a bit off to me" is not.

Feedback also doesn't have to be critical. If someone made a good architectural call, name it, explain why it was good, and say it in front of their peers. I've found this does more for team confidence than almost anything else.

The Context, Clarity, Cover Framework

After eighteen years of shipping software and leading teams, I'd distil good engineering management into three obligations.

Context means your team knows what they're building, why it matters, and what success looks like. Clarity means requirements are specific enough to act on, priorities are explicit, and trade-offs are documented before work starts, not discovered mid-sprint. Cover means your developers don't have to fight political fires themselves. You take the heat from stakeholders. You manage upward. You're the buffer that lets the team stay focused.

When I think about the projects that went well, those three things were in place. When I think about the ones that didn't, at least one was missing. If your team's delivery feels harder than it should and you're not sure which lever to pull, it's worth thinking about leading through uncertainty as a frame before assuming the root cause is technical.

What Most Companies Get Wrong

The biggest systemic mistake is prioritising technical sharpness over people skills in their engineering managers. Sending someone on an AWS architecture course is easier than helping them get better at difficult conversations. It's also usually the wrong investment at that stage of their career.

The second mistake is confusing velocity metrics with output quality. Commits per week, tickets closed, sprint velocity: these numbers are easy to produce and hard to interpret without context. A team that closes 40 tickets and accrues six months of technical debt has not performed well. If you're evaluating this at an organisational level, a technical health check from a fractional CTO will tell you far more than a velocity dashboard ever will.

Companies that need senior technical judgment without the overhead of a full-time hire get someone who can assess both the management layer and the technical foundations fast. Our CTO in a Box package is built precisely for that: a structured review of your technology organisation with documented findings and a clear picture of what needs to change.

Start Here

If you're scaling a team, trying to work out why delivery has stalled, or stepping into an engineering leadership role and want an outside perspective, Fewzen offers practical senior-level support. The work isn't complicated in principle. Context, clarity, cover. The discipline is in doing all three consistently, especially when things are moving fast.

A great engineering manager multiplies the output of their team. Everything else follows from that.