Speed Doesn't Fix the Bottleneck

I led a workshop recently for engineering leads at a midsize B2B SaaS company. Their annual offsite. I'd prepared material on a range of topics.

What surprised me was what they cared about.

It wasn't AI coding tools. It wasn't new frameworks or development workflows. The room got quiet and focused when we started talking about continuous discovery. How to map assumptions. How to write a good hypothesis. How to figure out if you're making the right bet before you spend three months building it.

These are people who built careers on shipping. Solving hard technical problems. Writing good code. And what they wanted to talk about was whether they're building the right things.

That told me something.

Everyone's role is changing

There's a growing refrain that engineers need to become tech leads now. Think more strategically. Own the what and the why, not just the how. I think that's partly right but incomplete. This isn't just happening to engineers. It's happening to everyone.

When AI compresses execution time, the bottleneck moves upstream. It moves to the decisions, the conversations, and the alignment work that determine whether fast execution produces something valuable or just produces something fast.

Product managers feel it. Designers feel it. Analysts, marketers, project leads — anyone whose work touches a product or a strategy. The people who only know how to execute a plan are becoming less differentiated. The people who can figure out the right plan, explain why it matters, and bring others along are becoming more valuable.

I saw it in a room full of engineers, but I could have seen it in any room.

AI gets you to the bottleneck faster

Here's what I keep seeing in the companies I work with. They adopt AI tools. Individuals get faster. And then everything piles up in the same places it always did.

Requirements that were never clear. Features built and then stuck in review for three weeks because nobody looped in stakeholders early enough. Sprints where the team ships quickly and then discovers they solved the wrong problem.

AI doesn't fix any of that. It compresses the time between "go" and "released" while leaving all the upstream ambiguity intact.

An engineer who uses AI to ship in half the time but can't explain why this bet matters to leadership? That person is just generating more output for the same bottleneck to choke on.

Speed without shared understanding is expensive rework delivered faster.

Three things that matter more now

If the bottleneck has moved, the skills that matter have moved with it. None of this requires becoming a different person. But it does require paying attention to things many of us have treated as someone else's job.

Discovery. Not the buzzword. The practice. Can you find the assumptions hiding underneath a plan? Can you test them cheaply before committing resources? Teresa Torres wrote the definitive book on this.¹ The engineering leads at that offsite were hungry for it because they've lived the pain of building confidently in the wrong direction.

Communication. Not decks and status updates. The ability to make a case for why something matters. To translate between technical reality and business context. To surface disagreement early instead of discovering it three sprints too late. When execution was slow, the pace of building created natural checkpoints. AI removes that pacing. Misalignment compounds faster.

Collaboration. Not meetings. The ability to work across disciplines, pull in perspectives before decisions harden, and build shared understanding rather than assuming it exists. AI makes it possible for individuals to go further alone. That makes it more important to know when to stop and bring people with you.

The part nobody's saying out loud

Here's where this gets uncomfortable.

If the value shifts to discovery, communication, and collaboration — and AI makes each person much more capable in execution — the math on team size changes.

You can't have fifteen people doing assumption mapping together. That's a committee, not a team. Discovery works when the group is small and everyone has real ownership. Communication gets harder as you add people. Fred Brooks pointed this out fifty years ago: coordination costs grow geometrically with headcount.²

So when we say "everyone should shift left," we're implying something we aren't saying. Organizations probably need fewer people than they currently have working on the same sized product or initiative. A team of twelve building features might become a team of five making bets, running experiments, and using AI to ship what they've validated.

The work gets harder per person. It requires more judgment. And there's less of it to go around.

What this might look like

I don't know exactly how organizations will restructure around this. Nobody does yet. But I've been thinking about it in terms of team topologies — borrowing loosely from Skelton and Pais's work on shaping teams around the work they actually do.³ If the work is changing, the shapes should change too.

Here are three scenarios I keep coming back to.

Consolidated strategic teams. Take a typical product org today. Three scrum teams of eight. Twenty-four people, about 75% in execution roles. Now compress that. Same three teams, four people each. Two engineers, a PM, a designer. AI handles the implementation, testing, and scaffolding. Twelve people covering the same surface area, every one of them involved in discovery and decisions.

The studio model. A small permanent core of four to six people owns strategy and discovery. Around them, a constellation of specialists, contractors, AI agents, and partners. The core assembles the right configuration for each bet and reconfigures when it resolves. This is how agencies and production studios already work. Applied to product teams, it means minimal permanent headcount. Expertise assembled, not maintained.

The coordination layer. This is less about individual team shape and more about what happens between teams. If a multi-product SaaS company makes every product team smaller and more autonomous, someone has to make sure those teams aren't pulling in opposite directions. A portfolio strategy function becomes essential — holding strategic context, managing shared infrastructure decisions, maintaining alignment across teams that are each heads-down on their own bets. Some of the displaced execution headcount may find purpose here, but it requires different skills: systems thinking, facilitation, the ability to see across boundaries.

None of these are predictions. They're thought experiments. But they share a direction: teams get smaller, individuals carry more weight, and the hard problem shifts from executing efficiently to coordinating autonomy.

What you can do about it

I don't have this figured out. But a few things feel concrete enough to share.

Learn discovery as a discipline. If you've never mapped assumptions or written a hypothesis for a product decision, start with Torres's Continuous Discovery Habits.¹ Also learn basic facilitation. This means running a conversation that surfaces real disagreement rather than polite agreement is one of the most undervalued skills in any organization.

Have the conversations that feel risky. If your role is changing, say so. Talk to your manager about where you want to grow. Talk to your cross-functional partners about what's working and what isn't. Ask the uncomfortable question: are we building the right thing, or just the thing that was already decided? The alternative is six months of executing well on a bad bet.

Sit with some hard questions. What am I good at that's becoming less scarce? What am I avoiding that's becoming more important? Where am I using speed as a substitute for clarity? I've asked myself these over the past year. The answers weren't comfortable. But they pointed me toward work that feels more durable than just getting faster at what I already knew.

The real challenge is identity

Most of us built our professional identities around execution. We're the person who ships. Who gets things done. Who takes a vague ask and turns it into something real.

That identity served us well. It still matters. But it's not sufficient on its own anymore.

The engineers at that workshop weren't just learning new techniques. They were renegotiating their sense of what makes them valuable. That's harder than picking up a new tool or reading a book. It means being a beginner again in areas where you're used to being the expert.

The roles are still forming. The team shapes are unresolved. The balance between smaller teams and the coordination needs of large organizations is a genuinely open question.

But the direction is clear enough to start moving. The bottleneck isn't execution anymore. It's knowing what's worth executing, and being able to bring people with you.

There may be fewer seats at the table when we get there. That's worth being honest about.

References

1. Torres, Teresa. Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value.Product Talk LLC, 2021.
2. Brooks, Frederick P. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975. Brooks's law — "adding manpower to a late software project makes it later" — rests on the observation that communication overhead grows as n(n-1)/2, where n is team size.
3. Skelton, Matthew, and Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow.IT Revolution Press, 2019.