Pre-read for the learning session.
This document has two parts that belong together. Part I — "How we ship" is the applied memo: how we ship by September 1. Part II — "Founder Mode, in detail" is the idea behind it, pulled from the original sources. Read them in order, or jump to the part you want.
How the fastest teams ship — and what to borrow.
How the fastest AI-native teams work — and an honest set of questions about what actually applies to Bono before September 1.
Before the retreat, we went looking for one honest answer: how do the teams that ship in days — not months — actually work? Two sources answer it best. One is an interview with Cat Wu, who leads product for Claude Code and Cowork at Anthropic, a team shipping a fast-moving AI product on a weekly cadence. The other is an internal Anthropic study of how 132 of its own people, technical and not, changed the way they work day to day. Together they cover both halves of our question: how a fast team operates, and how AI actually changes everyday work across every function — not only engineering.
Two cautions before we start. First, Anthropic is not Bono. They build frontier models, with a particular team and a particular culture; some of what makes them fast may simply not transfer, and pretending it will would be dishonest. Second, this note is meant to open a conversation, not settle one. So as you read, the useful question isn't "why don't we already do this?" — it's "which of this is real for us, and which isn't?"
When building gets cheap, the bottleneck moves
AI has made the act of building nearly free and nearly instant. But if building is free, the constraint stops being the building — it moves to deciding what to build, to coordination, to verification, and to focus. The Anthropic study puts numbers on the shift: Claude usage there doubled, from 28% to 59% of daily work; self-reported productivity rose from 20% to 50% in a single year; feature-implementation work grew from 14% to 37% of the total; and more than a quarter of the AI-assisted work simply would not have happened otherwise. They don't do the same amount of work faster — they do more, and more ambitious, work.
This is the Lean Startup logic we already use: when building is cheap, the value moves to deciding correctly what to build, and learning fast from contact with reality. It also matches our own recent weeks, where most of the effort has gone into wiring systems together, testing on real data, and integration — the connective work that doesn't get cheaper just because the code does.
Is building still a constraint for us? If yes, why? If not, what is actually slowing our delivery — and how much of it is decisions waiting, hand-offs queuing, or too many things open at once?
Their speed came from less process — not a better model
The most counterintuitive point Cat Wu makes is that the model is not the main reason they're fast. The bigger reasons are cultural. They run on very little process and actively try to remove every barrier to shipping, to the point that anyone on the team can take an idea from a thought to something live in under a week. The principle they keep repeating is almost embarrassingly simple: "just do things."
What replaces approvals is the interesting part: a weekly metrics read-out with the whole team. Everyone sees the same numbers and understands the goals, so people can decide on their own instead of routing decisions up a chain. Shared context does the job that committees and sign-offs do elsewhere — only far faster.
Two things worth debating: where do approvals or hand-offs add time without adding quality? And could a shared, weekly metrics read-out give us enough alignment to need fewer approvals — or do we not yet have the metrics that would make that safe?
They ship weekly, in preview, to learn
Their cadence is deliberate. Features go out every week, often as a research preview, specifically to gather real feedback rather than waiting for polish. They've made shipping a standing rhythm — a permanent "launch room" — so that putting something in front of users is the default, not a special event. That cadence is a big part of how their timelines fell from roughly six months to a month, sometimes a week, sometimes a single day. And the bar for "shipped" isn't "95% there" — it's genuinely useful, on something they would use themselves.
For us this needs an honest filter. Accounting is not a place to ship loosely — a wrong number has real consequences for a client, and trust is hard to win back. But plenty of what we're building is not the filing itself: the waiting list, the client dashboard, onboarding, internal tools. Those are exactly where shipping early to learn is cheap and safe.
Where can we "ship to learn" safely, and where can't we? Drawing that line is one of the most useful things we can do in the session.
They build before the thing is fully ready
A recurring theme: they deliberately build products that don't fully work yet, so they're ready to ship the moment the missing piece lands. They plan backward from where the technology is heading, not from today's limits. The cost of building something slightly too early is small; the cost of starting late is not.
The company-formation flow is a good test: signature, KYC and the registry steps don't all have to be finished before we wire the rest and rehearse the full journey. Where are we waiting for "everything to be ready" on parts of the launch we could be building in parallel right now?
Intelligence to the machine, judgment to us
The most practical part of the Anthropic study is a simple rule for where AI is worth using. Give the machine work that is easy to verify, simple, well-defined, repetitive, or outside your own expertise — and keep for yourself the work that is creative and demands judgment. Their half-joking heuristic rings true: the more excited you are about a task, the more likely you do it yourself; the more repetitive it is, the more likely you hand it over. And they treat verification as a real skill — building evals, systematic ways to test what the AI produced, and even asking the model to find its own mistakes.
Some of this seems to map — receipt processing, document generation and repetitive filings look like autopilot candidates; accounting interpretation looks like AI-suggests / human-decides; legal and client calls look like judgment that stays with a person. But that's a guess. Drawing this map honestly, workstream by workstream — and naming where verification must stay human — is exactly what the session is for.
The people who own the whole thing
At Anthropic the lines between roles blur — PMs do engineering, engineers do product, designers touch code — and an engineer can carry something from a user's comment to a shipped product in the same week, with almost no hand-off. Their claim is blunt: merging roles that overlap beats inflating separate silos.
This is where the caution matters most, so let's say it plainly: we are not them, and a single owner will not make shipping easy for us overnight. The fair question for us isn't "why don't we ship like that" — it's whether AI now lets one person carry more of a deliverable than the old split assumed.
Does our "Analysis / Implementation / Review" split improve quality, or mostly add queues? Where would a single end-to-end owner genuinely help, and where would it break? And who, realistically, becomes the bottleneck today — and how do we unblock them?
"Done" is a definition, not a feeling
One detail worth borrowing outright: their bar isn't "I worked on this," it's "this delivers value." Without a shared definition of done, a deadline is just an opinion — everyone privately believes a different version of finished.
Every V0 item gets three things written down: an owner, a hard deadline, and a definition of "done." For the accounting flow, "done" might mean a real test company's books closed and the D300 generated and independently verified — not "the module runs." Is that the right discipline for us, and what should "done" mean for each launch deliverable?
Two ways to read the next 11 weeks
One way to frame the choice in front of us — worth pressure-testing together, not simply accepting. We can keep working the way we do, which feels safe because it's familiar. Or we can change how we work now — fewer things in parallel, clearer ownership, shipping-to-learn where it's safe — and accept a short adjustment cost in exchange for moving faster toward launch. We have one advantage many companies don't: no legacy to tear down. We can choose how we work.
What the session is for
We won't settle all of this in a pre-read; the learning session is where we do. What we'll try to walk out with:
- an AI map for each workstream — what's Autopilot, what's Copilot, what stays Human;
- a few working rules we actually agree to;
- and, for the V0 items, owners, deadlines, and definitions of "done."
The questions on the table:
- What has actually slowed our delivery — and what is within our power to change?
- Where does AI help most, and where do we consciously decide it stays with a human?
- What does "done" mean for each V0 deliverable — and what hard deadline do we give it?
- How do we hold a cadence (daily / weekly) so deadlines are real, not aspirational?
- What are the three rules that would make us faster on the road to September 1?
Anthropic's answer won't be ours wholesale — but the questions are exactly the ones worth arguing about before September 1. Come ready to disagree, to cut, and to decide what's actually ours to copy.
Founder Mode, in detail.
The term became a meme within days — which blurred what it actually means. This part pulls together the three sources that matter — Paul Graham's essay, Brian Chesky's Decoder interview with Nilay Patel, and his Rotman Q&A — to get the concept straight, not the slogan.
Where the term came from
In September 2024, Paul Graham published a short essay built on a talk Brian Chesky had given at a YC event. Graham says it was one of the best talks the founders in the room had ever heard — Ron Conway, he notes, forgot to take notes for the first time. One point of hygiene before anything else: Chesky didn't invent the phrase "founder mode." He described a set of principles; Graham put the label on them.
Chesky's thesis was that the conventional wisdom about running a large company is wrong. As Airbnb grew, well-meaning people advised him to switch to a different way of leading — optimistically summarized as "hire good people and give them room to do their jobs." He followed the advice, and the results, in his words, were disastrous. He had to find a better way largely on his own, studying in part how Steve Jobs ran Apple. At the event, founder after founder confirmed the same thing had happened to them. Graham's sharpest framing is that these founders built extraordinary companies despite the standard advice, not because of it.
Two ways to run a company
Graham's question is why every one of these founders was told the same wrong thing. His answer — the heart of the concept — is that they were being taught how to run a company they hadn't founded. That is manager mode. And it is so much less effective for a founder that it feels broken.
Treat the branches of the org chart as black boxes. Tell your direct reports what to do; they handle the "how." Don't go into the details — that would be micromanagement, and micromanagement is bad.
The founder does things a manager can't. Breaks the rule that a CEO engages with the company only through direct reports. Goes into the details. Messier, but it works better.
The sharpest line in the essay is what "hire good people and give them room" turns into in practice. Graham doesn't soften it: too often it becomes "hire professional fakers and let them drive the company into the ground." Hence the feeling founders describe of being gaslit from two directions — by the people telling them to lead like a manager, and by the executives who do exactly that. His nuance: VCs who never founded anything don't actually know how a founder should run a company, and a good share of C-level executives are very skilled at managing up.
Presence, not absence
This is where the Decoder interview adds the precision the essay leaves out. If he had to compress founder mode into two sentences, Chesky says, it would be this: be in the details, because great leadership is presence, not absence. His argument is a cascade — if you, the leader, aren't in the details, then your leaders aren't either, and neither are theirs. The standard evaporates down the chain.
But — and this is the nuance the meme drops — it isn't about all the details. It's about the right details. Chesky explicitly rejects the idea that founder mode is swagger, micromanagement, gutting middle management, or worshipping long hours. His distinction from micromanagement is surgical: you can be in the details of people's work without telling them what to do — solving problems alongside them, not for them.
The operational corollary: for Chesky, a CEO should be an expert in the company's product, almost like a chief product officer — not a remote administrator running the place through numbers, but someone who knows the material. The question he turns back on anyone who invokes "empowerment": how do you even know your people are good, if you're not in the details?
Chesky's test cuts both ways. Where would more presence from someone senior raise a standard that's quietly slipping — and where would "presence" tip into telling people what to do instead of solving it with them?
One ship, not a thousand boats
Founder mode wasn't only an attitude — it came with a restructuring. After COVID collapsed Airbnb's bookings by roughly 80% and delayed the IPO, Chesky abandoned the hands-off style. He cut about a quarter of the company, redesigned the hierarchy around functions rather than business divisions, and centralized product planning into a single roadmap. That structure is precisely what lets him have input on far more decisions.
Why it matters: in a matrixed org, once you subdivide the company, the groups start rowing in different directions — each incentivized on something else, with more bureaucracy because they'd rather not work together. Chesky's metaphor is blunt: he'd rather have a thousand people in one ship than a thousand people in a thousand little boats, each heading wherever. Founder mode, structurally, means one ship.
Are we one ship, or a flotilla? With everything in flight toward September 1, where are workstreams on different roadmaps, rowing in different directions — and what would "one roadmap" actually take?
Jobs, Apple, and the seed of the idea
Chesky calls himself a student of Steve Jobs, and Graham builds on the contrast between Jobs and John Sculley — the founder in the details versus the manager who delegates without understanding the product. The concrete seed, Chesky says, was a meeting with Jony Ive and Hiroki Asai, two former Apple leaders. He also cites a conversation with Reed Jobs, who pushed back on the idea that his father was a micromanager — because he worked with people's ideas rather than confiscating them.
From the same family of ideas comes a prediction in the essay: founder mode breaks the rule that a CEO only talks to the company through direct reports. The skip-level — reaching past the hierarchy to hear things unfiltered — becomes the norm, not the exception. Graham's signature example is Jobs's annual retreat for the hundred most important people at Apple — chosen not by their seniority on the org chart. The point: to make a large company still feel like a startup.
Where it stops, honestly
None of the sources pretend this is a clean recipe. Graham admits you can't run a 2,000-person company the way you ran it at 20 — there will be delegation. Where the borders of autonomy sit, and how clear they are, varies by company and even over time, as managers earn trust. Founder mode is more complicated than manager mode, not simpler — but, Graham argues, it also works better.
At Rotman, Chesky adds the nuance of rhythm: there are hands-on moments and hands-off moments — it isn't permanent micromanagement. And he offers a golf analogy: the worst thing when you're learning to play is to teach yourself the swing — you lock in bad habits an instructor can barely fix later. Translated: the leader's early presence in the details sets the right patterns before the wrong ones harden.
Founder mode is not "no delegation." Where should we deliberately stay hands-off and fully trust the owner — so presence stays meaningful exactly where it counts?
As soon as the concept settles, people will misuse it. Founders who can't delegate even what they should will invoke "founder mode" as an excuse. Non-founder managers will try to mimic it, with messy results.
The irony Graham notes: manager mode, inferior as it is, has one advantage — it at least limits the damage a bad CEO can do.
"AI founder mode"
The most recent layer, which Chesky says he's still working out: in the AI era, his argument is that you have to be even more founder-oriented, because you'll need to move like a startup to keep adapting. Counterintuitively, that means more detail, not less — because AI makes almost anything accessible on demand, so a leader can be in many more places at once. His prediction: pure "people managers," with no depth in the material, will have the hardest time. It dovetails with Graham's own forecast — that once founder mode is properly understood, many founders will turn out to have been doing it all along, just regarded until now as eccentric.
What it is, and what it isn't
Compressed into one idea: founder mode is the conviction that great leadership is presence in the right details — a founder who knows the material, reaches past the org chart to hear things unfiltered, and keeps the company in one ship with one roadmap. It is not swagger, not micromanagement, not "no delegation," and not a licence to be everywhere at once. It is a more complicated and more demanding way to lead — and, the sources argue, a more effective one, when it's done with judgment.
This is why Founder Mode is in the pre-read, not as theory: we want everyone who leads at Bono to apply it. The trap it names is the comfortable one Graham warns about — delegating from the premise that "I have responsible colleagues who'll figure out what's needed and do a good job." That's how "hire good people and give them room" quietly turns into absence, and the standard slips. Presence in the right details isn't distrust; it's how the bar holds. The honest question for each of us who leads a team: where are we delegating on that premise today — and where should we be closer to the work?
Reference explainer for the learning session. A synthesis of the three main sources plus verified context; short quotes belong to the sources, the rest is paraphrase. Conceptual companion to the applied memo (Chesky / Graham / Wu → BONO).