No More Hog Butchering

Earlier this year, I became acquainted with Fred Brooks's Mythical Man-Month, which is a canonical text in the SDLC world (that's software development lifecycle). For the last decade, I've been a rare champion of Agile methodologies. So it's weird that I'd never read the origin of those ideas.

Brooks worked at IBM for nine years, starting in 1956, and his crowning achievement was shipping the IBM System/360 family of computers. With that project under his belt, he went on to teach at Chapel Hill and write extensively about managing software projects, aiming to answer Thomas Watson Jr's question "Why are software projects so much harder to manage than hardware projects?"

Mythical Man-Month is a great text, and it's where Brooks's Law came to be:

"Adding manpower to a late software project makes it later"

MMM is worth a lot more ink than I can give it here, but the chapter titled "The Surgical Team" is particularly relevant to me, today, and to everyone building software for the years to come.

Chapter 3 of Mythical Man-Month poses the question: "how does one build large systems on a meaningful schedule?"

It's important to note that the preceding chapters talking about the agility of small teams and garage start-ups. Fewer people on a project means fewer lines of communciation, which means exponentially lower coordination costs. (side note: this idea is perfectly illustrated in Alex Komoroske's infamous Coordination Headwinds deck). The coordination overhead slows production to a halt, which is why Brooks's Law holds true. More people slows things down.

But most software cannot live in startup mode forever. If it's to succeed long-term, a software company's ambitions must grow, and to a scale that a two person team is not capable of achieving.

I know that the punditry is holding their breath for the one person, billion dollar company, believing that AI is going to make solo developers so incredibly productive that they can afford to go it alone. That sounds nice, and I'm confident that in some exceptional cases, it can happen.

Yet most people aren't the exceptions, and around here, I'm not interested in running on faith.

That's why chapter 3 is so good. Brooks mentions a proposal from Harlan Mills, which Mills successfully implemented at IBM: the surgical team.

The Surgical Team is modelled the structure of the operating room: everyone involved works in support of the surgeon. Unlike a hog butchering factory, where everyone is hacking away at the pig, the surgeon is the only one with the scalpel, and he's in charge. All other staff is present solely to improve the surgeon's effectiveness and productivity.

Mills calls this role the chief programmer, who "personally defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation."

This single person is responsible for every decision regarding the design and implementation of the software at hand. This has many advantages, and surprisingly few drawbacks. The idea is that one person can maintain the conceptual integrity of the application, and they don't have to waste any time arguing about design choices or any of the other silly things that bog down software teams. Whatever the chief says, goes.

In the book, Brooks lays out nine other roles to round out a 10-man team. Many of these roles have been made obsolete by software (like secretaries, although I believe that the loss of secretaries is a shame, for a variety of reasons), but Brooks lays out a good template for team composition.

A copilot is the chief programmer's right hand, or alter ego of the surgeon. This person is a chief programmer in training. They're capable of doing the job, but has less experience. The surgeon uses this person as a sounding board, because the copilot knows the entire system just as well as the boss. Still, they have no authority, and as such, aren't held accountable for any part of the system.

The administrator acts as a whip inside the company, making sure the chief program remains free of managerial drama so they can build their system.

There are more roles, which all help the chief programmer deliver high quality software. An editor makes sure that the "manuals" (the docs) are pristine, a toolsmith builds utilities that help the surgeon, a language lawyer who has mastery of programming language, so they can help make code more efficient and clean, and a tester, who is the surgeon's adversary, and tries their hardest to break the system.

It's not clear to me that this idea ever became mainstream, because it was so far ahead of my time. The idea is from a punch card era of programming, one where there were immense barriers to deploying code. I imagine that when everyone could run code on their own machine, and the bottlenecks of program management went away, management went full speed ahead. Throw more bodies at the problem, and let our version control tools figure things out.

Software creation has been a hog butchering operation for decades. But I think the time has come for The Surgical Team 2.0.

While the one person billion dollar company is a stretch, it seems likely that a new standard will be set. How small can you stay and still get to ten figures? According to Claude, Instagram has 12 people when they reached a billion. But let's consider them an exception, and realize that the media unicorn employs 700 people.

700! That's a lot of butts in a lot of seats!

I think that 10% of today's median, 70, is a realistic target, with 20-30 being engineers. 10 surgeons, 10 copilots, and 10 more supporting engineers for quality assurance, fine-tuning, and keeping environments snappy.

