The Part That Doesn't Scale
People are the hardest part of a software team to scale. Instead of one ever-bigger team, run small factories, each overseen by one person who owns the strategy before the doing and the efficiency after it. One bug from my own factory shows how.
The short version
1-minute readPeople are the hardest part of a software team to scale. Teams try: they hire, add layers and add process. Past a point, each new person brings more coordination than output, and the whole team slows down.
I think there's a better shape: small, modular factories, each run by one person who oversees not just what it produces but how efficiently it produces it. That person's value is the strategy before the doing and the efficiency after it.
"The value you need from them isn't the doing... It's all the things before and after the doing."
Me, on what your people are for
That's how I work now. The workers in my factory are AI agents, and I'm the only person on the floor. I can't scale me, so I built it to spend me before and after the doing. Here's how that played out on one bug in my game.
"I have not yet reproduced the flicker"
I filed a bug at 10:22 PM: a screen in my game "frequently flickers where it appears the content is moving vertically during some scrolling." Eight minutes later the Implementation agent had checked 180 frames at three screen sizes, found nothing, and asked me for a recording and a save.
It was a fair question. But if I'd answered it, the person running the floor would have stepped back onto a machine.
The supervisor answers first
My agents take their questions to a supervisor agent before they reach me. It answers whatever my past decisions already settle. Three minutes later it answered this one: you tested a scrolling bug on a page with nothing to scroll. Spend 20 minutes on one that overflows, then ask Rudy.
Five minutes later the agent had found a real defect: dragging the scrollbar made the page jump backward. The fix was committed by 10:51 PM, and the full test suite passed by 11:24 PM. I didn't step in once.
Where my time went instead
I was working on other projects the whole time. When I checked in, one thread showed me where the agent got stuck, how the supervisor responded and why, and what came of it. I clicked Agree and moved on. When I disagree with a call, I say why, and that reasoning goes into the supervisor's memory for the next one.
That's the after: reviewing the friction and tuning how the team works, not making the call myself. The before is the same idea: I put the most capable thinking into supervision and planning, and cheaper models into execution. Every ticket ships something, and every ticket teaches the team something about the next one.
"I can't scale me. My thinking, decisioning, and communicating is not a resource I've yet learned how to containerize."
Me, on the part that doesn't scale
Run the floor, not one machine
Swap my agents for engineers and the lesson holds. The most valuable thing your people do isn't the doing. It's the strategy before it: deciding what's worth building and what good looks like. And it's the efficiency after it: seeing where the work got stuck and making the next round go better.
That's why I'd grow with more small factories rather than one bigger team. Each person runs a floor and owns both what it ships and how well it ships. As agents take on more of the doing, I think we'll find that each person is worth more running a factory floor than working as one machine on it.
Before: set the direction
Decide what's worth building and what good looks like, then let the work run.
After: review the friction
Where the work got stuck and how it was handled tells you what to change next.
Write down the why
Decisions with their reasons let the next call happen without you.
Improve the delivery, not just the ticket
Each piece of work should make the next one go better.