The Two-Pizza Team Was an Answer to Constraints AI Just Solved

In April 2025, an internal Shopify memo from Tobi Lutke leaked. It said, in effect, that no team could request additional headcount or resources without first demonstrating why the work could not be done with AI. Using AI was made a "fundamental expectation" of every employee, including the executive team, and would be factored into performance reviews.

The memo got read mostly as a cost-cutting move dressed up in transformation language. I think that misses what is actually happening. Lutke was not announcing layoffs. He was inverting the default that has shaped team growth for two decades. Instead of adding people when capacity is needed, teams must now exhaust AI capability first and justify the human addition as the exception.

The two-pizza team rule told you how big a team should be. The Lutke memo tells you how big a team should not become. Both rules answer the same underlying question, with different inputs.

What the two-pizza team was actually solving for

Bezos did not invent the two-pizza team because he liked small groups. He invented it because three constraints converged at a specific size.

Cognitive load was the first. Beyond a certain team size, the shared context of the work overwhelms individual contributors. People stop holding the whole picture in their heads and start operating on partial models, which compounds into miscommunication and rework.

Alignment tax was the second. Coordination cost grows non-linearly with team size. Around ten people, the overhead is still manageable. Past that, the meetings, syncs, and updates start eating the work.

Minimum viable scope was the third. To ship anything meaningful at a service or feature level, you needed roughly eight to ten people. Smaller than that, and you could not cover the surface area required to deliver something real.

The two-pizza team was the configuration that minimized the first two costs while staying above the floor set by the third. It was an optimization solution, not a management philosophy. It worked because the three constraints, in 2003, lined up the way they did.

Every input has changed at once

AI does not adjust one of those three constraints. It changes all three simultaneously, and not in the same direction.

Cognitive load actually gets worse, not better. Four agents generating output continuously can overwhelm a team faster than four humans ever did. The team either shrinks to keep the cognitive load manageable, or it abstracts so heavily that nobody actually understands what is being shipped.

Alignment tax compounds faster. The speed of AI-generated work means the gap between two people's mental models drifts apart in days rather than weeks. Coordination overhead that used to require a weekly sync now requires daily contact, or it slips out of phase.

Minimum viable scope collapses. One strong individual with agentic leverage can now ship what previously required a full squad. The floor that justified building teams of eight to ten is gone. You can sit at three or four and still cover the surface area.

Run those three changes through the same optimization, and the answer that falls out is not "two-pizza team minus one." It is a fundamentally different unit. Three to four people maximum, organized around a strong T-shaped generalist, with agents handling much of what used to require specialist roles inside the team.

This is the actual structural pressure behind the layoffs we are seeing. More than one million job cuts were announced in the United States in 2025, with technology among the hardest hit sectors. The reflex is to call this a 2022-2023 style correction. It is not. The 2022 wave was temporary contraction following over-hiring. This wave is permanent role elimination driven by AI-enabled restructuring. Many of the organizations cutting headcount are not struggling. They are making a deliberate bet that smaller, higher-leverage teams will outperform larger, more costly ones.

What three-person teams actually look like

The team that survives this transition is built around a different center of gravity. Instead of a tight specialist mix (designer, two engineers, PM, data person, QA), you get a small group of strong generalists with clear ownership and agent leverage that covers the rest.

The roles do not disappear. The work each role used to do gets redistributed. A designer who can prototype in code and instrument the experiments is operating across what used to be three roles. A PM who can do their own analysis, build their own internal tools, and run their own discovery is doing the work of a former cross-functional pod. The leverage is not coming from each person doing more things badly. It is coming from each person being deep enough in one thing to use agents effectively across adjacent things.

The hiring filter has to change to match. Specialist depth and role-specific credentials, the criteria that worked for a ten-person squad, are no longer the right signals. Curiosity, ownership, and adaptability move from "nice to have" to "non-negotiable." Not because they are virtues. Because in a three-person team where every person's traits are load-bearing, a passenger sinks the whole structure.

The honest complication

This argument breaks down in real ways inside enterprise contexts. Compliance work, large-scale integration, regulated change management, and anything that requires deep institutional memory still benefit from larger team structures. A bank cannot run its core platform on a four-person team. A healthcare provider cannot ship into clinical workflows on three generalists with agents.

There is also a class of work that is fundamentally about coordination across many stakeholders, and no amount of agentic leverage compresses that down to a small team. The two-pizza unit was always a poor fit for those contexts, and the three-person team is worse.

But the trend is unmistakable in the contexts where the constraints actually matched the original logic. Product squads, growth teams, internal tooling teams, and most early-stage product work were exactly the kind of optimization the two-pizza rule was solving for. Those are the teams shrinking now, and they are not coming back to their old size when the cycle turns.

What this means if you are running one of these teams

If you are leading a product team today, the question is not whether the structural pressure is coming. It is whether you would rather restructure proactively, while you still have a hand on the wheel, or have it happen to you in the next reorg.

The proactive version looks like this. Pick the smallest scope of work your team owns. Ask honestly, with a six-month horizon, whether three strong generalists with agent leverage could ship that scope. If the answer is yes, the team you have is already over-built for the work it does. If the answer is no, the gap between yes and no is the actual transformation roadmap.

So the question I would leave you with. If you had to rebuild your current team from zero today, would you reach for the same shape, or would you reach for something smaller and sharper? And if the answer is the smaller version, what is keeping you from moving toward it now?