Two Engineers.

A short history of absurdly small teams — and the leverage that made them possible.

In February 2014, Facebook paid nineteen billion dollars for a company with about fifty-five employees.

WhatsApp was serving roughly 450 million people at the time (more than the population of the United States) on an engineering team you could fit in a single conference room, with chairs left over. The deal worked out to something like $345 million per employee. There are entire publicly traded companies, with towers full of staff, worth less than what each WhatsApp engineer’s seat represented.

Everyone remembers the price. The interesting question is the denominator. How does a team that small carry a load that big?

It’s not a fluke, because it keeps happening. Instagram had thirteen employees when it sold for a billion. Telegram’s founder has said the entire operation runs on about thirty engineers — for one of the largest messaging networks on earth. RollerCoaster Tycoon, one of the best-selling PC games of its era, was written by one Scotsman, Chris Sawyer, almost entirely in assembly language. SQLite (quite possibly the most widely deployed software in existence, running inside essentially every phone, browser, and car on the planet) is maintained by a team you can count on one hand.

The lore treats these as stories about genius. They’re not. They’re stories about leverage — and about a law most companies are still violating daily.

The law nobody repeals

In 1975, Fred Brooks, who had managed IBM’s gigantic System/360 software effort, published the most uncomfortable finding in software management: “Adding manpower to a late software project makes it later.”

The arithmetic behind Brooks’s Law is brutal and simple. Work might scale with headcount, but coordination scales with pairs of people — and pairs grow quadratically. Ten engineers have forty-five possible conversations to keep coherent. A hundred engineers have nearly five thousand. Somewhere along that curve, a company stops being a group of people building a thing and becomes a machine for synchronizing itself, with software as a byproduct.

Small teams don’t win because each member is a hero. They win because they sit on the cheap end of a quadratic. Every legendary tiny team is, mathematically, a team that refused to pay the coordination tax — and found another way to carry the load.

That other way has a history.

The leverage stack

Look at when each tiny-team miracle happened, and you can watch the floor rising underneath them.

Two people (Dan Bricklin and Bob Frankston, an idea and an attic) built VisiCalc in 1979, the spreadsheet that single-handedly sold the personal computer. Their leverage: the compiler and the microprocessor. They didn’t need a mainframe priesthood anymore.

Sawyer’s one-man theme park empire rode the maturing PC platform. id Software’s handful of twenty-somethings shipped Doom to the world in 1993 on the leverage of shareware distribution — no publisher, no sales force, no permission.

Instagram’s thirteen stood on the cloud: AWS meant nobody on the team racked a server. WhatsApp’s fifty-five stood on open source (famously running on Erlang, a telecom-grade foundation a tiny team could never have built but could absolutely use), plus app stores that delivered distribution to billions without a single salesperson.

The pattern: the teams didn’t get smarter each decade. The leverage stack got taller. Compiler, platform, open source, cloud, app store — each layer absorbed work that used to require a department, and the minimum viable team shrank accordingly. Perfection, it turns out, applies to org charts the way it applies to machines: it’s what’s left when there’s nothing left to take away.

What was never the bottleneck

Now a new layer is being added to the stack, and everyone can feel it: AI agents that write code. The obvious conclusion is that teams shrink again — if typing is infinite, surely two engineers can do anything.

But here is where the history gets precise, because Brooks saw this trap fifty years ago too. In his other famous essay, he split software’s difficulty into accidental complexity (the typing, the boilerplate, the mechanical labor) and essential complexity: understanding the system, holding its design in your head, knowing what it does and why and what happens when you change it.

Agents are a flamethrower aimed at the accidental half. The typing is solved; it was solved the moment the first capable coding model shipped.

The essential half just got worse. A two-person team with agents can now produce the output of two hundred, which means two minds are now responsible for comprehending, operating, and answering for a system that grows at two hundred minds’ pace. The constraint was never how fast you could write software. It was always how much software a human team could see, understand, trust, and keep alive. On-call doesn’t care how fast the code was written. Neither does the 3 a.m. incident, the dependency that changed under you, or the question “wait, why does it do that?”

Which means the next tiny-team era doesn’t belong to whoever has the most agents. Everyone will have the agents. It belongs to whoever builds systems legible and self-operating enough that two humans can actually hold them — systems that report their own state, surface their own problems, heal their own routine failures, and never contain a corner nobody understands. The leverage stack’s next layer isn’t more hands. It’s a system that carries its own comprehension.

This isn’t a hypothetical, by the way. It already exists in miniature, and you’re carrying it in your pocket. The reason a team you can count on one hand maintains SQLite (software deployed in every phone, browser, and car on earth) is not that they type quickly. It’s that SQLite is wrapped in one of the most ruthless verification structures ever built: hundreds of lines of test for every line of code, a harness adapted from aviation safety standards, billions of checks run before any release. Three people can hold the world’s most deployed software because the structure carries the burden of proof, and the humans only carry the judgment. That ratio (tiny team, industrial verification) isn’t a curiosity of one project. It’s the prototype of the next era.

Get that right, and the absurd math of WhatsApp stops being a story we tell about outliers and becomes the default shape of a software company.

Imagine if Slack only needed two engineers.

That’s not a joke about Slack. It’s a spec for the next decade.

— Haltere