Stop Hiring Your Way Out of a Systems Problem

Most early-stage founders trying to hire a CTO are trying to hire away an infrastructure gap.

You've read the founder advice. You've talked to two recruiters. You've quietly looked at the LinkedIn profiles of three CTOs at companies you respect. You've started telling yourself the story: the missing piece is a heavy hitter.

You're going to hire a CTO.

You'll write the offer letter this weekend. You'll give up 8-15% of the cap table. You'll spend the next quarter onboarding them. You'll feel, for the first six months, like the company is finally serious.

Then you'll watch them quietly redesign the deploy pipeline for the company you'll be in 2030 instead of the company you actually are in 2026, and at month nine you'll wonder why you don't feel any less stuck than you did before they started.

You don't have a CTO problem.

You have a systems problem, and you are about to spend $300K to dress it up as a hire.

Fred Brooks named this in 1975

The most-cited book in software management is Fred Brooks's The Mythical Man-Month. Brooks managed the development of IBM's OS/360 in the 1960s, ran into every disaster a software project can run into, and wrote up the lessons in 1975. The book is almost old enough to qualify for Medicare and is still on every working CTO's reading list.

The most-quoted sentence is now known as Brooks's Law.

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

The reason isn't intuitive. Brooks's argument was that complexity in software comes from communication overhead. Each new person you add to a project doesn't add one unit of work. They add one unit of work and N units of new conversations between themselves and every other person who has to coordinate with them. Past a certain size the conversations grow faster than the work does.

What Brooks was really saying, behind the law that has his name on it, is that hiring is an answer to a specific kind of problem. It is not the answer to every kind of problem. Most founders, when they hit a wall, reach for a hire because hiring is the move you make when you have money and don't know what else to do.

Hiring is the move when the system is right and the throughput is wrong.

If the system isn't right, hiring slows you down.

What 32 engineers built

In February 2014, Facebook bought WhatsApp for $19 billion. The number that gets quoted is the price. The number that should get quoted is the headcount.

When the deal closed, WhatsApp had 55 employees. 32 of them were engineers. Those 32 engineers were running a service used by 450 million monthly active users, processing 18 billion messages a day, across 180 countries.

For comparison: at the time of the acquisition, the average ratio at WhatsApp was about one engineer per 14 million users. The industry-average ratio that year was closer to one engineer per 60,000 users.

The story isn't that WhatsApp had magical engineers, though they were good. The story is that Jan Koum and Brian Acton built an opinionated technical system before they built a team. They picked Erlang, a programming language designed for telecom switches, because it handled massive concurrency natively. They ran on bare metal in a single colocation facility because cloud was too expensive at their scale. They refused to add advertising or games because both would have required tripling the team to support.

The 32 engineers were possible because the system did most of the work.

If WhatsApp had hired a "real" CTO at year three to "professionalize" the operation, the most likely outcome is they would have tripled the team and shipped a worse product. The simplicity was the moat. A heavy-hitter CTO almost always optimizes against simplicity, because there is no career upside in being the executive who said "we don't need to add anything."

What 37signals keeps proving

37signals — the company that builds Basecamp and HEY — has roughly 80 employees as of 2025. They have shipped products at scale for over 20 years. They have publicly turned down growth opportunities, refused outside investment, and stayed deliberately small.

Jason Fried and David Heinemeier Hansson have written about why for two decades. The argument is consistent. Once you cross a team size threshold, most of your time goes to coordination instead of work. Adding heads makes the calendar look fuller. It doesn't make the product better.

The 37signals operating system is a small set of decisions, made once, that scale. Six-week cycles. Two-person teams (one programmer, one designer) per cycle. No standing meetings. No persistent project chat. Written communication over verbal. Deliberate cooldown weeks between cycles.

Notice what isn't on the list. They don't have a CTO. They have a co-founder, DHH, who writes code, and a co-founder, Jason Fried, who writes strategy. They have technical leads who emerge from the work. They've never hired a "Chief X Officer" to fix a problem.

Their thesis: the operating system is the leadership layer. If you have one, you don't need a hire to install one.

Three diagnostic questions before you write the offer

You don't need a CTO yet. You might never need one. Before you spend $300K and 12% of the cap table, run yourself through three diagnostic questions.

1. Is the work breaking, or is the operator breaking? If your bugs are stacking up, your deploys are getting scary, and your product is genuinely growing past what one or two engineers can hold, that's a work-breaking signal. Hire. If the bugs are normal but you can't keep up because you're doing 14 things, that's an operator-breaking signal. You don't need a CTO. You need a Build Audit and a system.

2. What would the CTO's first 90 days actually contain? Write the 90-day plan. Be honest. If the answer is "introduce a roadmap, set up sprints, document the architecture" — those aren't CTO outputs. Those are systems outputs. You can install them in 6 weeks for the cost of a build partnership.

3. Are you looking for a person or for a permission slip? A lot of founders hire because the hire makes them feel like a real company. That's an identity move, not a strategic move. The market doesn't care that you have a CTO. The market cares whether you ship.

If you ran those three questions and you can't write the 90-day plan, you don't need a CTO. You need scope lock and an operating cadence.

When you actually do need a full-time CTO

Hire one when:

• You have 12+ engineers who need career architecture, not just code review
• Your product is in a genuinely high-stakes technical domain (financial infrastructure, safety-critical systems, cryptography) where wrong calls in year one cost millions in year three
• You have an 18-month roadmap with enough novel architecture work to fill 40 hours a week
• A category-defining hire is a fundraising signal you genuinely need

If two or more of those don't apply yet, you don't have a CTO problem. You have a structure problem.

The reframe

You're not falling behind because you lack a Chief Technology Officer.

You're falling behind because you're trying to run a system that doesn't exist yet through sheer competence, and competence is a finite thing.

You don't need a $300K hire. You need a six-week scope lock, a written operating cadence, and one person whose job is to read your work weekly and tell you what to cut.

That's not a CTO. That's a build partnership.

Pick one. Install it. See if the "I need a CTO" feeling goes away.

It usually does.

If you're trying to figure out whether you need a person or a system, book a free build partner call. That's where we start.