Most engineering career advice treats the leadership track as a ladder where each step is a slightly bigger version of the one before it. That metaphor is the reason so many career transitions go sideways.
IC, manager, director, and VP are four different jobs. Each has its own failure modes, its own definition of what counts as your work, and its own relationship to the code. The skills that earn a promotion to one level are rarely the skills that make someone effective at the next. And the transitions that look incremental from the outside, particularly the manager-to-director jump, are often the toughest ones to navigate.
This guide maps the real leadership shifts at each level. What you're actually accountable for, where people get stuck, and how the leaders who handle each transition well stay technically grounded. Parts of this framework are inspired by what we learned on a recent episode of the Braintrust podcast with Tamar Bercovici, VP of Engineering at Box, who has worked through every level of this track over 15 years at the company. We'll reference her perspective at a few points, but if you want an even richer picture, you should check out the podcast on Spotify, Apple Podcasts, or wherever you get your podcasts.
What the IC job actually is
As an individual contributor, the deal is simple. Your credibility and impact come from technical depth, from understanding systems, finding elegant implementations, and debugging what nobody else can.
This is the role most engineers understand intuitively, and the one that makes every subsequent transition disorienting. The thing that made you excellent here, the ability to go deep and produce directly, stops being the primary lever the moment you move into management.
LeadDev's 2025 Engineering Leadership Report documents what they call the great flattening, a compression of IC career paths that pushes senior engineers toward management once the IC ladder runs out of rungs. The result is a pipeline of new managers whose instinct is to keep doing the job they were good at, which is the single most common failure mode of the next level.
The manager's identity shift
The first real identity shift in the leadership track is figuring out what "your work" even means anymore. You stop being measured on what you shipped and start being measured on what the team shipped. And you have to genuinely believe the team's output is your output, instead of feeling like you're taking credit for other people's work.
Most writing about this transition focuses on soft skills like coaching, delegation, and one-on-ones. Those matter, but the harder part is changing how you see your own contributions to the organization.
"I remember sitting down to try to write my self-evaluation the first time after becoming a manager. What did I do versus what did they do? You almost feel like it's hard to put a finger on exactly what your role is." — Tamar Bercovici, VP of Engineering, Box. Hear the full conversation on the Braintrust podcast.
The tricky thing for new managers to accept is that what the team shipped is what you did. You're accountable for the conditions under which the work gets shipped, which means having the right people, the right roadmap, and the right cross-functional relationships. It means understanding what the team is facing technically without being the one writing the code.
Most new managers overcorrect in one of two directions. Some stay too hands-on, writing the code themselves because they're faster, reviewing every PR, becoming a bottleneck the team can't route around. Others go fully abstract, deferring to the team on every technical decision and losing the grounding that lets you tell the difference between a reasonable trade-off and a shortcut that will cost you later.
There's a distinction worth holding onto here. Being technically grounded means understanding the architecture, the constraints, and the trade-offs your team is hitting. On the other hand, being technically hands-on means writing the code yourself. The first is a requirement at every leadership level, while the second becomes increasingly counterproductive.
The director transition nobody warns you about
This is where the leadership track changes in a way most people aren't prepared for, and where the ladder metaphor does the most damage. The promotion from manager to director often feels incremental, but it's actually a pretty significant category change.
As a manager, you're optimizing within constraints someone else defined. The team's scope, the headcount, the technical strategy, the org structure. These are the boundaries you operate inside, and your job is to make the team as effective as possible within them. A great manager takes whatever environment they're given and gets disproportionate results from it.
As a director, you're responsible for the constraints themselves. Org structure, team boundaries, how work gets prioritized, which technical bets to make and which to kill. When you see a structural problem and don't fix it, nobody else will. The buck stops with you because there's nobody below you whose job it is to solve that class of problem.
This catches people off guard because the day-to-day can look similar. You're still in meetings, still making decisions, still working with the same people. But your job shifts from execution quality to problem selection and org design. Whether the team is even working on the right things, and whether the team itself is structured to make the right things possible, is now on you.
LeadDev's analysis of the director of engineering role reinforces this. The role is defined less by what directors build and more by what they decide. Directors who fail tend to be the ones still operating in manager mode, optimizing the current plan instead of questioning whether the plan is right.
Some organizations formalize this by having principal architects report at the same level as directors. It ensures that technical authority and managerial authority carry equal weight at the strategy layer, and it gives directors a peer who can pressure-test architectural decisions rather than just approving them.
However, once you realize you can reshape the constraints, you can fix structural problems that your teams have been absorbing for years instead of just operating within them. Leaders who unlock that capability create outsized value. The ones who don't tend to stall at the director level without understanding why.
How VPs burn down risk
At the VP level, the job is pattern-matching across the org, allocating resources against bets, and systematically retiring risk. Execution at this level means identifying the biggest risks to the business and burning them down.
"Execution is burning down risk. That's a one-to-one." — Tamar Bercovici, VP of Engineering, Box
A VP reviewing a roadmap is looking for the biggest risks and whether the work is sequenced to retire them early. A VP restructuring an org is redistributing risk by putting stronger teams on higher-stakes problems.
Two failure modes are common at this level. The first is staying in director mode, picking one domain you know well and managing it directly while the rest of the org runs itself. The second is going fully strategic, living in slides and skip-levels and losing touch with what's actually hard for the teams. Both produce roadmaps that look clean on paper and fall apart on contact with reality.
The best VPs maintain something you might call architectural empathy. They shouldn’t be spending their time writing code, but they understand the trade-offs deeply enough to know when a roadmap is realistic and when it's wishful thinking. They ask the right questions in architecture reviews because their investment decisions depend on understanding what's actually hard.
That judgment matters more now than it did a year ago. GitHub and McKinsey's 2026 research found that AI has already reduced routine coding by 46%, which means the ground a VP is making bets on is shifting in real time. The VPs who can't track that shift will make increasingly expensive mistakes.
Why technical depth matters at every level
The form of technical grounding changes as you advance. An IC reads code, a manager reviews designs, a director interrogates architecture, and a VP pressure-tests strategy against technical reality. But the need for technical expertise never disappears, and at every level, the leaders who stall are the ones who let that grounding erode.
This is where AI raises the stakes. When one engineer with AI tooling produces at the output level of several, the operational practices underneath (CI/CD, observability, deployment gates, ownership clarity) become load-bearing in a way they weren't before. CodeRabbit's analysis found that AI-assisted code has 1.7x more issues per commit than human-written code, and 71% of developers say engineering discipline matters more now than it did before AI. Cortex's own 2026 benchmark data tells a similar story.
"I think what's interesting about AI coding is that it's really pressure testing what you already technically should have had in place." — Tamar Bercovici, VP of Engineering, Box
Leadership transitions and AI readiness are directly connected. The leaders who stay technically grounded can tell which parts of their stack will absorb the increased load and which will crack. The leaders who've drifted too far from technical reality won't see the failure coming until it's already an incident. (For more on what that accountability looks like in practice, see AI is writing your code. Who's watching your standards?)
A note for platform leaders
The challenge for platform leaders is that almost none of the features / products they build has a public announcement attached to it, no demo, no launch blog post, no customer-facing moment that makes the value obvious. Making the case for a platform team's value requires a different vocabulary, one rooted in risk reduction, developer velocity, and the reliability guarantees that every user-facing feature depends on but nobody sees.
Gartner projects that 80% of large software engineering organizations will establish platform engineering teams by the end of this year, up from 45% in 2022. The CNCF's Q1 2026 report found that 94% of organizations view AI integration as critical to their infrastructure strategy. The investment is happening, but the harder question is how to demonstrate it's working.
The answer starts with having a shared definition of what a well-run service looks like. Without a standard, there's nothing to measure against, and without measurement, every conversation about the platform team's value becomes anecdotal. Cortex Scorecards allow you to define what good looks like across ownership, test coverage, deployment practices, observability, and security posture, and the platform measures every service against that definition automatically. Engineering Intelligence makes the trends visible over time, so platform leaders can show the trajectory and not just the snapshot.
The leaders who get this right can walk into a budget conversation with measured evidence of what their platform team delivered, the risk they retired, and the velocity they unlocked.
The four jobs ahead of you
The IC-to-VP track is a series of role changes that happen to share a reporting chain (the CTO Playbook for Engineering Excellence covers the organizational side of this in more depth), and each one requires partially letting go of the framing that made you successful at the last level. Depth gives way to leverage, execution gives way to strategy, and ownership of a problem gives way to ownership of the constraints.
The leaders who handle each transition well tend to share one thing. They stay close enough to the real work to know what's actually hard, not to do the work themselves, but to make decisions grounded in what the team is actually facing. For a deeper look at how this plays out in practice, including what it looks like inside a company that grew its engineering team by orders of magnitude, listen to the full conversation with Tamar Bercovici on the Braintrust podcast.
