The hardest professional conversation I've ever had is one I had 44 times in a single week.
We had grown the Realm team from around 20 people to 68 across San Francisco and Copenhagen. It felt like we had graduated to the next level — the headcount of a real company, the organizational structure, the engineering capacity to build everything on the roadmap simultaneously. The product was working. The developer community was growing fast.
Then the fundraising market tightened. The C-round conversations that had been warm went cold almost overnight. We didn't have the revenue to support 68 people without that capital.
We cut from 68 to 24 employees. I was involved in all 44 conversations.
There's no way to make that experience not brutal. People had moved cities. Turned down other offers. Built things they were proud of. Some had equity that, at this point, was worth significantly less than they had been led to believe.
I'm not going to pretend that there's a management framework that makes this okay. There isn't. The responsibility for those 44 people's situations was partly mine — I had hired them into a company burning capital against a fundraising plan that didn't materialize, and I had not managed burn aggressively enough to give us more options when the market changed.
What I walked away with, permanently, was a principle I haven't compromised since: fundraising is optional, not a necessity.
This sounds obvious. It is not obvious when you're in a growth phase and the capital is available and there are things you could build with more engineers.
The temptation to raise and spend is not irrational. More engineers means more velocity means more product means better fundraising leverage for the next round. The logic is real. It's also dangerous, because it only works if the next round materializes.
The risk I miscalculated was the asymmetry: if the next round comes, aggressive hiring accelerates the trajectory. If the next round doesn't come, aggressive hiring creates a situation where you're responsible for 44 difficult conversations with people who trusted you with their careers.
The company has to be able to survive without the next round. Not "survive uncomfortably" — survive and continue to build. If it can't, you've already lost control, whether or not the next round ultimately closes.
After cutting to 24, we rebuilt. The engineers who stayed were exceptional, and the leaner team moved faster in some ways than the 68-person team had. Decisions happened faster. There was less coordination overhead. People could hold the whole system in their heads again.
The most significant one was the synchronization architecture. We had been circling the sync problem with the larger team — there were competing proposals, ongoing debates about the protocol design, and a general sense that the problem was hard enough to require more people on it. After the cut, we had a small group who had the deepest context on the storage engine, and the decision about how to approach sync became much cleaner quickly. Not because the smaller team was smarter. Because the smaller team had less coordination overhead, clearer ownership, and enough shared context to move through the design questions without relitigating fundamentals in every meeting. The sync architecture that we shipped was better than anything we had produced in the larger-team design phase. I don't think it would have been, if we had kept all 68 people working on it.
This isn't an argument for keeping teams small indefinitely. It's an observation that the productivity relationship between headcount and output is not linear, and the non-linearity is much larger than most founders account for when they have fresh capital.
The right size for an engineering team is the size where the communication overhead is low enough that smart people can do their best work. Where that point is depends on the kind of work — a team building a complex distributed system needs different coordination than a team with a tightly scoped feature set — but it's almost always smaller than founders think when they're looking at a full bank account.
The lesson I try to give founders who are building their first engineering teams:
Hire for the problem you have now, not the problem you'll have in twelve months. Build the processes that can scale before you hire people to fill the slots those processes require. Treat every hire as a permanent commitment — not because the commitment is actually permanent, but because thinking about it that way changes which hires you make and how quickly you make them.
And keep the company capable of surviving without the next round. Not as a pessimistic contingency. As a discipline that keeps you honest about what you're actually building, why you need the people you're hiring to build it, and whether the business can stand on its own.
Fundraising is optional, not a necessity. The team you're accountable for is not.