TBM 427: The Bottleneck Strike Again! - by John Cutler

The Beautiful Mess

SubscribeSign in

TBM 427: The Bottleneck Strike Again!

John Cutler<br>Jun 26, 2026

28

Share

My goodness. If I see another slide with a 2005-era SDLC diagram sprinkled with little AI logos and a bunch of words suggesting “the bottleneck has moved” or that this has all been figured out, when in reality every week there’s something new like Loop Engineering, or _____________.

I’m trying to understand why we are so quick to be seduced by the idea that “engineering is no longer the bottleneck.” At this point, it almost feels like the bottleneck has shifted to conversations about how the bottleneck has shifted. As if engineering was ever the bottleneck, or was always the bottleneck. Unlike home plumbing, product development rarely has one obvious clogged pipe. The work is not a simple linear system where everything waits behind one blockage and then magically flows once that blockage is cleared. It isn’t a Kafka queue or the Holland Tunnel.<br>Product development is not just production, and writing code was never one cognitive activity repeated over and over. It is sensing, deciding, learning, aligning, making, changing, supporting, and adapting. It can be hard to remember this. Almost all of us have, at some point, shouted out, “If we could JUST move faster!” And I do think there are situations where you have 1) lots of data, 2) lots of reps, 3) strong situational awareness, and 4) you can confidently tell an LLM to do this/that/whatever, and you’ll be happy that happened faster. But that isn’t the majority of situations in our line of work.<br>The “bottleneck” moves, but even that mental model breaks quickly. If something is constantly moving, is it more akin to the Heisenberg principle, whereby the very act of observing the system changes the system? It is always layers of constraints, context, incentives, dependencies, and feedback nudging the system into different configurations. All bottlenecks are constraints, but not all constraints are bottlenecks. Constraints can enable, govern, limit, focus, shape, and protect. Bottlenecks are just the visible logjam that, more often than not, is a symptom and not “the problem.” Even in systems thinking traditions like Donella Meadows’, the idea of a single constraint is more of a simplifying lens than a literal truth. And from a complexity perspective, like Alicia Juarrero’s work, the notion of “one constraint” does not really hold at all; constraints are distributed, interacting, and constantly co-evolving. What looks like a bottleneck is just a temporary pattern emerging from that web, not a singular point of control.

(Note: None of this is definitive, of course. Almost every conversation I have with engineers whose work I respect boils down to grappling with what this all means. My point here is to reflect that we generally net out on typing being faster, AI being an incredible energy suck, and it not being as simple as “hey, no longer the bottleneck.”)<br>Flashback to walking into startups with the “best engineers money could buy” (”and most of the work we’re doing right now is pretty trivial”) that couldn’t get out of their own way. Coding was not the bottleneck. But then again, nor was there one thing—anything—you could shake a finger at.<br>It’s like when your house is a mess and you keep talking about needing “more storage,” but no matter how much storage you add, until you change your relationship with “stuff,” maybe your kids move out, and you stop treating every closet as a place to hide deferred decisions, you’ll never have enough storage. You can point to the mess and call it a bottleneck, and it very well might be a bottleneck, and there’s so much clutter you have trouble decluttering. But there is a lot more going on.<br>The deeper proponents of Theory of Constraints would never advocate for the idea that you’re playing a game of linear whack-a-mole in a company, chasing around the “one big gap that holds everything back.” Take Goldratt himself, who, while famous for saying “An hour saved at a non-bottleneck is a mirage,” also spent much of his later work emphasizing that in complex human systems the constraint is often policy, mindset, or coordination, not a single physical choke point you can just point at and fix. Yes, you can apply Theory of Constraints to some sort of flow or “value stream” and do the classic identify the constraint, exploit the constraint, subordinate everything else, elevate the constraint, and repeat playbook. But apply that very same thinking to a group of humans and you have simplistic hot takes. But even worse:<br>Chatting with a friend recently:<br>McKinsey, BCG, Deloitte, EY, etc. are all pitching that we can cut our workforce by 30% in 2 years. And uninformed execs without informed reps are buying the story.<br>So let’s be honest with ourselves: that is what this is all about. That’s the conversation. We can all buy into the easy-to-repeat meme about bottlenecks, or...