The Engineering Team Got 4× Bigger.

August 31, 2026

Tech

Given the state of AI coding agents today, what can we do to improve product and engineering velocity by 2-5×?

The first hypotheses are usually about workflow:

Product requirements are underspecified, so give PMs a skill that writes more precise PRDs.
Decisions get lost between product and engineering, so put an agent in Slack, publish a daily update, turn open questions into Linear issues, and chase people to close the loop.

These remove friction, but they do not explain why velocity isn't 2–5× higher than a year ago. Imagine a company with 5 VPs, 25 directors, 200 teams, and 2,000 engineers.

flowchart TD
    VP[5 VPs] --> DIR[25 directors]
    DIR --> ENG[2,000 human engineers]

If 6,000 more engineers showed up overnight, we would quickly move to reconfigure the leadership structure, team boundaries, product/design model, and on-call system.

flowchart TD
    VP[5 VPs] --> DIR[20 directors]
    DIR --> H[2,000 human engineers]
    H --> A[6,000 effective agent ICs]
    H --> O[8,000 IC-equivalents of implementation capacity]
    A --> O

This is what AI agents are doing now: they are the 6,000 junior engineers that have been added to each engineering team. Reorganizing around them is how we get the 2–5×.

A 6-12 engineer team was large enough to own something and sustain on-call, and small enough to coordinate. If each engineer can now direct several agents, that team has the implementation power that used to take twenty or thirty people. Keeping all 6-12 humans in one delivery unit leaves too little independent product surface.

So, I propose that we shrink the default build unit to short-lived one or at most two human engineers plus agents, aimed at a defined customer outcome. We'll call these "Pods".

The "Team" of 6-12 engineers now becomes a collection of Pods, where every member of the team is part of the operational responsibilities and oncall rotation.

The unit of building should shrink. The unit of ownership should not.

flowchart TD
    P[Team<br/>on-call, architecture, knowledge] --> C1[Pod A<br/>1–2 humans + agents]
    P --> C2[Pod B<br/>1–2 humans + agents]
    P --> C3[Pod C<br/>1–2 humans + agents]

Structure	Purpose	Suggested human size	Time horizon
Pod	Deliver a specific product outcome	1–2 engineers, supported by a PM/Designer	2–8 weeks
Team	Own a service family, domain, architecture, and on-call rotation	6–12 engineers across several pods	Durable
Org	Allocate people and attention across related bets	18–25 engineers plus product/design leadership	Long-lived

A pod exists to change an outcome. Its charter should name the customer, the measurable outcome, the constraints, the decision-maker, the interfaces, the time box, and when to scale, pivot, or stop. Give the pod enough context and authority to decide most things itself.

flowchart TD
    V[VP] --> O1[Org]
    V --> O2[Org]

    O1 --> T1[Team]
    O1 --> T2[Team]
    O2 --> T3[Team]
    O2 --> T4[Team]

    T1 --> P1[Pod]
    T1 --> P2[Pod]
    T1 --> P3[Pod]
    T2 --> P4[Pod]
    T2 --> P5[Pod]
    T2 --> P6[Pod]
    T3 --> P7[Pod]
    T3 --> P8[Pod]
    T3 --> P9[Pod]
    T4 --> P10[Pod]
    T4 --> P11[Pod]
    T4 --> P12[Pod]

    X[Shared platform, security,<br/>data, design and reliability] --> T1
    X --> T2
    X --> T3
    X --> T4

Finally, the roles have to change with the leverage:

Role	Before	After
Engineer	Implement a bounded set of tasks	Own an outcome, direct agents, evaluate output, and operate the result
Staff+ engineer	Solve the hardest technical problems and align teams	Design architecture, evaluation systems, and constraints that let many pods move safely
Engineering manager	Allocate work, coordinate a team, develop people	Shape missions, manage attention, and keep quality high across several pods
Director	Manage managers and a large human headcount	Own an org of 15–25 humans with many times that execution capacity
Product manager	Write requirements and coordinate a delivery team	Discover problems, define success, and allocate judgment across multiple bets
Product leader	Review roadmaps and align stakeholders	Decide which learning loops deserve scarce human attention; kill weak bets quickly
Designer/researcher	Produce designs and research inputs	Make customer reality legible to agents and pods; define experience quality

4× velocity means more frequent, high-quality changes in customer or business outcomes, without blowing up risk or operating cost. More code is a weak proxy.

Measure	What it reveals
Time to first customer evidence	How quickly a pod turns an idea into real learning
Decision latency	How long pods wait for product, design, technical, or risk decisions
Outcome-bearing launches per org	Whether more activity is becoming customer value
Rework after product or architecture review	Whether pods had enough context and clear constraints
Change failure and incident load	Whether implementation speed is dumping cost onto operations
Human review time per mission	Where scarce expert attention is limiting throughput
Active work in progress	Whether cheap starts are overwhelming completion capacity
Time from launch to next decision	Whether the organization closes the learning loop

AI made implementation abundant and judgment scarce. PRDs and Slack agents leave the operating model unchanged, so the extra speed becomes queues. We need small pods with end-to-end missions, inside teams that still own the services. The useful question is: if the company woke up with four times the implementation capacity, how would we design the company?

Anant Jain