// 2026.05.20

The shape of an engineering team

On a team Fred Brooks endorsed in 1975, and why it may finally be buildable.

// CONTEXT

The first enterprise programs I worked on, in the late 1990s, ran on a village of people. Onshore architects, offshore developers, a QA group, a release team, business analysts writing requirements the rest of us would build from later. Timelines of six to eighteen months were normal. The pyramid answered a question nobody said out loud. How do you coordinate more hands than any one mind can hold?

Fred Brooks named the cost in 1975. In The Mythical Man-Month, he wrote down the arithmetic. For n people, the number of pairwise channels is n(n-1)/2. Ten people, forty-five channels. A hundred, just under five thousand. The growth is quadratic, and it bends sharply enough to break teams.

// THE LONG CORRECTION

The thirty years since were a slow correction. Waterfall gave way to sprints. Requirements became stories. Functional silos became feature teams. Around 2002, Bezos drew a line at Amazon. A team you cannot feed with two pizzas is too big. Six to ten people. Every step pointed the same way. Smaller.

// THE FORGOTTEN IDEA

Brooks's book carried a second idea, quieter than the arithmetic, and largely forgotten. It was not his own. Harlan Mills had proposed the surgical team, and Brooks gave it a chapter and his endorsement. One chief programmer supported by a small group of specialists, the way a surgeon is supported in an operating room. Almost nobody could staff it. The supporting roles asked for talent that did not exist at the depth the model needed, so the industry shelved it and went looking for the smallest feature team it could afford.

// THE THRESHOLD

Something shifted in the second half of 2025. The frontier models crossed a threshold in software engineering. Not in essays, in code. Code that compiles, holds together under review, follows the conventions of the system around it. The large firms are reorganizing in public. Amazon has described a handful of engineers, equipped with agentic tools, rebuilding in a couple of months what would once have taken a team of dozens a year. Microsoft reports that twenty to thirty percent of its code is now written by AI.

Still, the examples share a caveat worth naming. They are rebuilds, known systems started over on a clean bench. The harder test is the codebase nobody fully remembers, the one carrying years of buried decisions. Does the small team hold there too, or only where the bench is clear?

// THE QUESTION

There is a question I keep hearing. Did you use an agent? Are you vibe coding? It would sound silly about a calculator. No one asks an accountant whether the arithmetic came from a machine. But an agent is not a calculator. A calculator is deterministic. Same input, same output. An agent is probabilistic. Ask it the same thing twice and the answers drift apart. The worry underneath the question is unowned code. Code the engineer cannot defend or maintain, because they never understood it. It is the difference between the craftsman who picks up a router knowing exactly what it will do, and the novice who picks one up because a video said to. Same tool. A different relationship to the work.

So the question worth asking is not whether an agent was used. It is whether the work is owned.

The engineer's work is moving from author to editor. From making to choosing.

// THE NEW SHAPE

The shape I think replaces the two-pizza team is smaller and more specific. For an independent application, a mobile app or a web product, two people. One carries the vision and works as architect, product owner, and director of the agents. The other brings different strengths and equal standing, a peer whose angle of sight covers what the first one misses. Two and not one, because the whole model rests on review, and a person checking their own agents has no second pair of eyes. Two and not three, because the third person is the first channel that starts to cost. For a larger product, perhaps five. The unit is sized to the work, not to the org chart.

What moved is the bottleneck. Writing code is no longer the constraint. Reviewing what the agents produce is. The scarce skill is no longer making. It is judgment, the discernment to read a diff and see the architecture it implies, to know whether it should live or be thrown out.

// THE SCAFFOLDING

The shape does not hold on its own. Two people and a model do not ship a product. The surgical team needs scaffolding around it. Convention files that tell the agents how the system is built. An evaluation layer for what they produce. Governance gates for actions that cross a confidence threshold. And a judgment layer, someone, usually the chief, who decides what good looks like. Without the scaffolding, the model slides back into chaos.

// THE ARITHMETIC, INVERTED

Brooks's arithmetic has not been refuted. The channels still grow quadratically with the size of the team. What changed is who pays for them. In a pyramid, most channels ran between people. In a surgical team, most run between the chief and the agents, and those are cheaper. They need no status meetings, no retros, no career conversations. The curve still bends. It just bends in a place where bending is cheap to absorb.

// CLOSE

The team Harlan Mills designed and Fred Brooks endorsed in 1975 is, fifty years later, within reach. The Mythical Man-Month was never refuted. It may be getting fulfilled.

Or it is early, and we are mistaking a clear morning for the whole season. That is the part I am still sitting with.

// SUYOG KONI HEBBAR · TEXAS · MAY 2026