In 2019, a fintech startup based in Austin had what looked like a clean problem. Their sole engineer, call him Marcus, was good. He’d built the core product in nine months, found product-market fit, and was now the bottleneck on everything. The founders raised a seed round, hired a second engineer with comparable skills, and waited for output to double.
It didn’t. In fact, for about six weeks, meaningful feature velocity dropped to near zero.
This is not a story about a bad hire. It’s a story about a fundamental misunderstanding of how software development scales, one that costs startups real money and real time every year.
The Setup
Marcus had built something that worked, but he had built it the way solo engineers do: fast, pragmatic, and almost entirely inside his own head. The architecture made sense to him because he had made thousands of small decisions over nine months, none of which were written down. Variable names were consistent in ways only he understood. There was one deployment process, and it lived in a shell script in his home directory on a server he’d provisioned manually.
The second engineer, let’s call her Priya, was capable. She had shipped production code before. She was not incompetent. She was simply dropped into someone else’s brain and told to start adding rooms.
What followed was textbook. Priya needed to understand the codebase before she could contribute. Understanding required Marcus’s time. Marcus’s time was finite. Every hour Marcus spent onboarding Priya was an hour he wasn’t shipping. For the first two weeks, Priya produced almost nothing and consumed roughly forty percent of Marcus’s capacity. Net output fell.
What Happened
This is the pattern Fred Brooks documented in The Mythical Man-Month in 1975. His observation, now usually called Brooks’ Law, is blunt: adding people to a late software project makes it later. The mechanism is communication overhead. Two engineers don’t produce twice the output of one; they produce something less, because they must now coordinate. As team size grows, the number of communication channels grows combinatorially. One engineer: zero channels. Two engineers: one channel. Five engineers: ten channels. Ten engineers: forty-five channels.
Brooks wasn’t writing about early-stage startups specifically, but the underlying math doesn’t care about your funding stage.
What made the Austin case interesting wasn’t the slowdown itself, which was predictable in retrospect. It was what the founders did next. Convinced the problem was onboarding friction, they spent three weeks having Marcus write documentation. Documentation that, by the time it was finished, was already partially out of date, because Marcus had continued building while writing it.
The documentation project consumed another chunk of Marcus’s capacity while producing an artifact of uncertain value. The founders had correctly diagnosed a symptom (Priya couldn’t understand the codebase) and prescribed a solution (write it down) without asking whether the underlying investment made sense at all.
Why It Matters
The startup had hired Priya for the wrong reasons at the wrong time. They hired her because Marcus was the bottleneck. But they hadn’t asked the sharper question: was Marcus the bottleneck on things that actually mattered right now?
In the three months before Priya joined, Marcus had shipped two major features that directly drove conversion. He had also spent time on internal tooling, on refactoring code that annoyed him, and on a mobile-responsive redesign that users had not asked for. Roughly a third of his output was going to work that didn’t move the business.
A second engineer didn’t fix this. It actually made it worse, because now there were two engineers who needed alignment on priorities, and the founders weren’t providing it clearly enough. The coordination overhead wasn’t just technical. It was managerial.
This is the part of the Brooks’ Law story that usually gets left out. The law is about communication costs, but communication costs aren’t just about code review and pull requests. They’re about every meeting where someone has to ask what to build next, every Slack thread debating an architectural decision, every moment of duplicated effort because two people didn’t know the other was working on the same problem.
Priya eventually got up to speed. Four months after joining, the team was genuinely faster than Marcus alone had been. But four months is a long time at a seed-stage company. The founders had modeled the hire as an immediate doubling of output. What they got was a four-month dip followed by a gradual climb to something like 1.6x throughput, not 2x, because of the permanent overhead that comes with coordination.
What We Can Learn
The first lesson is about timing. Hiring a second engineer makes sense when your documented, repeatable work exceeds what one person can do. It makes much less sense when your bottleneck is unclear thinking about what to build. Adding headcount to an unclear roadmap doesn’t accelerate the roadmap. It multiplies the confusion.
The second lesson is about what you’re actually buying. A second engineer doesn’t buy you double the output. It buys you parallelism on independent work streams, some redundancy against bus-factor risk, and a second perspective on hard technical decisions. Those are real benefits. But they have real costs attached, and the costs are front-loaded. If your runway is measured in months, not years, those costs can be fatal.
The third lesson is about the knowledge transfer problem specifically. Solo engineers build systems that reflect their mental models. Before you hire someone to work inside that system, you need to externalize the model enough that it survives contact with a new mind. This doesn’t have to mean comprehensive documentation. It can mean pair programming sessions, recorded architecture walkthroughs, or simply being honest about which parts of the codebase are landmines. But it has to happen before the hire, or you’re paying for the externalization process at the worst possible time.
The Austin startup survived. They raised a Series A, eventually grew to a team of eight, and the early scaling pains became a footnote. But the founders, interviewed later, were clear: they would have hired Priya three months later than they did, after cleaning up the codebase, after tightening the roadmap, and after accepting that they were optimizing for the feeling of momentum rather than its substance.
The feeling of momentum is seductive. Two engineers looks like more than one. The math says otherwise.
