Jim Nielsen has two posts up that I haven’t been able to stop thinking about. One is about how a team’s collective speed isn’t the sum of its members’ individual speeds, with the Olympic relay baton as the running example. The other is about how speed is corrosive to wisdom, because wisdom needs time to be wrong about things and notice.

Both feel especially applicable right now because the AI tooling story is mostly told as an individual-velocity story. Chris Coyier’s line about engineers being 10x faster with AI has been quoted everywhere, and at the keystroke level it’s mostly true. The thing I keep noticing is that this hasn’t translated into 10x faster teams or 10x more shipped product, and I don’t think it will. We sped up the part that wasn’t slow.

The slow parts of building software were always elsewhere. Figuring out what to build, waiting for review, aligning on a decision, recovering from a bad call. None of those got faster when the AI showed up. In some cases they got worse, because more output per engineer means more PRs in the queue, more competing initiatives, more decisions waiting on the same handful of people who can actually make them. The baton handoffs Nielsen talks about don’t go away when each runner gets faster. They become a larger share of the total time.

I’ve watched a version of this play out at the org level for years, well before AI. A company like Uber looks like a monolith from the outside, but internally it’s a set of orgs that touch in specific places. Rider, Eater, and Driver each have their own ownership, their own roadmaps, their own engineers, but they share payments, identity, maps, fraud, and a dozen other systems where one org’s decision is another org’s constraint. The hard work has always lived at the areas of intersection, where two or more roadmaps need to agree and two or more sets of engineers need to align on what “shared” actually means. The same pattern repeats inside each org. AI doesn’t help with that. If anything, when each org is shipping more code more quickly, the intersections get noisier, not clearer.

The bottlenecks AI doesn’t unblock are the ones that already mattered. Senior judgment about whether the work is worth doing. Patience to let a decision settle before reversing it. The willingness to sit with a bug long enough to understand why it happened, instead of fixing the surface and moving on. The kind of taste that comes from having shipped a thing, watched it fail in production, and felt bad about it for a while.

This is where Nielsen’s second post lands for me. He argues that speed lets you outrun your own mistakes, because mistakes take time to register. You can’t notice you were wrong if you’ve already shipped three more things on top of the wrong thing. I think this is right at the individual level too. AI makes it dramatically easier to skip the part where you sit with your bad code, your wrong design, your misplaced confidence. Being wrong used to be expensive enough that you slowed down to be less wrong. The cost dropped, and the discipline that produced careful work isn’t getting reinforced.

I’m not against the speed. The speed is real, and a lot of work that used to be tedious is genuinely easier now. The point is that the gains accumulate at one layer and the bottlenecks live at another, and treating them as the same number leads to bad planning and worse promises. If you’re running an org right now, the useful question is what gets harder when each of the orgs around you is shipping two or three times more output than it was six months ago. The answer is usually some flavor of cross-org friction, which mostly means roadmap dependencies, review queues, and decisions made elsewhere that constrain what shape your work can take.

The relay framing is useful in a way I didn’t catch when I first read Nielsen. The fastest sprinters in the world still lose if the baton drops. We’ve spent the last two years recruiting faster sprinters. The batons are sitting in the same places they always were.