From Scrum Teams to F1 Teams

The other day I was talking with Scott Reed, Head of AI at Emporia Energy, about how teams build software.

We weren’t meeting up to write a manifesto. It started the way these conversations usually do: half-formed thoughts, and a growing conviction that the current way teams are building needs to change.

At one point, Scott said, “Scrum just doesn’t feel like it really applies anymore.”

On the surface, that sounds familiar. People have been declaring Agile dead for years. Usually, what they mean is that their version of it stopped working, and they invented an alternative. (E.g. Shape Up).

But it’s different this time. Let me explain.

Scrum exists for a good reason

Waterfall tried to eliminate uncertainty upfront. This was soooo painful, and a fool’s errand at best. I used to work with a Business Analyst to document every possible screen and interaction, creating a 100+ page Vizio document that we’d hand off to engineering. They’d actually use it to build over a 3-6 month period. And if they encountered an unknown, we had to update that manuscript and ask them how much our oversight would cost us in delays. That’s actually insane in hindsight. 🥴

Agile accepted that uncertainty was unavoidable and created a way to manage it over time. You worked in smaller increments, shipped more often (or continuously), learned faster, and reduced risk step by step.

That model made sense because building software was expensive. Every meaningful change took time, money, and coordination. So teams built systems to de-risk the work: specs, sprints, roles, handoffs, ceremonies.

But what happens when the cost of building drops dramatically?

That’s where the old model starts to crack. When you can ship something quickly, test it, and rebuild it the same day, you don’t need a long process for slowly converging on the answer. You can try something, judge it, and change course immediately.

So the bottleneck is no longer building. It’s deciding.

The old loop looked like this:

Plan → Build → Ship → Learn

Now it looks more like this:

Build → Judge → Rebuild → Repeat

When you can create multiple versions of something simultaneously, and try different approaches to a complex problem all within a single day, the value is no longer de-risking production costs. The value is in knowing which option is right.

That shift changes how your team operates, and pretty dramatically. I think this is why everyone is freaking out, but I don’t think it’s as hyperbolic as it needs to be.

Back to the Conversation

Scott watched the movie F1 on a flight home recently, and he made a comparison: we’re moving from Scrum teams to F1 teams.

In a traditional Scrum model, work moves across a chain.

Product defines.
Design shapes.
Engineering builds.
Everyone contributes.
The system depends (heavily) on coordination and handoffs.

In F1, there’s still a team. Engineers, mechanics, strategists, pit crew. But there’s also a driver: one person making real-time decisions under actual conditions, accountable for the result.

That doesn’t mean companies need one heroic individual doing everything. It means decision-making has a new center of gravity.

Maybe a company has multiple drivers: different people owning different parts of the product, all supported by shared infrastructure, design, and architecture. The question is no longer just how you coordinate work. It’s who you trust to drive.

Who Should Drive?

That person probably isn’t a traditional product manager or a traditional engineer.

I’ve worked with a lot of PMs who don’t have enough technical depth to operate directly in the system. On the other side, many of the engineers I’ve collaborated with don’t have the business context to decide what should be built.

The role emerging is someone who understands both: how software gets built and why the business needs it built in the first place. Someone who can move from customer need to product judgment to implementation without losing the thread.

Not a better title. A different kind of operator.

The closest description we came up with is a driver. (We came up with several dumb alternatives as well).

That shift doesn’t minimize the rest of the team. You still need strong architects to keep the system coherent. You still need strong designers to keep the product from turning into generic AI sludge. You still need a support crew.

But the structure changes. Fewer handoffs. More shared context. Smaller teams with clearer ownership.

And that’s what makes this so hard for established companies to figure this pivot out. It isn’t really a process problem. It’s a people problem. It touches roles, incentives, and organizational designs. It asks enterprises built like oil tankers to behave like race cars.

Startups have a much easier time with that. They have plasticity. They won’t break under the pressure to change. Brand new ones can jump out of the gate applying this way of working.

That said, abstraction like this never served anyone. Scott and I talked through a simple way any team can test this.

A Practical Experiment

• Pick one product slice small enough to change in weeks, not quarters.

• Assign one driver with real decision rights. This person can come from product, engineering, or design, but they must own the outcome, not just the backlog.

• Give that driver a tiny support crew: one designer, one senior engineer or architect.

• Remove most of the normal Scrum mechanics for that pod. No sprint commitments, no ticket handoff chain, no separate discovery process to green-light your investment.

• Replace them with a tighter loop:

  • daily 15-minute decision review

  • twice-weekly customer or internal user feedback

  • continuous shipping inside guardrails

  • one clear outcome metric

• Measure it.

This is roughly how we’re working today on our personal projects. Test it and let us know how it goes in the comments. 🙏🙏🙏

There’s one more trap here, though.

AI makes it possible to generate more of everything: more code, more features, more output, more experiments. Teams can run twenty agents overnight and wake up to a pile of progress.

But more output is not the same as better product. Without judgment, all you’ve built is a modern feature factory. More velocity. More noise. More things nobody actually needed.

That’s why this shift matters.

It’s not really about speed. It’s about decision quality.

It’s not really about roles. It’s about ownership.

Not everyone needs to be the driver. F1 teams still need engineers, designers, and pit crews. But the center of gravity has moved, and teams that don’t recognize that are going to struggle and move slower no matter how many new AI tools they adopt.

The race has already started. 🏎️🏎️