Smaller teams, faster learning

AI made your team faster. So why does everything feel more chaotic?

You know the quarter I’m talking about. AI tools shipped, throughput went up, and suddenly there were more PRs open, more half-finished features in flight, more integration conflicts, and more “wait, what is everyone working on?” conversations than ever before.

The instinct is to add process. More standups, more status updates, more coordination. But that treats the symptom. The actual problem is structural.

The coordination tax

The traditional squad — 6 to 8 engineers, a PM, a designer — was sized for human throughput. When a feature took 3 weeks to build, you needed enough people to cover frontend, backend, infrastructure, and testing. The squad was an answer to the question: how many people does it take to ship something meaningful in a reasonable timeframe?

AI changes the answer. Two or three engineers with agents can now ship what a squad used to. But most teams kept the old structure and just added AI on top.

Now you have 8 people with AI-amplified output, all pushing changes into the same codebase, with the same coordination overhead they had before. More starts. More partial work. More “I didn’t know you changed that.”

Here’s the thing: coordination cost doesn’t scale with AI. Execution speed does. The gap between them is where the chaos lives.

Smaller pods, vertical slices

I’m not theorizing here. Last quarter, my team hit both failure modes — too many simultaneous initiatives, too much coordination overhead, and a lower probability that any single effort shipped cleanly.

Sound familiar? The fix isn’t adding process. It’s restructuring the unit of execution.

So the model I’m rolling out breaks the squad into 2-3 person pods — each owning end-to-end vertical slices. Not a reorg. The team stays one team with shared goals, shared standards, shared accountability. Pods are execution pairings, not mini-teams.

Why small pods specifically:

• Context is always shared. Two people on every meaningful piece of work means no one is the only person who understands how something works.
• Small enough to move fast, large enough to cover a vertical slice. Two or three engineers can own a feature from API to UI without waiting on anyone.
• Natural code review partner. This matters more now. When AI is generating a significant chunk of your code, having someone who understands the intent review the output isn’t optional — it’s the quality gate.
• Reshuffled every 6 weeks. Pods aren’t permanent. At every cycle boundary, people can rotate. Context spreads across the team instead of calcifying.

The counterintuitive discipline

When AI makes your team faster, the natural response is to do more things at once. More experiments. More bets. More parallel streams.

This is exactly wrong.

AI-amplified parallelism without discipline produces a team that starts everything and finishes nothing. You get 8 experiments running simultaneously with nobody learning from any of them.

The move I’m making: explicit caps on how much high-uncertainty work runs at once.

We’re categorizing work by uncertainty. Most work should be low-uncertainty delivery — known approach, just execute. A few things are medium-uncertainty bets — one hypothesis, limited cohort, measurable outcome. And only one thing at a time is high-uncertainty exploration — multiple unknowns, rapid iteration, real ambiguity about what to build.

One. At a time.

That single constraint changes more than any tool you adopt. It forces real choices about what matters most, instead of spreading attention across everything that seems promising. And it forces you to kill things. Most teams keep every initiative alive because stopping something feels like failure. But running 5 mediocre bets is worse than running 2 good ones and having the courage to cut the rest.

Ship-learn loops, not sprints

The real unlock isn’t smaller teams. It’s what smaller teams enable: faster learning cycles.

When a pod can ship a vertical slice in 2 to 3 days instead of 2 to 3 weeks, you can run real experiments.

Most teams batch work into 2-week sprints and ask “did we finish?” That cadence was fine when building the feature took 2 weeks. But when a pod can ship a slice in days, the 2-week batch isn’t fast enough to learn. You’re waiting to evaluate work that could have been in front of users a week ago.

Ship-learn loops ask a different question: “did we learn?” Ship something small. Watch the signal. Decide: promote it, iterate on it, kill it, or park it. Then reshape the next increment based on what you saw.

The target I’m setting is 2 ships per week per pod. Small, reversible increments. Feature flags by default. Limited cohorts first, then expand based on data.

I expect the hardest part will be the discipline of saying no. When AI gives you the capacity to start 6 things, capping at one high-uncertainty bet will feel like leaving money on the table. It isn’t. It’s the difference between 6 half-learned lessons and one real answer.

Your team probably got faster this year. The question is whether your structure caught up, or whether you just added speed to chaos.