Scaling Beyond the Founder

In Q3 2018, 25% of companies that raised a Series A made it to Series B within two years. By Q3 2022, that number was 9%. The crunch is real, and most of the post-mortems blame the macro: ZIRP ended, multiples compressed, capital got scarce. That story is true. It is also incomplete.

The other story — the one we see in the diligence calls, in the board decks, in the 1:1s with founders who are exhausted but cannot say why — is that the company never built the operating system that the Series A was supposed to fund. The product worked. The team grew. The founder kept being the founder. And somewhere between $3M and $30M of ARR, the founder became the bottleneck of their own company.

This is the most undermanaged crisis in venture-backed companies. Not product. Not GTM. Not even hiring. The crisis is the transition from "founder-led" to "systems-led," and 80% of the companies that stall after Series A stall here.

The fix is not delegation training. It is not hiring a better COO. It is not reading No Rules Rules on the flight back from the offsite. The fix is architectural. You codify decisions into systems, you replace founder presence with operating cadence, and you accept that your role morphs from the person doing the work to the person designing the system that designs the systems.

This memo is the framework. What to systematize. What to keep. What to let go.

The bottleneck is mathematical, not psychological

Most discussions of founder scaling start with the founder's psychology — ego, control, fear of letting go. That framing is wrong, or at least secondary. The first problem is arithmetic.

