The judgment this piece runs on: what kills a fast team is usually not slowness. It's the fairest-looking move in all of management — putting every team on the same cadence. What a fast team ships each week is weekly-disposable; the foundation it stands on ships on an annual clock. One unified cadence means forcing your supply line to march at charge speed.
What this piece solves for you: before you align the whole company on a single release calendar, audit who your fast team owes — the data foundation, deployment stability, the training of successors, the incident backstop. None of those four lines appears in any fast metric, but every blank one costs you roughly a quarter of speed.
A scope note before anything else: this piece is about the slow work that supplies fast teams — not slowness itself. Slow that produces only inertia and no durability takes just as much criticism here. The fast-slow split is a judgment frame, not a template to copy; every way it breaks is in "When This Audit Stops Working" at the end.
One Clock Left in the Whole Company
Start with a move almost every manager has made: pulling every team onto the same cadence.
Same sprint length, same weekly report, same release calendar. Intuition calls this alignment. It calls it fairness. It calls it managerial health — why do they get to ship every two weeks while your month barely moves? Mismatched rhythms make the reports unreadable, the reviews impossible to sequence, the resources impossible to pool. So the clocks get tuned tighter and tighter.
I want to take that intuition apart. Most companies don't die of being too slow. They die after the whole company is down to one clock — because the work that can never go fast, the data foundation, deployment stability, the development of successors, gets forced to queue inside fast metrics. It can't get in, so it gets pushed to the next round. Then the next. And when there is nowhere left to push it, the supply quietly stops.
The fast team feels nothing at the time. The road gives out three quarters downstream.
The Company That Organized the Other Way: Three Org Designs in Four Years
Now a company that did the reverse.
Airtable's CEO Howie Liu, on Lenny's Podcast, walked through his company's reorganizations — several rounds inside four years. The case ledger is worth laying out in full, because it reads like an org-design textbook played in reverse, starting from the most common structure of all.
Version one: organized by function. A search team, a mobile team, each defending its own patch of product surface. The upside was real: nobody on earth knew that code better than the people who lived in it. But the flaw he named is worse — every team's assignment was, by construction, "improve your own patch a little more," and nobody looked up at the whole. Each group was competent on its own. Add them up and you get a company that only knows how to polish in place.
Version two: organized by business pillar. Later came the pillar split: an enterprise pillar to scale deployments up to ten- and twenty-thousand seats, plus separate pillars for self-serve, AI, solutions, and infrastructure. With pillars, the company could at least think in wholes — redoing the entire onboarding experience as one project, instead of every feature fending for itself. This is the state most companies envy: a whole-company view, clear pillars, a home for everyone.
Version three: organized by cadence. But whole-picture or not, he still felt the drag — and the harder he pushed into AI, the more obvious it became. "You look at companies like Cursor — they're shipping something big every week." Several roadmaps twisted into one rope, one product sprinting. So in the most recent reorg, he split the engineering organization into two cadences.
The fast half is officially named AI Platform, and its goal is blunt: ship a batch of new capabilities roughly every week, good enough to make users' jaws drop.
The other half lives on the slow track, making the heavy bets that require premeditation. His example is HyperDB, the in-house data foundation, built to carry hundreds of millions of rows. He said it plainly: that is not something you ship as a scrappy prototype within a week.
Put the three versions side by side and the grouping logic itself does the talking:
| Version | Grouping logic | What it bought | What it cost |
|---|---|---|---|
| One | By function | Every line of code had someone who knew it best | Each team farmed its own acre; nobody looked up at the whole |
| Two | By business pillar | Whole-company thinking; onboarding redone as a single project | Still too slow for him — he couldn't match AI-native shipping speed |
| Three | Two cadences | Fast track shipping roughly weekly; slow track raising HyperDB, a foundation for hundreds of millions of rows | Both tracks need their own people, goals, and scorecards (more on that below) |
HyperDB deserves a pause of its own. It has no demo and no story. Bury a bet like that in some feature team's backlog, or in a pillar's long-term investment line, and it never holds time and headcount under its own name — only when cadence became its own axis did HyperDB get both, for the first time.
What a fast team ships every week is weekly-disposable. The foundation it stands on is annual-cadence.
How the Two Halves Mesh: the Fast Half Makes the Novelty, the Slow Half Grows the Seeds
What's interesting is how he describes the relationship between the two halves. Slow thinking isn't better or worse, he said — people simply need both fast thinking and slow thinking. Lenny chimed in from his chair: the book was sitting right behind him. Splitting an organization into two tracks isn't one side reforming the other. It's giving each of two naturally coexisting modes of thought its own dedicated line.
And the division of labor meshes tightly. The fast half manufactures novelty: new capabilities pull eyeballs, pull in new users, pull enterprises over to kick the tires. The slow half catches those seeds and grows them into bigger deployments. Every weekly, jaw-dropping drop from the fast track is seed scattered into the pond; whether any seed grows into a ten-thousand-seat deployment depends on the slow track paving the foundation out to that point, inch by inch.
Plenty of AI-native companies, he said, get stuck exactly here: the top of the funnel is wide, and everyone pouring through it is an "AI tourist." The hard part is sometimes just converting tourists into durable growth. Tourists are the fast track's output. Durable growth is the slow track's output. A company with only a fast track is a storefront with a crowded entrance and nothing inside.
Lenny's verdict, in his own words: he had never heard of this split. A manager who tried several rounds of org design finally matched AI-native shipping speed by cutting rhythm itself into two.
Plainly put: a fast team doesn't run fast on its own legs. It's carried by the slow team — and when the horse doing the carrying starves, it cannot take a single step.
Most Companies Run the Play in Reverse
Here's the problem: most companies run this exact play the other way around.
The data foundation, deployment stability, the development of successors — none of this work has a demo or a story, and it loses every prioritization round. It is the road under the fast team's feet, and the road's maintenance log appears in no fast metric. Releases shipped, iteration speed, requirement throughput — scan the whole stack of fast dashboards and nowhere is there a column reading "road still solid."
Then management squeezes the whole company onto one release calendar, and it even sounds fair: why do they ship every two weeks while your month barely moves?
But slow work cannot certify itself with slow metrics. Once the whole company is down to one clock, all it can do is queue inside the fast ones — and the fast ones ask: what did you ship this quarter?
The foundation team has no answer. No answer means your budget gets cut in the next round. Foundation value arrives in steps. Fast metrics only recognize slope. Three years of foundation work plots as a flat line; in year four it jumps a full step, and every fast team riding it gets faster at once. But on a slope-only report, that three-year flat line looks exactly like idling — in every single cost-cutting discussion.
In intuition, one cadence equals fairness. In the ledger, it equals ordering your supply line to march at charge speed. The front line is scored on charge speed, so the supply line gets scored on charge speed, so every ounce of supply-line effort gets redirected into fixing trucks. Nobody repairs the road.
And the ugliest part is where the consequences land. The people making the decisions are the ones closest to fast metrics. The first cuts hit the slow teams. The last to starve are the fast teams charging down that unmaintained road. Decision chain, budget chain, death chain — three chains lining up in one seamless order. No individual manager is the villain here. In a one-clock organization, the ledger simply calculates this way.
The Other Kind of Slow Work: Handoffs, the Kind That Involves People
Slow work has a second face — one with nothing to do with code and everything to do with people.
Ryan Salva of GitHub, on the same show, walked through the Copilot handoff: whatever a research team incubates has to be handed to a product team to go further — who takes it, how the taking happens, and when research lets go. He gave a complete account.
The easiest script for that moment writes itself: the research team takes a bow and exits stage left, the product team says "we'll take it from here," a handoff email goes out, a calendar box gets checked, and everyone keeps their dignity.
They didn't do that. Their handoff ledger, move by move:
| Handoff move | What they actually did | The judgment underneath |
|---|---|---|
| Move researchers into product | Deliberately embedded part of the research team into the product team, for a fixed term, to do knowledge transfer | A brain that understands the business isn't inherited through documents; the person has to travel with the work |
| Staff around those people | Built the receiving team out around the embedded researchers | A handoff isn't the transfer of documents. It's growing a receiving team next to a living person |
| Recruit to serve the handoff | Hires existed to build buffer around the researchers, so they could eventually withdraw whole and go think about the next moonshot | Headcount budgets sequenced by handoff needs, not by department walls |
| Withdraw in phases | Only about eighteen months after the product's kickoff did researchers begin phased withdrawal back to research | Withdrawal follows maturity, not the calendar |
He has one hard criterion for when researchers can leave: not by the calendar — you wait until the people receiving the work are in place, actually doing the job, and have closed every skill gap.
He added two more rules, both worth copying into a notebook. The roadmap cannot be outsourced to the research team: the team closest to customer feedback, the one that maintains the product, has to hold the roadmap itself. And innovation cannot be fully outsourced either: the product team has to own the use cases and own the customers. Together, the two rules say one thing — you can lend out your research team. You cannot lend out responsibility.
A head for the business, enough tenure to hold the room, face recognition with the customers — no handoff email grows any of the three.
A handoff is complete not when the calendar says so, but when the people receiving the work are genuinely running it.
Two Buckets of Cold Water
Before this piece gets misread, two buckets of cold water.
First: slow is not automatically right. Airtable's pre-reorg functional teams were a kind of slow too — the kind that produces inertia, not durability. What deserves feeding is not slowness; it's the slowness that supplies the future. There is exactly one test question: what will this slowness ship to the fast teams next year? Slow with no answer is the same organizational disease as the unified calendar — just with opposite symptoms.
Second: do not copy the fast-slow split as a template. That boundary is mine, not Howie's — he described only the current shape that survived several rounds of reorg across four years. And the entire grouping story is his own account in an interview; I have never been inside Airtable to verify a number. The Copilot criterion is the same register: a methodological claim, not a measured handoff outcome. Both cases are practitioner retrospectives on the same podcast. As contrast samples for org design, fine. As experimental conclusions, no.
One calibration from my own ledger. I spent six years at my last company and watched support functions be first in line in every cost-cutting round. This year, building my own systems as a crew of one, the biggest steps of progress all went into work that will never appear in any demo. The first is an organizational story on repeat; the second is the same story at a desk for one. Orders of magnitude apart, one mechanism: speed is fed by slow work.
Who Does Your Fast Team Owe? An Audit in Four Blank Lines
Two things you can carry straight back to your team.
The first is the "who does my fast team owe" audit. Don't ask whether your team is fast. Draw four blank lines first:
| Blank line | What it asks | What breaks under the fast team's feet when there's no answer |
|---|---|---|
| Who is growing the data foundation? | Does capacity, performance, and architecture work hold time under anyone's name | Bets like HyperDB go unplaced; the fast track's new capabilities start hitting a ceiling |
| Who is watching deployment stability? | Is incident prevention, monitoring, and rehearsal somebody's actual job | The fast track runs shakier every sprint; every release is a dice roll |
| Where is the successor for the critical work? | Is a second person growing on every critical piece — and how far along | The key person moves and the work goes dark; the handoff gets brute-forced by calendar |
| Who absorbs the incident? | Does the backstop, the post-mortem, the accountability mechanism rest on a name | Incidents get staffed by whoever's grabbable; soon nobody dares take slow work at all |
A team with any blank line on this list can't stay fast for three months.
The second is the handoff criterion. Rotation, yes. Withdrawal, no — withdrawal has exactly one condition: the receiver can already catch. Skills closed, running in the seat. Until then, nobody moves. The criterion is one sentence; when you apply it, watch three states — in place, doing the work, skills complete. All three true, then you may talk about withdrawal. Missing any one, the withdrawal date on the calendar is fiction.
When This Audit Stops Working
The failure boundaries of both tools, stated plainly.
First: a genuine one-person company or a pure delivery crew can live happily with a mostly blank dependency sheet — blank lines prove nothing there. In a crew of one, you are the foundation and you are the stability watcher; all four lines blank, and it still runs fast. This audit is for organizations with a division of labor.
Second: a company already in wind-down-and-harvest mode should not be buying durability. If you know the business exits within two years, piling an annual-cadence bet into the foundation is burying money in a field you will never harvest. Pushing the fast cadence is the correct call.
Third: when a business is being shut down, or the people simply cannot be hired at any price, the calendar is the only stop-loss line you have left — let no handoff criterion stand in front of a stop-loss. The criterion says "receiver not ready, nobody withdraws." The stop-loss line says "this business is gone next month." Stop-loss wins. The criterion yields.
An audit and a criterion are tools. A tool that knows exactly where it stops applying is a tool that has earned the right to be trusted.
The Road Is What Makes Fast Mean Anything
Everyone is teaching you how to use AI to make your team faster, and everyone loves the one-person-company-worth-a-billion story.
Nobody asks: who paves the road under your fast team — and what share of the rations the paving crew eats. The question isn't sexy. It decides how many quarters your speed survives.
Before your next cadence-alignment meeting, audit the road under your own team first.
The road is what makes fast mean anything.
Related reading: “The Small-Team Productivity Myth Is Missing a Few Names” runs the measurement ledger this piece only points at — the productivity denominator omits exactly this supplying, slow work. And for what the handoff criterion looks like at a client site, see “Your FDE Moved Into the Client's Building. How Do You Get Them Back Out?” — an embed that never exits shares the same root cause: withdrawing by calendar instead of waiting for the receiver to actually catch.
I'm Uncle J. Eighteen years in HR taught me the craft this whole piece runs on: break the work down, write down who owns which piece, and notice which pieces nobody owns. These days I run a one-person AI organization, where the fast team and the slow team are the same person — all four lines of my own audit carry one name, and that name spends its hours on the road first.