Part III of the AI SDLC series.
- Part I: Async by Default: Cross-Team Communication in the AI SDLC
- Part II: What Async Can’t Teach You: Rebuilding Apprenticeship in the AI SDLC
Leadership Work Moves Up the Stack
Much of engineering leadership is described through coordination: meetings, planning, reporting, staffing, and escalation. Those activities are visible, but they are not the full job.
The more durable work is system design.
Engineers design software. Staff engineers shape technical systems. Engineering managers design team environments. Directors design organizational operating systems. VPs design how the organization evolves.
AI can reduce parts of the coordination load. That does not make leadership less important. It makes the underlying design responsibility easier to see.
I call this model The Engineering Leadership Stack.
A promotion expands the system a leader is responsible for improving. It is not simply an increase in the number of people they manage.
The Engineering Leadership Stack
Leadership has always been system design.
We often describe leadership in terms of people:
- managing engineers,
- managing managers,
- managing organizations.
The strongest leaders design systems:
- hiring systems,
- learning systems,
- decision systems,
- knowledge systems,
- feedback systems,
- career systems,
- trust systems.
Operational work often competes with this responsibility for attention.
AI-assisted workflows can reduce some of that operational load, but only when teams redesign the surrounding process rather than adding another tool to it. The useful shift is from coordination as the default activity to intentional system design.
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. In The AI-Executable Ticket, I argued that a ticket written for a human teammate often smuggles in assumptions an AI 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 increasingly 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 flows, test generation, incident response, and future migrations.
The staff engineer’s job becomes less about being the smartest person in every design review.
It becomes more about designing the technical environment so better decisions become easier to make.
Engineering Managers Design Team Environments
Historically, engineering managers coordinated work.
Increasingly, they design environments:
- learning,
- feedback,
- psychological safety,
- autonomy,
- knowledge sharing,
- execution.
The engineering manager’s product is not sprint velocity.
It is the daily experience of every engineer.
The question shifts from:
Did we finish the sprint?
to:
Is this an environment where engineers consistently become better?
That shift connects directly to What Async Can’t Teach You. Async communication can make execution cleaner, but people still learn judgment through observation, feedback, and shared reasoning.
The EM owns the environment where that happens.
Directors Design Organizational Operating Systems
This may be the role AI transforms the most.
Historically, Directors spent enormous effort on:
- cross-team coordination,
- roadmap alignment,
- dependency management,
- resource discussions,
- quarterly planning,
- escalations.
AI can reduce the cost of some coordination work.
The scarce resource becomes organizational coherence.
Directors increasingly design:
- organizational topology,
- shared engineering principles,
- ownership boundaries,
- cross-team interfaces,
- AI operating models,
- governance,
- knowledge architecture,
- platform strategy.
This is where Hierarchical Context becomes foundational.
Instead of isolated documentation, organizations develop operational context across multiple layers.
These are not documentation repositories.
They are organizational infrastructure.
Every engineer.
Every AI agent.
Every automation.
Every new hire.
Begins with the same evolving context.
Without context, AI amplifies inconsistency.
With context, AI can amplify excellence.
Directors stop coordinating organizations one thread at a time.
They design how organizations coordinate themselves.
VPs Design Organizations That Learn
If Directors build the operating system, VPs shape how the organization evolves.
The old VP question was:
Are we executing strategy?
The new question becomes:
Are we becoming better at executing future strategies?
VPs increasingly optimize:
- organizational adaptability,
- leadership pipelines,
- engineering culture,
- AI adoption,
- innovation systems,
- technical excellence,
- organizational learning.
Their product is not execution.
Their product is an organization capable of continuously reinventing itself.
Span of Control Becomes Span of Improvement
Traditional leadership celebrated span of control.
The AI era rewards span of improvement.
Notice what each layer’s measure of success does not contain. No velocity. No headcount. No number of reviews attended. Each measure describes a property of the system after the leader has designed it, which means it keeps holding when the leader is not in the room. That is the point.
A measure of success you can only satisfy by being present is not a measure of a system. It is a measure of a dependency.
Leadership scales through systems, not span of control.
This is also why measuring motion gets dangerous. In Stop Measuring Motion: Engineering Value in the AI SDLC, I argued that AI makes output easier to produce and therefore easier to confuse with value.
The same is true for leadership.
A leader can produce more updates, more plans, more dashboards, and more AI-generated summaries without improving the system.
The useful question is different:
AI Removes Administrative Gravity
AI does not reduce leadership.
It removes administrative gravity.
Status reporting.
Meeting coordination.
Routine documentation.
Knowledge retrieval.
Planning overhead.
Those were not leadership.
They were friction.
Once reduced, leadership becomes more visible:
- creating clarity,
- growing leaders,
- designing learning systems,
- reducing organizational friction,
- improving decision quality,
- building culture.
The Organization Becomes the Product
AI-native organizations produce two products.
Software.
And the organization that continuously produces software.
The second increasingly determines the first.
Organizations with better learning systems build stronger engineers.
Stronger engineers build better products.
Better products attract better engineers.
The flywheel compounds.
A Practical Leadership Checklist
The model is only useful if it changes behavior.
Here is the practical version.
Find your layer, and ask.
| Role | Ask |
|---|---|
Engineer | Is the problem clear enough that an agent and a new teammate can both work from it? |
| Did I capture the assumptions behind the implementation? | |
| Did I leave the system easier to understand than I found it? | |
Staff Engineer | Which repeated decision should become a golden path? |
| Which operational guardrail would prevent five future reviews? | |
| Which context is missing from the platform, README, or service boundary? | |
Engineering Manager | Where are people learning judgment, not just completing tickets? |
| Which rituals create clarity and which ones only create motion? | |
| Is the team environment making good engineering behavior easier? | |
Director | Where do teams still coordinate by memory, personality, or Slack archaeology? |
| Which ownership boundaries are unclear? | |
| Which organizational interfaces should become explicit protocols? | |
Which parts of the AI operating model need governance before scale makes them expensive? | |
VP | Is the organization improving its ability to improve? |
| Where are leadership pipelines too dependent on heroic individuals? | |
| Which systems make the next strategy easier to execute than the last one? | |
Are we adopting AI as tooling, or redesigning the organization around new constraints? |
Connecting the Series
Looking back, each article in this series focused on a different layer of the same transformation.
- Async by Default redesigned how information moves.
- What Async Can’t Teach You redesigned how people learn.
- The Engineering Leadership Stack redesigns how organizations evolve.
Together they describe an AI-native engineering organization where execution, learning, and leadership reinforce each other.
Final Thoughts
AI will not replace engineering leadership.
It will expose it.
When coordination, reporting, and information retrieval become cheaper, what remains is the work that always mattered.
Designing organizations.
Growing leaders.
Building systems that outlive today’s technology.
The future belongs to leaders who stop asking:
How do I manage more work?
and instead ask:
What system can I design so that exceptional work happens naturally?
Because in the AI era, the greatest engineering achievement may not be the software your organization ships.
It may be the organization you designed to keep shipping extraordinary software long after today’s technology has changed.