Two Speeds

Two Speeds

Photo by pine watt on Unsplash

I’ve been listening to a lot of conversations about AI adoption lately, and the same problem keeps appearing. Every company is trying to do two things at once: keep the current business running and figure out what AI actually changes. Most of them are trying to do both with the same teams using the same planning cycles and the same approval processes.

It doesn’t work. These two activities move at fundamentally different speeds, and when you force them into the same cadence, one of them suffers.

Howie Liu, the CEO of Airtable, ran into this problem and did something about it. In 2025, he restructured the entire company around a single question: if we founded this business today with AI as a core capability, how would we operate?

The answer wasn’t “add AI features to the roadmap.” It was a full organizational redesign. Liu split his teams into two modes, borrowing the framing from Daniel Kahneman’s Thinking, Fast and Slow :

Fast-thinking teams experiment rapidly with AI. They ship on short cycles, tolerate mess and are encouraged to cancel meetings and spend days just playing with AI products to build intuition. The output is learning and iteration, instead of polished products.

Slow-thinking teams build durable infrastructure. They make deliberate, long-term bets around architecture changes, and data systems…you know…the stuff the business actually runs on. Their work requires premeditation and precision and moving fast here would be reckless.

One side needs permission to be wrong. The other needs protection from the chaos.

Liu discussed the restructuring in detail on Lenny Rachitsky’s podcast , and it’s worth listening to because the reasoning behind the split matters more than the split itself.

Why Single-Speed Fails

Most companies run at one speed. And it’s almost always the slow one.

Every initiative, whether it’s a database migration or an AI experiment, goes through the same planning, approval, and review process. There are requirements documents, architecture reviews, stakeholder alignment and sprint planning. By the time an AI experiment makes it through the pipeline, the thing you were experimenting with has already changed or the model updated or the API evolved…or worse, your biggest competitor shipped something.

AI initiatives die slowly under process weight and quietly stall out, buried under a process that was never designed for this kind of work.

The opposite failure is less common but just as real. Some companies try to move everything fast. The result is instability and things break in production, technical debt compounds and the core business gets shaky because nobody slowed down long enough to make anything solid.

The insight behind the two-speed model is that these failures aren’t execution problems per se, but structural ones. You’re asking people to do fundamentally different kinds of work under the same constraints, and that’s a design flaw.

What Two Speeds Actually Looks Like

The fast-thinking team needs permission to be wrong. Short cycles. Hypothesis-driven work. Kill experiments that aren’t learning anything. The people on these teams need to be comfortable with ambiguity and able to work across roles. Liu’s observation was that the biggest productivity gains weren’t going to specific roles like engineers or PMs, but to people who could prototype, test, and iterate across functions.

The slow-thinking team needs protection from the chaos. Their job is to take what works and make it permanent, reliable, and scalable. They need the space to think through architecture decisions, handle edge cases, and build things that won’t need to be rebuilt in three months.

The hard part, and Lex Sisney at Organizational Physics makes this point well , is the handoff between the two. When does something graduate from fast to slow? How do you keep the fast team from building things that the slow team can’t maintain? How do you keep the slow team from gatekeeping things that need to ship?

The ambidextrous organization literature has been writing about this tension for years. Companies need to exploit what works and explore what’s next at the same time. Amazon does it with separate teams for core operations and AWS innovation. What’s different now is that AI makes the speed gap wider. The experimental side can move much faster than it could before, which means the distance between the two modes is growing.

The two-speed tension predates AI, but AI widens the gap faster than most companies can close it.

Liu’s acid test is worth sitting for a bit:

“If you cannot articulate how you would operate as an AI-native company founded today, you should find a buyer.” — Howie Liu, CEO of Airtable

I think he’s right about the question, even if the answer isn’t as binary as ‘keep or sell.’

Share

Get weekly insights on technology leadership

One idea per issue. No spam. Plus a free guide on measuring AI initiatives when the old metrics don't work.

Or download the free guide directly →