Will AI change how many engineering managers an organization needs? That depends partly on the work assigned to them. Start by separating the decisions and systems each leadership layer owns; headcount alone cannot tell us whether that work is getting done.
Engineering managers were never hired because they knew how to schedule meetings. Directors were not promoted because they could coordinate quarterly planning. VPs were not successful because they could collect status updates. Those activities simply consumed a disproportionate amount of their time.
Where AI reduces operational overhead, I would reinvest the capacity in system design. That is a choice leaders must make, not an automatic effect of adopting a tool. I call this the Engineering Leadership Stack.
Leadership has always been system design
We describe leadership in terms of people: managing engineers, managing managers, managing organizations. But exceptional leaders have always been designing systems, hiring systems, learning systems, decision systems, knowledge systems, feedback systems, career systems, and trust systems.
For decades, operational work interrupted that mission. Status collection, coordination, and manual reporting expanded to fill the calendar. This is the pull I call Administrative Gravity: the operational overhead that drags leaders down out of design and into logistics. AI changes the equation, but only for teams that redesign their operating model instead of merely adding tools.
The stack, layer by layer
| Role | Designs |
|---|---|
| Engineer | Software |
| Senior / Staff Engineer | Technical systems |
| Engineering Manager | Team environment |
| Director | Organizational operating system |
| VP | Organizational evolution |
Engineers design software
AI accelerates implementation, testing, documentation, and exploration. It does not replace engineering judgment. Engineers still own customer understanding, trade-offs, architecture, and quality. AI changes how software gets built, not why.
This is why vague work instructions become more dangerous, not less. A ticket written for a human teammate often smuggles in assumptions an agent will not reliably infer. Engineers still have to define the problem clearly enough that both humans and agents can work safely.
Staff engineers design technical systems
Staff engineers create reusable capability: golden paths, platforms, reference architectures, engineering principles, operational guardrails. Their leverage comes from improving the technical system rather than individual implementations.
In an AI-native environment, that leverage compounds. A better golden path does not only help engineers. It helps agents, reviewers, onboarding, test generation, incident response, and future migrations. The value of good technical infrastructure multiplies once agents are consuming it too.
Engineering managers design team environments
The manager’s system is the team itself: how it hires, learns, makes decisions, and builds trust. When AI removes some of the operational overhead, the manager’s real work becomes visible. It was always designing the environment in which good engineering happens. This is where Span of Improvement adds a necessary lens alongside span of control: a manager’s impact is the improvement they create in the system, not the headcount they oversee.
Directors design the organizational operating system
Directors design how multiple teams interact: the flow of context, the routing of decisions, the standards that hold across teams. In an AI-native organization this is inseparable from how knowledge and communication are structured, which is why this dimension connects directly to Communication and Knowledge.
VPs design organizational evolution
The VP’s system is the organization’s ability to change itself. Not this quarter’s structure, but how the structure learns and adapts. That is the subject of the Organizations dimension and the Organization as a Product model.
Why the stack matters more with AI, not less
If AI only made engineers faster, you could argue leadership matters less. But AI changes the leverage at every layer simultaneously. The better the systems each layer designs, the more the agents and humans below them produce. Poorly designed systems now fail faster and more visibly, because execution no longer hides the gaps behind sheer effort.
The stack describes responsibilities, not a required hierarchy
Task expertise can sit outside engineering titles. Anthropic’s Claude Code expertise analysis associates domain expertise with stronger task outcomes across occupations. OpenAI’s account of agents transforming work likewise describes use beyond developers. These observational accounts support involving the people who understand the problem; they do not establish this leadership stack or predict which jobs survive.
A five-person company may combine all these responsibilities in two people. A large company may split them across platform, product, security, and operational leaders. Staff engineers can shape organizational interfaces; managers can still contribute technical judgment. The table identifies different objects of design, not exclusive territories.
The claim that leadership should spend more attention on system design is normative. It is not a forecast that AI automatically frees managers or preserves every existing role. Tools can create more review and coordination work as well as remove it. The organization has to choose where recovered capacity goes.
In the fictional Northstar case, the engineer corrects the transaction boundary. A technical leader makes the verification pattern reusable. The manager protects review and mentoring capacity. A cross-team leader resolves ownership of the client contract. In a small team, one person may do several of these jobs.
Evaluate that work through evidence: did a later change receive a clearer decision, did the check catch a recurrence, and did the improvement survive without the same person chasing it? Span of Improvement develops that review without converting it into a headcount substitute or an inflated impact score.