Aggressive? Certainly. But think about most software startups: do they have more than 10 "products", however you may define that? No, not really. Look at the sidebar nav in all the software you use. Are there more than 10 top-level items? I didn't think so.

Agentic coding tools mean that a single person can be responsible for an entire domain in a billion dollar startup. Maybe you're building the next Shopify. Do you really need more than one engineer to build the order management features? Or can a single person hold all the domain modelling in their head, design a beautful system, and ship so hard and so fast that the system gets better day after day?

I'm starting to get away from the thread that led me here.

5 days ago, me, Cursor, and Claude Sonnet 4.5 began building a Ruby on Rails app. It's goal: to build Klaviyo for direct mail. Allow Advertisers to sign themselves up, invite collaborators to their private workspace, integrate with their Shopify store to pull in CRM data, upload postcard creative files, and send campaigns to their customers.

I've worked for a direct mail software company for a few years now, and we've not been able to get this done, much to my dismay.

As a designer, I've had grand ambitions of building a multi-channel lifecycle marketing tool, one that allows advertisers to send email, SMS, postcards, and more to their customers.

It seems straightforward, but I guess most things that do are not.

Over tha last couple of years, I have tried and failed to make progress, with the help of our AI overlords. I don't have the backend chops to do it on my own, and while earlier AI models could help me make dents, I was never able to get something working in reasonable time.

But whatever vooodoo magic is happening at Cursor and Anthropic has changed that.

In 5 days, I shipped a functioning v1, with robust access control, usage-based billing, and a print-postage API.

And I think it's changed the direction of the company, if not only my career.

No, I'm not claiming to be the billion-dollar engineer, and my company isn't the 70-person unicorn. Not yet, anyway.

But what happened over those 5 days matters. One person, armed with AI, can ship big things fast. Really fast.

Mills's whole point with the surgical team was that ONE person writes all the code. The chief programmer is the only one with the scalpel. Everyone else is there to support them, to make them more effective.

That model got abandoned somewhere along the way. Tools proliferated, deployment barriers disappeared, and management said "why limit ourselves to one coder when we can have five?" Version control could handle it, right? So they threw bodies at problems, and we've been doing hog butchering ever since.

AI brings us back to the surgical model, but supercharged. One person can write all the code again because AI collapses both the mechanical work AND the knowledge barriers. The copilot role? That's Cursor and Claude. The toolsmith who builds utilities? AI can generate those. The language lawyer with deep framework knowledge? AI has that too.

But you still need people to keep the chief programmer honest.

There's a skillset I have that, paired with agentic coding tools, makes me capable of being a surgeon. Just enough back-end knowledge to architect the system, design sense to build something people actually want, front-end chops to ship a working interface, and product judgment to know what matters.

If I were deficient in design but world-class at backend, it wouldn't work. I'd get kneecapped by my own system rather than build something valuable for real people. If I were purely a designer with no technical chops, I'd never get past the implementation details.

AI amplifies these skills. It lets me execute on all of them at once. But it also hallucinates, writes suboptimal code, and generates verbose documentation that nobody can parse. That's where the support roles matter.

The modern surgical team still needs a language lawyer to catch when AI does something stupid. A toolsmith to maintain infrastructure. An editor to make documentation readable. A tester to break things. But these roles are shared across multiple surgical teams now. One language lawyer can keep three chief programmers honest. One toolsmith can maintain infrastructure for the whole company.

That's how you get from 200 engineers to 20-30.

Brooks was measuring in man-months because that was the atomic unit that mattered. But AI changes the unit of work. Meaningful progress happens in man-days now, sometimes man-hours.

That's not just faster—it's different. Coordination costs vanish because one person holds the system in their head. Conceptual integrity is guaranteed because there's only one cook. Iteration speed explodes because you can just change things without RFCs or three-day migration plans. Five days, one person, a functioning product with multitenancy, billing, and three API integrations. A 5-engineer team couldn't deliver less than that in three months.

Brooks was right: adding people to software projects slows them down. But he was working in an era where one person couldn't produce enough to matter. AI changed that calculation. Not for everyone—most engineers still can't ship alone. But for people with the right combination of skills, judgment, and taste, the new surgical team is you, your AI copilot, and a small support crew keeping you honest.

The one-person billion-dollar company might be a stretch. But 20 people doing what used to take 200? That's already happening.

The man-month is dead. Long live the man-day.