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.
And it seems that a lot of managers are only looking at the surface, not what's below it.
Managers should look at the fundamentals that make their organisation what it is today, and work these fundamentals to create their organisation of tomorrow.
I am thinking about decision mandate, outcome ownership, skill completeness, decisive adaptation, honest inspection, ...
Replace engineering with design and if also fits. It seems that the distance between the actual work and teams context might prevent executives from achieving the right decision on this. Not sure how to bridge that gap.
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.
I also LOVE this post and It is not the onlyone explaining this
https://emmanuelvalverderamos.substack.com/p/faster-code-slower-system
https://emmanuelvalverderamos.substack.com/p/the-real-bottleneck-was-never-code
https://emmanuelvalverderamos.substack.com/p/my-reflection-on-the-real-problem
https://emmanuelvalverderamos.substack.com/p/ai-is-teaching-product-teams-to-optimise
"the “bottleneck” is typical surface level".
And it seems that a lot of managers are only looking at the surface, not what's below it.
Managers should look at the fundamentals that make their organisation what it is today, and work these fundamentals to create their organisation of tomorrow.
I am thinking about decision mandate, outcome ownership, skill completeness, decisive adaptation, honest inspection, ...
Replace engineering with design and if also fits. It seems that the distance between the actual work and teams context might prevent executives from achieving the right decision on this. Not sure how to bridge that gap.
Great summary of the what the product world feels like today. If only we could solve that easy..