Communication channels in an organization grow by n(n-1)/2. Ten people: 45 channels. Fifty: 1,225. A hundred and fifty: 11,175. A founder who was the central node at twelve people is, at a hundred and fifty, theoretically connected to over eleven thousand pairwise relationships (Dunbar's number, applied). Their working memory has not changed. Their calendar still has 168 hours in it. The org has scaled. The founder has not. There is no amount of grit that closes that gap.

HBS researchers Michael Porter and Nitin Nohria tracked CEO calendars 24/7 for thirteen weeks. Their finding that gets quoted is that CEOs spend 21% of time on strategy. The finding that should get quoted is that they spend just 3% with customers, and that the average CEO works 9.7 hours a weekday, 79% of weekend days, and 70% of vacation days. The person at the top of a scaled company is not under-allocated. They are saturated. Adding another meeting to their calendar is not "more leadership." It is queueing theory: the moment the founder's queue depth exceeds their service rate, every decision routed through them gets older. Decision latency, not decision quality, becomes the ceiling on the company.

This is what the Series B-to-C stall actually looks like from the inside. Engineering can't ship because the spec needs a CEO sign-off that's three weeks behind. Sales can't close because pricing exceptions queue at the founder's desk. The board asks why ARR per employee is dropping and the honest answer is: every new hire added latency, not throughput, because the founder is still the routing layer.

What "Founder Mode" actually says, and what it doesn't

In September 2024, Paul Graham published "Founder Mode", based partly on a Brian Chesky talk at YC. The essay claimed that the conventional advice — "hire good people and give them room to do their jobs" — was a trap, and that founders should run companies through "skip-level" engagement rather than the manager's clean org-chart layers.

The essay was right about something narrow and wrong about something broad.

It was right that absentee delegation is a failure mode. Chesky himself has said he over-delegated for years and "wasn't making enough decisions." It was right that founders carry information — about the original promise of the product, about why a tradeoff was made in 2014, about the customer's actual face — that no consultant-CEO can replicate. And it was right that the McKinsey-style "professional manager" archetype has, for some companies, been a slow form of organizational decay.

It was wrong about almost everything else. The essay never defined what founder mode is in operational terms. As Shreyas Doshi and others noted, the prescription collapsed into "be more like Steve Jobs," which is unfalsifiable advice. Worse, it gave thousands of mid-stage founders a permission slip to micromanage their VPs and call it leadership. Chesky himself clarified, "I never called it founder mode," and warned the term would be misused. It has been.

Here is the more honest framing. "Founder mode" is not a mode you switch into. It is a set of decisions you do not delegate, embedded in a system that delegates everything else. The trap is treating it as a personality trait instead of a design problem.

Codify decisions before you delegate them

The single most under-built artifact in Series A and Series B companies is a decision log. Not a project tracker. Not Notion pages with meeting notes. A versioned, searchable record of what was decided, by whom, with what reasoning, and what would change our minds.

Stripe is the canonical example. Patrick Collison's emails were structured like research papers, with footnotes. Project kickoffs at Stripe begin with a written memo — goal, assumptions, risks, success metrics — read silently in the room before anyone speaks. This is not a literary affectation. It is a decision-compression algorithm. A two-page memo, read by twelve people, replaces a forty-five-minute meeting where the loudest voice wins, and it leaves an artifact the next twelve people can read without rerunning the meeting.

Bridgewater took the idea further with the Dot Collector — every meeting produces structured ratings of arguments, weighted by historical believability, fed into a decision algorithm. You don't have to like the Bridgewater culture to take the lesson: when decisions are recorded, they compound. When they are spoken, they evaporate.

Choose a frame and use it. RAPID, DACI, and RACI all work; the discipline is what matters. RAPID (Recommend, Agree, Perform, Input, Decide) is overkill for routine calls but right for irreversible ones — repricing, reorgs, top-of-funnel pivots. DACI is the right default for product and operating decisions in a fast org because it names one driver and one approver and routes input around them. RACI is for execution after the decision is made.

The mistake is not which framework. The mistake is having no framework — which means every decision implicitly routes to "ask the founder," and the founder becomes the queue.

The Amazon move: single-threaded ownership

Amazon's most exportable management invention is not Working Backwards or the six-pager. It is the Single-Threaded Leader (STL). The premise: any initiative important enough to fund deserves one person whose entire job is its success — no shared responsibility, no committee, no part-time ownership. The STL has the mandate, the team, and the metric. They do not need permission to make 90% of the calls inside their scope.

The reason this works is not Amazon scale. It is Amazon's understanding that dependencies kill speed before headcount kills it. A VP of Engineering owning fifteen initiatives has fifteen queues. An STL owning one initiative has one. The founder's job is to set the initiatives, fund them, choose the STLs, and then — and this is the part most founders cannot do — stay out of the queue.

In practice, for a Series B company, this looks like:

• Three to seven STLs, each owning a major bet (a market expansion, a platform layer, a regulatory effort).
• Each STL has a written charter — not a job description. The charter names the bet, the success metric, the budget, the time horizon, and the decisions the STL has authority over without escalation.
• A weekly thirty-minute review per STL, written-first. The founder reads, comments in the doc, and only takes the meeting if the doc surfaces a decision the founder must make.
• The founder is not in the STL's standups, not in their hiring loops below the director level, and not in their customer calls except by explicit invitation.

The founders who reject this almost always cite the same reason: "I'm faster than my STLs." That is true and irrelevant. You are one person making a hundred decisions a day at 80% quality. Five STLs make five hundred decisions a day at 75% quality. The system wins by volume and by parallelism. Your speed is not the bottleneck. Your centrality is.

Operating cadence is the replacement for founder presence

There is a thing founders do early on that creates enormous value and becomes lethal at scale. They walk the floor. They sit in the customer call. They review the design. They notice the small thing. The team feels the founder's attention, and the work gets sharper.

You cannot do this for two hundred people. You can try, and you will fail, and the team will get worse not better, because half of them will perform for you and the other half will hide.

The replacement is not "trust your team." That is a slogan, not a system. The replacement is operating cadence — a fixed, public rhythm of writing, review, and decision that creates the same compression and accountability without requiring you to be in the room.

The minimum viable cadence for a Series B company:

• Weekly: Each function head publishes a written status — three sentences on what shipped, what slipped, and what is blocked. Public. Five-minute read.
• Bi-weekly: A business review across the leadership team, driven by a single document. No slides. The document has the metrics, the narrative, and the open decisions. Read silently for twenty minutes. Discuss for forty.
• Monthly: A founder's letter to the company. Not motivational. Strategic. What changed. What we learned. What we're betting on this month and why.
• Quarterly: A planning document. Not OKRs as theater. A short list of bets, with owners and metrics, derived from the founder's strategic memo.
• Annually: A long-form strategy memo. The Stripe / Bezos / Collison move. This is the document that justifies your next two years of capital allocation.

GitLab runs a 2,700-page handbook, public-by-default, as the company's source of truth. You probably don't need 2,700 pages. You do need the discipline that produces them: a culture where the answer to "how do we do X here?" is "it's written down."

Hire for the operating system, not the resume

The most expensive hiring mistake at Series B is hiring for credentials over operating-system fit. The ex-Google VP joins, the ex-Salesforce SVP joins, the ex-McKinsey partner joins. They are competent. They have run things bigger than yours. And they break.

They break because they came from a company with a working operating system, and they assume yours has one. It does not. They came from an org where decisions were already routed, escalation paths were known, and the documentation existed. Yours has a founder who answers everything in Slack. The senior hire spends three months waiting for the system they're supposed to plug into. Then they leave, or worse, build their own private system that conflicts with everyone else's.

The right sequence for most Series B founders is Chief of Staff before COO. The Chief of Staff makes the founder more leveraged within the existing system. They build the cadence, run the planning, edit the memos, and audit the founder's calendar. They are cheap, fast, and replaceable. The COO replaces the system itself, and you should not hire one until you can describe the system clearly enough that someone else could run it.

Noam Wasserman's research found that by year three, half of founders are no longer CEO of the company they founded, and fewer than 25% lead their companies to an IPO. The lesson read most often is "founders get pushed out." The lesson most worth reading is the opposite: the founders who survive the transition are the ones who began designing themselves out of the daily critical path before the board started counting. Kalanick and Neumann are remembered as ousters. They are also case studies in what happens when the founder is the system, and the system has to be removed.

What to keep doing yourself

The mistake on the other side of over-delegation is just as costly. There are things only the founder can do, and abdicating them is what makes a company drift into the bland, slow, brand-decayed organization that founder-mode-Twitter loves to dunk on.

Keep these:

1. Hiring of senior leadership. VP and above. You should personally close every senior hire. Not screen — close. The leverage is asymmetric: a great VP fixes the system around them; a wrong VP corrupts it for two years.
2. Critical strategic memos. The annual strategy memo and the quarterly bet list. You can have help editing. You cannot delegate the having of the opinions.
3. The top-twenty customers and the top-five investors. Not because no one else can manage these relationships. Because the information you collect from them is the input to every other decision you make. A founder who learns the customer narrative from a CRM is a founder making bad calls.
4. Cultural artifacts. The rituals. The vocabulary. The all-hands tone. Culture is what people do when you're not watching, but it's set by what you do when you are. Lütke's "trust battery" is a Shopify artifact because Lütke uses the term every week. The CEO who outsources culture-setting to a Chief People Officer is outsourcing the soul.
5. The hard "no." Killing a project. Firing a senior person. Walking away from a deal that doesn't fit the strategy. These are unpleasant and costly to delegate; the second-order effects of getting them wrong are worse.

Everything else is, in principle, designable into the system.

The counterargument: when founder intensity is the moat

Now the inconvenient part of this memo. There are companies where founder-led intensity is not a stage — it's the moat.

Anduril raised $2.5B at a $30B valuation in 2024 because Palmer Luckey is in every product review, every Pentagon meeting, every prototype test. SpaceX runs because Musk is at McGregor on Saturdays. OpenAI's culture, for better and worse, is downstream of Sam Altman's specific weekly cadence. Oxide Computer's response to the Founder Mode essay made the point cleanly: in deeply technical, capital-intensive, regulated, or contrarian domains, the founder cannot delegate technical judgment, because the judgment is the company.

This memo is not an argument for absentee CEO-ing. It is an argument for intentional presence. The Anduril founder is not in every meeting because he hasn't built systems. He is in the meetings he's in because the system is designed to put him there. Everything else still runs without him.

The test: if you removed yourself from your calendar for two weeks, what breaks? If the answer is "the company drifts" — you have a system. If the answer is "specific deals stall, specific hires can't close, specific product calls don't ship" — those are your founder-decisions, and the rest is either delegable or already broken. Map them. That is your founder-mode list, and it should fit on an index card.

Closing: the question to ask in your next 1:1

Most founders think the question is how do I hire better. It is not. The question is: what would a system that does my job look like, and what's the smallest version of it I can build this quarter?

Start with the decision log. Pick one frame — DACI is a good default — and apply it to the next ten material decisions. Hire a Chief of Staff before you hire a COO. Write the quarterly bets memo yourself; ask the team to read it silently before the planning meeting. Stop attending standups. Audit your calendar against your founder-decision list and delete anything that isn't on it.

Then watch what happens. The companies that make it from Series A to Series C in this market are not the ones with the best founders. They are the ones whose founders, somewhere between $5M and $25M of ARR, stopped being the answer and started being the architect.

The fund-defining companies of the next decade will be built by founders who figured this out before the board had to figure it out for them.