From Engineering Manager to VP Engineering: What Nobody Tells You

Photo by Alex Dos Santos on Pexels

At some point, you go from managing a team to managing managers. Or at least that is the hope all of us had as Engineering Managers. The title changes. The scope changes. The salary, usually, changes. What doesn't change — for a while — is the mental model you're operating with.

That lag is where most VP Engineering failures happen. Not in the big decisions. In the accumulated weight of small ones, made through a lens that no longer fits the job.

What you have to let go of

The code. This is the hardest one, and it's not optional. As an engineering manager, you could still contribute. You had opinions about the architecture, and your opinions were valuable because you were close to it. As VP Engineering, being close to the code is a liability. Every time you weigh in on an architectural decision that should belong to a senior engineer, you narrow the gap between them and the problem they need to own. You stay good. They don't grow. You are depriving them of the opportunity to be independent. The result is that at some point they will leave.

Coding agents didn't make this easier. They made it more dangerous, in a quieter way. Nobody accidentally sits down and grinds out a pull request — that temptation announces itself. "I'll just kick off an agent in the background" doesn't. It sounds like delegation. It isn't. The agent runs unattended; your attention doesn't. It stays fixed on what the agent might come back with — attention the problem in front of you needed instead. Your attention is all your organization needs. Right now, it's pointed at the wrong thing.

Immersing yourself in a codebase hasn't gotten any cheaper, either. If you actually want to go deep — agent or no agent — you still need to block out a full day for it. There's no fifteen-minute version. The tools got faster; the cost of switching your head into that mode did not.

What spawning and monitoring agents actually resembles isn't writing code. It's managing people. You jump between sessions the way you jump between direct reports — each one holding a different context, a different problem, a different question waiting on you. That's a muscle an experienced VP Engineering already has.

If you're making the transition right now, in this era of coding agents, you don't have that muscle yet — which is exactly why the temptation above is more dangerous for you than for someone five years into the role. Being technical still stops being the liability it was for the code itself and becomes the asset it always was for the people around it: you understand what the agent — like the engineer — is actually doing.

This doesn't mean you stop caring about technical quality. It means you express that care through the people and processes — and now the agents — you put in place, not through your own hands.

The temptation changed shape. The job didn't.

The feeling of being the most technical person in the room. When you were an individual contributor, and even as an engineering manager, your authority was partly grounded in technical depth. People came to you because you knew more. As VP Engineering, you need people on your team who know more than you about their domains. If you are still the most technically capable person in the room, you haven't hired well enough (yet, at least).

The identity shift this requires is real. Some people never make it. They stay technically dominant, keep the best problems for themselves, and find after two years that they have a team of followers rather than a team of leaders. And at that point someone else realises the same thing too, and, trust me, that is not a problem a CEO/CTO likes to have.

The comfort of legible output. As an engineer, what you produce is visible: code ships, tests pass, the velocity metric moves. As VP Engineering, your output is the organisation's output, mediated by dozens of people over timescales of months. On any given day, you may not be able to point to anything you did. That ambiguity is uncomfortable, and it never fully goes away — it's one reason imposter syndrome gets louder, not quieter, the more senior you get. The sooner you make peace with it, the better.

What you have to pick up

A longer time horizon. This is how you make peace with the ambiguity above. Your lever got bigger, and the horizon your actions play out on got longer with it. Sprints and quarters still happen, and you still show up to them, but they stop being where your real signal comes from. Whether you hired right, structured the org right, chose the platform right — that answer arrives eighteen months out, sometimes two years, by which point the market has shifted, the org has grown, and half the people in it have changed. You will not know if this quarter's calls were right this quarter. You will know two years from now, and by then you'll already be running the next version of the plan. Commit to a direction, run it, check it against what actually happened, adjust, run it again. Not once. Continuously, for as long as you hold the role.

The org-level view. As an engineering manager, your primary responsibility was your team. As VP Engineering, your responsibility is the engineering organisation as a whole — including the teams you don't directly manage, the inter-team dynamics you didn't create but now have to navigate, and the things that fall through the gaps between teams. You have to develop the ability to see patterns across the organisation that no individual team can see from inside it.

The business perspective. VP Engineering is an executive role, not just a senior technical role. The business cares about outcomes: velocity, reliability, the ability to scale, the cost of the engineering function relative to what it produces. You need to be able to speak to those things fluently — not to the exclusion of technical depth, but in addition to it. If the only language you bring to executive meetings is technical, you will not be in those meetings for long.

Deliberate relationship management. The informal relationships that worked fine when you were managing a single team become insufficient at VP level. The relationship with your CTO or CEO shapes your political reality. The relationship with your product counterpart determines whether the organisation executes. The relationship with the most senior engineers on your team determines whether they stay. None of these maintain themselves. All of them require deliberate investment — regular, honest, not just when something is wrong.

The transition no one talks about

The engineers you used to manage closely will, at some point, start managing themselves. This is the goal. When it happens — when you ask how something is going and the answer is "fine, we handled it" — the right response is satisfaction, not anxiety.

A lot of new VP Engs feel anxiety. They feel dispensable. They wonder what they're for if the team is running without them. The answer is that you're for the things the team can't see from where it sits: the organisation-level problems, the external relationships, the strategy, the hiring pipeline, the culture. None of that is visible from inside a single team. All of it matters enormously.

The transition from engineering manager to VP Engineering is a genuine career change. The people who navigate it well are not the ones who were the best engineering managers. They're the ones who were willing to change what they were good at.