When the Bottleneck Moves

Notes from an Engineering Manager Learning to Lead in the AI Era

This is the first in an ongoing series of reflections on how engineering leadership is evolving in the AI era. I don’t have a finished framework or all the answers. I’m simply documenting what I’m observing, what I’m learning, and how my own thinking is evolving. If these ideas resonate with you, I’d love to learn from your perspective too.

Image created by Angeline using ChatGPT

Over the past few months, I’ve been reading, listening to podcasts, and experimenting with AI in software engineering.

Like many engineering leaders, I started with familiar questions.

• How should my team use AI?
• Which AI tools should we adopt?
• Will engineers spend less time writing code?
• What does this mean for Engineering Managers?

They’re all important questions.

But the more I explored, the more I realised they weren’t the questions I was most interested in.

Instead, one question kept coming back to me:

If AI is removing one of engineering’s biggest bottlenecks, where has that bottleneck moved?

That question made me reflect on my own career.

Looking Back

People often say “the only constant in life is change”.

I think that’s only half the story.

Looking back over the past twenty years in software engineering, I noticed something else.

Every major technology shift — from cloud computing and DevOps to platform engineering, and now AI — didn’t simply create change.

It moved the bottleneck.

That made me look at my own career differently.

Every meaningful initiative I worked on — whether it was Quality Engineering, Product Engineering, cloud migration, observability, CI/CD, platform engineering, or incident management — felt like a completely different challenge at the time.

But looking back, they all had one thing in common. Each one was an attempt to remove the biggest bottleneck limiting the engineering organisation at that moment.

• Cloud migration removed infrastructure bottlenecks.
• CI/CD reduced deployment bottlenecks.
• Observability helped teams understand production issues faster.
• Platform engineering reduced developer friction.
• Incident management improved how quickly teams could respond, recover, and learn.

Different technologies. Different problems. But ultimately, they were all solving the same challenge:

Helping the engineering organisation move beyond its biggest constraint.

That’s when something clicked.

Engineering leadership has never really been about managing technology. It’s about continuously identifying and optimising the current constraint.

Technology changes. Constraints move. Great engineering leaders move with them. That idea has completely changed how I think about AI.

Bottlenecks Don’t Disappear

One of my favourite ideas from The Goal by Eliyahu Goldratt is surprisingly simple:

Bottlenecks don’t disappear. They move.

Every time we remove one constraint, another becomes visible.

Looking back over the past two decades of software engineering, that’s exactly what our industry has been doing.

• Cloud computing removed infrastructure bottlenecks.
• CI/CD reduced deployment bottlenecks.
• DevOps improved collaboration between development and operations.
• Platform engineering reduced developer friction.

Every generation of engineering leaders has focused on solving the biggest constraint of its time.

I believe AI is simply the next chapter in that story.

AI Didn’t Change the Job. It Changed the Constraint.

Most conversations about AI focus on productivity.

• How much faster engineers can write code.
• How quickly prototypes can be built.
• How many pull requests AI can generate.

Those improvements are real.

But I don’t think they’re the most interesting part.

Implementation is becoming dramatically cheaper.

Whenever one constraint becomes cheaper, another becomes relatively more expensive.

So instead of asking,

“How much faster can AI help us build software?”

I’ve started asking,

“Now that implementation is no longer the primary bottleneck, where has it moved?”

To me, that’s the more interesting leadership question.

My Current Hypothesis

I don’t have a definitive answer.

In fact, this series is my attempt to explore that question.

My current hypothesis is that the bottleneck is shifting toward things that are much harder to automate:

• Understanding the real customer problem
• Making good engineering decisions
• Creating shared context
• Aligning teams quickly
• Verifying AI-generated solutions
• Reducing unnecessary cognitive load

Ironically, AI has removed much of the waiting. It hasn’t removed the thinking. If anything, it has increased it.

What This Means for Engineering Managers

For years, Engineering Managers have focused on helping teams deliver software more effectively.

• Planning.
• Coordination.
• Roadmaps.
• Status updates.
• Removing blockers.

Those responsibilities are still important.

But I don’t believe they’ll be where Engineering Managers create the most leverage over the next decade.

Increasingly, I think our role is shifting from managing delivery to designing the engineering system.

Instead of asking:

• Are we delivering enough?
• Are engineers productive?
• Are we closing enough tickets?

I’m finding myself asking different questions more and more now:

• Why is information difficult to find?
• Why does every incident begin by rebuilding the same context?
• Why do engineers switch between six different tools just to make one decision?
• Why are architecture decisions difficult to discover?
• What repetitive work should never require a human again?

These aren’t project management problems.

They’re system design problems.

Where I Think the Bottleneck Is Moving

One idea keeps coming back to me.

For years, we optimised away waiting.

• Faster builds.
• Faster deployments.
• Faster pipelines.

Now AI is helping us reduce implementation effort as well.

But engineers aren’t necessarily thinking less.

Quite the opposite.

Today they need to evaluate:

• Multiple AI-generated implementations
• Different architectural options
• AI-generated test cases
• AI explanations
• Dashboards
• Documentation
• Slack conversations
• Customer feedback

We’ve reduced manual effort.

But we’ve increased the number of decisions.

That’s why I keep coming back to another idea:

Cognitive Load Is the New Downtime.

Perhaps the next generation of engineering leadership isn’t about helping engineers type faster. Perhaps it’s about helping them think more clearly.

Why I’m Writing This Series

I don’t have a complete framework.

I’m still learning.

I’m experimenting.

I’m changing my mind as I go.

Rather than pretending to have the answers, I want to document the questions I think are worth exploring.

Over the next few articles, I’d like to explore topics such as:

• Why I think Cognitive Load Is the New Downtime
• How the Engineering Manager role is evolving from delivery manager to system designer
• Why engineering leaders need a new toolbox in an AI-native world
• How Design, Engineering and Product (DEP triad) are beginning to converge
• What engineering organisations may need to redesign now that implementation is becoming dramatically cheaper

I fully expect some of these ideas to evolve over time.

That’s the point.

I’m writing to learn, not to present a finished framework.

The Journey Ahead

I don’t know whether cognitive load is the next bottleneck.

Or decision quality.

Or organisational alignment.

But I do believe one thing.

Engineering leadership has always been about helping organisations move beyond their biggest constraint.

AI hasn’t changed that.

It has simply given us a new constraint to understand.

That’s the journey I hope to explore through this series.

If you’re asking similar questions, I’d genuinely love to hear what you’re seeing inside your own engineering organisation.

Where do you think the bottleneck has moved?

This article is the beginning of an ongoing series exploring how engineering leadership is evolving in the AI era. I’ll continue sharing what I’m learn, experiment with, and rethink as my own leadership evolves.