Post
JA EN

From Two-Pizza to One-Pizza Teams: What Gets Lost When AI Halves Your Team

From Two-Pizza to One-Pizza Teams: What Gets Lost When AI Halves Your Team
  • Target audience: Engineering managers, tech leads, and engineers involved in team operations
  • Prerequisites: Hands-on experience working in software development teams
  • Reading time: ~15 minutes

Overview

Amazon’s “two-pizza rule”—teams should be small enough to feed with two pizzas (6–8 people)—has been a staple principle in the software industry. But now, with the rapid adoption of AI coding tools, teams are shrinking further toward “one-pizza teams” (3–4 people). Engineers at Anthropic use AI for 60% of their work and report a 50% productivity boost1. Meta is experimenting with a flat structure where one manager oversees 50 engineers2. Yet an 8-month field study from UC Berkeley found that AI tool adoption actually increased cognitive fatigue and working hours3. This article examines both the productivity gains from team downsizing and what quietly gets lost in the process.

The Rise of the “One-Pizza Team”

From Two Pizzas to One

The “two-pizza rule,” popularized by Amazon’s Jeff Bezos, intuitively captured the relationship between team size and communication costs. As Brooks’s Law illustrates, communication channels grow at n(n-1)/2 as team members increase4. An 8-person team has 28 channels; a 4-person team has just 6—a 78% reduction.

flowchart TB
    subgraph TWO["Two-Pizza Team (8 people)"]
        direction TB
        A1((A)) --- A2((B))
        A1 --- A3((C))
        A1 --- A4((D))
        A1 --- A5((E))
        A1 --- A6((F))
        A1 --- A7((G))
        A1 --- A8((H))
        A2 --- A3
        A2 --- A4
        A2 --- A5
        A2 --- A6
        A2 --- A7
        A2 --- A8
        A3 --- A4
        A3 --- A5
        A3 --- A6
        A3 --- A7
        A3 --- A8
        A4 --- A5
        A4 --- A6
        A4 --- A7
        A4 --- A8
        A5 --- A6
        A5 --- A7
        A5 --- A8
        A6 --- A7
        A6 --- A8
        A7 --- A8
        note1["Communication<br>channels: 28"]
    end
    subgraph ONE["One-Pizza Team (4 people)"]
        direction TB
        B1((A)) --- B2((B))
        B1 --- B3((C))
        B1 --- B4((D))
        B2 --- B3
        B2 --- B4
        B3 --- B4
        note2["Communication<br>channels: 6"]
    end

With the arrival of AI, the assumptions behind Brooks’s Law are shifting. Traditionally, adding people to compensate for insufficient capacity caused communication costs to explode. If AI can double individual productivity, there’s no need to add people in the first place. One company director stated, “We’ve started renaming two-pizza teams to one-pizza teams. With AI, large teams just don’t make sense anymore”1.

The Numbers Behind the Productivity Gains

Data supporting AI-driven team downsizing does exist.

MetricValueSource
Anthropic engineer productivity gain50% (2–3x from a year ago)Anthropic internal survey1
Work that wouldn’t have been attempted without AI27% of totalAnthropic internal survey1
AI-assisted individual vs. traditional teamIndividual matches traditional teamHarvard/Wharton P&G study5
ISBSG optimal team size3–5 people1,000+ project analysis6

A joint study by Harvard/Wharton and P&G demonstrated that individuals using AI tools could produce output equivalent to traditional teams without AI5. Furthermore, AI-equipped teams significantly outperformed those without AI.

Meta’s Extreme Experiment

In March 2026, Meta introduced a flat structure in its AI engineering division where one manager oversees 50 engineers2. This doubles the 25:1 ratio traditionally considered the upper limit for flat organizations—a radical experiment.

Professor André Spicer of Bayes Business School warned this structure “will end in tragedy”2. His three reasons: junior engineers will be overlooked, line managers will burn out from overload, and mid-level engineers will lack clear direction, with “the loudest voices or problem employees” monopolizing the manager’s limited attention.

What’s Actually Happening Behind “Productivity Gains”

AI Doesn’t Reduce Work—It Intensifies It

The logic of team downsizing is straightforward: “AI doubles productivity → half the people can produce the same output → shrink the team.” But this syllogism has a critical blind spot.

An 8-month field study by UC Berkeley’s Associate Professor Aruna Ranganathan and colleagues (at a US technology company, approximately 200 participants) found that work was intensified in three ways after AI tool adoption3:

1. Task Expansion

Product managers and designers started writing code; researchers took on engineering work. AI tools created a sense of “I can probably do this too,” causing people to absorb tasks well beyond their original roles.

2. Blurred Boundaries Between Work and Personal Life

