Every leadership team I talk to—especially recently at Dscout’s Co-Lab conference and the Compass AI & Tech Summit—has the same slide somewhere in its AI deck: smaller teams, fewer managers, more output. The logic sounds airtight. If AI makes each person dramatically more productive, you need fewer people, and fewer people need fewer layers to coordinate them.
I think the logic is half right. AI shrinks the cost of making things. It does very little, so far, to shrink the cost of deciding, aligning, and integrating them. If those costs are still high in your organization, small autonomous teams don’t remove the bottleneck. They just move it somewhere less visible.
- Making
- Deciding
- Aligning
- Integrating
Making got four times faster. The whole job got 30% faster. Illustrative.
So the better question isn’t “why haven’t we restructured into small teams yet?” It’s “what has to be true before small teams will work here, and how will we know if we’re wrong?” Small autonomous teams are an outcome of the right conditions, not an org chart you can draw your way into.
Why big teams can’t just shrink their way to speed
In a large team, coordination is the work. Managers, leads, and program roles exist to route dependencies, broker decisions, and keep handoffs from dropping. Speed up the individuals and you don’t remove any of that. You just feed it faster.
The data says exactly this. Faros AI’s 2025 telemetry study of more than 10,000 developers across 1,255 teams found that developers on high-AI-adoption teams completed 21% more tasks and merged 98% more pull requests, but review time rose 91%, and the gains showed no significant correlation with company-level outcomes (Faros AI). Their explanation is Amdahl’s Law: a system moves only as fast as its slowest link. Bain’s 2025 Technology Report lands in the same place, with most teams seeing only 10–15% productivity gains from AI coding tools (Faros AI summary of Bain).
- 21%more tasks completed
- 98%more pull requests merged
- 91%longer to review
No significant link to company-level outcomes. More than 10,000 developers across 1,255 teams. Faros AI, 2025.
Google’s DORA research frames it more bluntly: AI is an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones (DORA 2025). In cohesive organizations it boosts efficiency; in fragmented ones it exposes weaknesses (Google).
Then there’s Conway’s Law, the observation that organizations produce systems mirroring their own communication structures (Thoughtworks). A monolithic org tends to build a tightly coupled product, and a tightly coupled product requires a monolithic org to change it. You can’t cut the team in half without also cutting the product along the same lines. That’s why “just reorganize into pods” so often produces pods that spend their days negotiating with each other.
You can’t cut the team in half without also cutting the product along the same lines.
Design feels this acutely. AI compresses exploration, prototyping, and early concepting dramatically (but even this isn’t consistent across projects, let alone teams, let alone organizations). But the gains taper as work moves downstream into review, handoff, engineering integration, and legacy delivery formats. Making the fast part faster doesn’t help much when the slow part is a queue.
When bigger teams are the right answer
Larger teams with more managers aren’t a failure state. Sometimes they’re the correct response to the environment. Even Amazon, the company most associated with small teams, found that two-pizza teams only really worked in select product development efforts, where tangled dependencies had been the main drag. The bigger predictor of success turned out to be a leader with the skills, authority, and dedicated focus to own the outcome, which is why the model evolved into single-threaded leadership (Inc., on Working Backwards).
In my experience, a larger, more coordinated structure is still the right call when:
The product is tightly coupled.
No team can own a surface end to end without negotiating with several others. Shrinking teams here just multiplies the negotiations, where something gets lost or broken because someone didn’t know something was already decided.
Decisions need traceable review.
In regulated domains, a second set of eyes isn’t overhead. It’s part of what the customer is paying for. SLAs are a contract you don’t want to vibecode your way into breaking.
Legacy delivery obligations dominate.
If partner teams still need artifacts in formats AI doesn’t accelerate, the slow part of the work stays slow no matter how small the team.
Judgment is thin.
Autonomy only works when the people closest to the work can make good calls without escalating. If that domain expertise, technical skill, or understanding of other interconnected systems isn’t there yet, someone has to knock on a lot of doors to get answers.
Strategy is unsettled.
Autonomy without clear direction produces divergence, not speed. Ten small teams with ten interpretations of the strategy (and 20 ideas to address it) is worse than one large team with one.
None of these are permanent. But each is a condition you have to change first, not a side effect you clean up after the reorg.
What has to be true before small teams will work
If you take one idea from this post, take this: a small team is only autonomous if it can own an outcome without borrowing coordination from everyone else. That requires conditions in two places, the operating system of the org and its culture.
Operational conditions
- A feature or product the team can actually own. Team Topologies argues for teams aligned to a single stream of value that can deliver without waiting on other teams, and for keeping each team’s responsibilities within its cognitive load (Team Topologies). If the product or system can’t be drawn along those lines yet, the team can’t either.
- A platform that reduces load instead of adding dependencies. In the same model, platform teams exist to make stream-aligned teams faster by offloading complexity. For design, that means a design system that both people and AI agents can consume directly, not one that requires a ticket and a meeting.
- AI fluency across the whole lifecycle. Not just discovery and prototyping, but clear, actionable PRDs, quality gates, reviews, handoffs, and delivery. Otherwise you get the Faros pattern: more output piling up in front of an unchanged bottleneck.
- Small batches. DORA’s AI Capabilities Model names working in small batches and quality internal platforms among the seven capabilities that amplify AI’s benefits (Google Cloud). Large AI-generated changes are hard to review; small ones keep speed from turning into instability.
- One outcome metric the team can move on its own. If the team’s success depends on three other teams shipping, it isn’t autonomous. It’s just smaller.
Cultural conditions
- Decision rights pushed down. Leaders manage by context, not approval. Amazon’s lesson is that the leader needs both the authority and the focus to own the outcome, not just a smaller headcount.
- Psychological safety. Google’s Project Aristotle found psychological safety was the most important dynamic in effective teams (Addy Osmani). Autonomy means people will make visible mistakes. If those mistakes are punished, people stop deciding and start escalating again. Even a shared understanding up front of what constitutes a mistake versus a decision that turned out poorly can lay some foundation of what’s acceptable.
- A real user focus. This one is the sharpest warning in DORA’s data: teams without a user-centric focus can see performance decline when they adopt AI (Google Cloud). Speed in the wrong direction is worse than slowness. Discovery has to be valued, not treated as a delay to delivery.
- Generalists with judgment. Small teams don’t have room for people who only operate inside a narrow lane. They need people who can frame a problem, make a call, and carry it through. Waiting for certainty, or wanting clarification on every last problem likely means the team isn’t primed to succeed as a smaller team.
The readiness test: baseline, pilot, decide
So how do you say “this function is ready to try small autonomous teams, even though that’s not how we’re structured today” with a straight face? You treat it as a hypothesis, not a reorg. Pick one surface, measure where it stands, run a time-boxed pilot, and decide in advance what you’ll measure and what failure looks like.
Pick the most separable surface.
Start where the conditions above are closest to true: the least coupled part of the product, the most mature slice of the design system, the team with the deepest judgment. Start with a small number of teams to learn what worked before scaling. Don’t pilot on your hardest problem to prove a point.
Baseline before you change anything.
Most orgs skip this, and then can’t tell whether the pilot worked or just felt better. Capture at least a quarter of history, and decompose the work honestly: how much is AI-accelerable, how much is legacy delivery, and how much is discovery and alignment. That mix tells you how much the team size can change before you’ve changed anything.
Measure during the pilot.
| What to measure | Why it matters | You’re right if… | You’re wrong if… |
|---|---|---|---|
| Idea-to-production cycle time | The end-to-end speed that actually reaches customers | It drops meaningfully, not just upstream | Upstream speeds up but end-to-end is flat |
| Wait time vs. work time (flow efficiency) | Shows whether you removed queues or just moved them | Wait time shrinks as a share of total | Work gets faster, waits stay the same |
| Handoffs per feature | The direct cost of coordination | Fewer handoffs, fewer formats | Same handoffs, smaller team carrying them |
| Decisions made in-team vs. escalated | The real test of autonomy | Most calls stay in the team | Escalations rise or stay constant |
| The team’s outcome metric | Whether speed turned into value | It moves, and the team can explain why | Output rises, outcome doesn’t |
| Quality: rework, defects, accessibility | Faros saw bugs per developer rise 9% with high AI adoption | Quality holds or improves | Speed is being bought with rework |
| Partner team load | The hidden cost of "autonomy" | Neighbors’ load is flat or down | Partners absorb the coordination you thought you removed |
| Team health and retention | Whether the pace is sustainable | Engagement holds or rises | Burnout, attrition, or quiet escalation |
The partner-team row is the one people forget. If a small team looks fast because engineering, research, or a sister design team (often the platform or the design system team) is quietly absorbing its integration work, you haven’t removed coordination. You’ve exported it to someone else. That’s the same pattern Faros describes at the company level, where uneven adoption across interdependent teams erased team-level gains (Faros AI).
Write the kill criteria first.
Before the pilot starts, write down what result would make you stop: for example, end-to-end cycle time unchanged after two quarters, quality down, or partner load up. Share it with your peers and your boss. Pre-committing keeps everyone, including you, from rationalizing the result afterward. It also makes the pilot safer to propose, because you’re asking for an experiment with a defined end, not a permanent restructure.
Earn the right to go small
The pressure to shrink teams because of AI is real, and some of it is justified. But small autonomous teams aren’t something you announce. They’re something an organization earns by decoupling its product, maturing its platform, pushing decisions down, and making it safe to be wrong in public.
The question isn’t “can a small team do this work?” With AI, the answer is increasingly yes. The question is “can a small team own this outcome without borrowing coordination from everyone else?” Measure that honestly, and the right team size usually becomes obvious.
Sources
- Faros AI, The AI Productivity Paradox Report 2025 (July 2025)
- Faros AI, Bain Technology Report 2025: Why AI Gains Are Stalling (October 2025)
- DORA / Google, 2025 State of AI-assisted Software Development Report
- Google, How are developers using AI? Inside our 2025 DORA report (September 2025)
- Google Cloud, From adoption to impact: Putting the DORA AI Capabilities Model to work (December 2025)
- Thoughtworks Technology Podcast, Reckoning with the force of Conway’s Law
- Matthew Skelton and Manuel Pais, Team Topologies
- Jeff Haden, Inc., When Jeff Bezos’s 2-Pizza Teams Fell Short, on Colin Bryar and Bill Carr’s Working Backwards (February 2021)
- Addy Osmani, Effective Engineering Teams, on Google’s Project Aristotle