TBM 427: The Bottleneck Strike Again!
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.
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.
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.”)
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.
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.
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:
Chatting with a friend recently:
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.
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 talk about what this is actually about. Imagine you have a 10% margin business. You spend 25% of your revenue on R&D. In comes that Deloitte person who says … “cut by 30%, spend 5% on tokens, book it all as AI productivity, and your EBITDA will magically expand, margins will look incredible, and you’ll somehow steal market share from other companies using the exact same technology and following the exact same mind-numbing AI mandates.”
While we’re going around wishfully imagining that this bottleneck will simply shift, maybe to something we like or do not, the real drivers and constraints—bottom lines, short-term financial incentives, boards, investor expectations, executive compensation structures, and capital structures—are already shaping where it will land and how it will be interpreted. There is also a very real arbitrage happening around chips and capex: massive upfront investments in GPUs and infrastructure being justified by projected efficiency gains, alongside the inconvenient truth that stock-based compensation, once treated as a benign or even invisible cost, is now being reframed as “too expensive” and ripe for reduction under the banner of AI productivity.
Maybe the “bottleneck” is our ability to have these conversations.
Maybe the “bottleneck” is our able to process whatever is changing, and trying to grapple with it with less fear.
Maybe the bottleneck is that the conversations are too sensitive, and it is easier to make slides saying there’s a bottleneck.
There are very, very real discussions to be had about how AI will shape how we work, how we think, how we behave, how humans will human. But we are in such the early innings, as they say in American baseball, that it is the equivalent of when electricity was first introduced and people were debating whether it was safe to wire homes, or when the printing press emerged and societies grappled with what it meant for knowledge and authority, or when the internet arrived and we were trying to understand what it would do to communication, commerce, and identity. The “bottleneck has moved” is basically saying “something has changed, and typing is faster, but we don’t know what the heck is going to happen.”
Not sure how to say this, but any podcast, article, YouTube video, or LinkedIn post from anyone telling you about “the way” just figured it out last week and is excited to tell you about it. We are all learning by doing right now, in real time, with incomplete information and shifting ground. A consultant might have some sort of marginal advantage due to their “n,” but they also lose that advantage because they probably weren’t sitting there in the thick of your strategy, your constraints, your customers, your codebase, your incentives, your politics, and your operating model last week. Everyone is learning. Everyone is inventing. Everyone is winning, then failing. Everyone is on this rollercoaster.
So if anyone tells you they’ve figured it out, they are de facto delusional or partaking in deceptive marketing.
Remember: the “bottleneck” is typical surface level.
Or maybe another way to say this
Imagine the “bottleneck” really was engineering or coding. What does that imply about the competitive game you were playing? Are you saying the only thing holding you back was something relatively commoditized—something you could just hire more people to do? What does that say?
It suggests you were competing in a world where speed of execution mattered more than insight, where everyone was building roughly the same thing, and whoever shipped faster won.
But if that’s true, you better hope engineering wasn’t your bottleneck. Because if it was, and AI removes that constraint for everyone, your competitors will take you to the cleaners.




This is spot on, John. The obsession with 'moving the engineering bottleneck' completely misdiagnoses what product development actually is.
The real constraint in a complex human system isn’t execution volume; it’s the velocity and quality of our knowledge turns—the iterative cycle of combining context, forming a hypothesis, testing it against messy human reality, and acting on the feedback.
AI doesn't do knowledge turns. It generates artifacts.
I think Goldratt would highly approve of this positioning. In The Goal, the mistake was thinking that keeping every machine running at 100% capacity was efficiency, when it actually just piled up massive, choked-up inventory on the plant floor.
When execs buy into the consultant pitch to slash headcount and replace it with LLM tokens, they are making the exact same mistake. They think they are clearing a pipeline, but they are just flooding the system with a massive backlog of unverified 'cognitive inventory.' Code that hasn't been validated by a human team navigating real organizational context is just a liability sitting in a warehouse. It doesn't reduce uncertainty; it just forces the remaining team to spend more time debugging, integrating, and untangling a high-speed mess.
As you noted with the house storage analogy: you can't solve a systemic issue by just throwing more 'stuff' into the closet. If AI commoditizes typing, then the speed of raw code generation drops to zero competitive value. The ultimate advantage shifts entirely to whoever can execute high-quality knowledge turns the fastest."
I have seen this phrase thrown around, and admittedly said it. I appreciate this article because I realize now that I was trying to say something different and completely missing the target and perpetuating confusion.
What I believe I was trying to convey is that the ability to go from idea to working code is faster than ever, and so in theory, more working code means more features, etc. And that obviously highlights a gap that we’ve had forever on that, “are we actually building shit that people want”, and more working code could just flood the zone with more crap. Of course, this also assumes that all of the tooling and processes are working…but who knows if those will even hold if you’re spamming out slop.
I guess what I’m saying is, no, the bottlenecks are still all there. But there is a way to say that we could further expose the gap between product and engineering if we speed up engineering. But saying the bottle neck has moved is not the right way.