Interacting with AI feels like chatting—it doesn’t feel like “working on a formal task.” As a result, work began creeping into lunch breaks, meetings, and evenings.

3. Increased Multitasking

Managing multiple AI workflows in parallel led to “constant attention switching, frequent checking of AI outputs, and a growing backlog of incomplete tasks.”

“AI Brain Fry”—A Large-Scale Survey of 1,488 Workers

In March 2026, a research team from BCG and UC Riverside surveyed 1,488 US full-time workers and identified a phenomenon they called “AI Brain Fry”7.

flowchart TB
    A["Intensive AI<br>tool usage"] --> B["Increased<br>cognitive load"]
    B --> C["AI Brain Fry<br>(14% affected)"]
    C --> D["Decision fatigue +33%"]
    C --> E["Critical errors +39%"]
    C --> F["Turnover intent +39%"]

    A --> G["Delegating repetitive<br>tasks to AI"]
    G --> H["Burnout -15%"]

    style C fill:#ff6b6b,color:#fff
    style H fill:#51cf66,color:#fff

Key findings:

  • 14% of AI users experienced AI Brain Fry
  • High-level AI supervision tasks increased mental effort by 14% and mental fatigue by 12%
  • Information overload increased by 19%
  • 3 simultaneous tools was the peak—beyond that, productivity declined
  • Affected workers experienced a 33% increase in decision fatigue and a 39% increase in critical error rates
  • Turnover intention rose from 25% to 34% (a 39% increase)

However, there was an important positive finding as well. When AI was used to eliminate repetitive tasks, burnout decreased by 15%7. How AI is used—to add tasks or remove them—makes all the difference.

Three Things Lost When Teams Shrink

Behind the productivity numbers lie hidden costs of team downsizing.

1. Loss of Tacit Knowledge

Research on organizational memory shows that the loss of tacit knowledge—undocumented knowledge rooted in individual experience—inflicts more severe damage on organizations than the loss of explicit knowledge8.

When a team shrinks from 8 to 4, code comments and documentation remain. But “why this design decision was made,” “how we’ve handled this client’s special requirements,” and “what approaches we tried and failed in the past”—this tacit knowledge leaves with the people who carry it.

A study in Management Learning demonstrates that without structured knowledge transfer plans (risk assessments, expert interviews, knowledge mapping) during downsizing, organizations are doomed to repeat the same mistakes9. AI can generate code, but it doesn’t retain the negative knowledge of “why we chose not to go that route.”

2. Erosion of Psychological Safety

As Google’s “Project Aristotle” (2015) demonstrated, psychological safety is the single most important factor in team performance10. When teams shrink, individual responsibility grows heavier and the impact of failure maps directly onto individuals.

In a 3–4 person one-pizza team:

  • No redundancy: One person’s absence means losing 25–33% of capacity
  • Fewer diverse perspectives: Risk of degraded quality in code reviews and architecture discussions
  • Lower bus factor: A key person’s departure threatens the team’s very survival11

3. Loss of Mentoring and Growth Opportunities

As Professor Spicer’s critique of Meta’s 50:1 structure aptly illustrates, there are hard limits to a manager’s bandwidth2. In one-pizza teams, the senior-to-junior ratio tends to become extreme, and learning opportunities through mentoring, pair programming, and code review are lost.

The “task expansion” phenomenon reported in the UC Berkeley study makes this worse3. As each member takes on work outside their core expertise with AI’s help, opportunities to learn from deeply specialized colleagues diminish, creating a risk of “broad but shallow” skill sets proliferating across the team.

Conditions for Making One-Pizza Teams Work

Team downsizing may be an inevitable trend. But whether it succeeds depends on whether you “just cut headcount” or “consciously compensate for what’s lost.”

Managing Cognitive Load

Intentionally limit AI tool usage to stay below the 3-simultaneous-tools threshold identified by the BCG/UC Riverside survey7. The “AI Practice” framework proposed by the UC Berkeley research team3 provides useful guidance:

  • Intentional interruptions: Build in time to review and reflect on AI outputs
  • Task sequencing: Batch notifications and limit concurrent workflows
  • Maintaining human connection: Protect structured time for face-to-face communication

Making Tacit Knowledge Explicit

Before downsizing a team, implement the following knowledge transfer processes:

  1. Architecture Decision Records (ADRs): Document the rationale behind design decisions
  2. Negative knowledge records: Capture “why we didn’t take this approach”
  3. Runbook creation: Formalize incident response and client-specific procedures

Redefining Productivity

The most important finding from the BCG survey was that burnout decreased by 15% when AI was used to eliminate tasks rather than add them7. If the purpose of team downsizing is “getting the same people to do more work,” that’s nothing but unsustainable exploitation.

flowchart TB
    subgraph BAD["Unsustainable Approach"]
        direction TB
        X1["Team 8→4"] --> X2["Double each person's<br>task volume"]
        X2 --> X3["Cognitive fatigue<br>and burnout"]
        X3 --> X4["Turnover and<br>quality decline"]
    end
    subgraph GOOD["Sustainable Approach"]
        direction TB
        Y1["Team 8→4"] --> Y2["Eliminate repetitive<br>tasks with AI"]
        Y2 --> Y3["Maintain per-person<br>task volume"]
        Y3 --> Y4["Focus on<br>creative work"]
    end

The right question isn’t “how many people do we need?” but “how do we allocate the surplus AI creates?” Do you fill the freed-up capacity with new tasks, or invest it in quality improvement, learning, and rest? That choice determines whether one-pizza teams succeed or fail.

Conclusion

From two pizzas to one—team downsizing is progressing as the logical consequence of AI-driven productivity gains. Anthropic’s 50% productivity boost and the Harvard/Wharton study show that small teams can achieve outsized results.

But behind the numbers lurk invisible costs. UC Berkeley’s 8-month study documents work intensification; BCG’s survey of 1,488 workers reports AI Brain Fry. When a team is halved, communication channels drop by 78%. But so do the pathways for transmitting tacit knowledge, the foundations of psychological safety, and the opportunities for mentoring.

One-pizza teams are not wrong. But between “reducing headcount while maintaining the same output” and “reducing headcount while doubling each person’s load” lies a deep chasm of burnout and sustainability. Whether we can channel AI’s benefits toward human liberation rather than human exhaustion—that is the litmus test for management in the one-pizza era.

You may also find these related articles helpful:

References

References corresponding to citation numbers in the text, listed in numerical order.

Additional References (not cited by number in the text)

  1. Anthropic’s Engineers Report a 50% Productivity Boost - Kilo AI Blog (2026). Anthropic internal survey data. [Reliability: Medium] ↩︎ ↩︎2 ↩︎3 ↩︎4

  2. Meta’s new AI team has 50 engineers per boss - Fortune (2026). Including comments from Professor André Spicer (Bayes Business School). [Reliability: Medium-High] ↩︎ ↩︎2 ↩︎3 ↩︎4

  3. AI Doesn’t Reduce Work—It Intensifies It - Aruna Ranganathan, Xingqi Maggie Ye, Harvard Business Review (2026). 8-month field study at a US technology company, ~200 participants. [Reliability: High] ↩︎ ↩︎2 ↩︎3 ↩︎4

  4. The Mythical Man-Month - Frederick P. Brooks Jr. (1975/1995). The foundational text on Brooks’s Law. Demonstrates the nonlinear growth of communication costs as team members increase. [Reliability: High] ↩︎

  5. The Cybernetic Teammate: A Field Experiment on Generative AI Reshaping Teamwork and Expertise - Fabrizio Dell’Acqua, Ethan Mollick et al., HBS Working Paper (2025). Joint research by Harvard Business School, Wharton, ESSEC, and P&G. Demonstrates that AI-equipped individuals can match the output of traditional teams. [Reliability: High] ↩︎ ↩︎2

  6. ISBSG Software Development Benchmarking - International Software Benchmarking Standards Group. Benchmarks based on a large-scale project database. Suggests productivity advantages for small teams (3–5 people). [Reliability: Medium] ↩︎

  7. When Using AI Leads to “Brain Fry” - Julie Bedard, Matthew Kropp, Megan Hsu (BCG), Olivia T. Karaman, Jason Hawes (UC Riverside), Gabriella Rosen Kellerman, Harvard Business Review (2026). Survey of 1,488 US full-time workers. [Reliability: High] ↩︎ ↩︎2 ↩︎3 ↩︎4

  8. Challenges In Preserving Organisational Memory - ResearchGate (2018). Demonstrates that loss of tacit knowledge inflicts more severe organizational damage than loss of explicit knowledge. [Reliability: Medium-High] ↩︎

  9. Don’t let knowledge walk away: Knowledge retention during employee downsizing - Achim Schmitt, Stefano Borzillo, Gilbert Probst, Management Learning (2012). Knowledge retention strategies during downsizing. [Reliability: High] ↩︎

  10. Project Aristotle - Google re:Work (2015). Large-scale study demonstrating the relationship between team performance and psychological safety. [Reliability: High] ↩︎

  11. Solo Development in the AI Era and the Bus Factor Problem - This blog (2025). Bus factor risks and AI-era team structures. [Reliability: Medium] ↩︎

This post is licensed under CC BY 4.0 by the author.