Engineering Productivity Is Necessary, But Not Sufficient.
Faster engineering doesn’t automatically create faster companies
Right now, almost every engineering organisation is focused on improving productivity. Teams are trying to ship code faster, reduce pull request cycle times, accelerate deployments, compress SDLC timelines, and integrate more AI-generated software into development workflows.
All of this is great and necessary.
Engineering productivity matters enormously. The strongest engineering organisations have always invested heavily in developer experience, tooling, automation, and the reduction of operational friction. Faster feedback loops and higher-quality execution create meaningful advantages.
The problem is not the pursuit of engineering productivity itself. The problem is that many organisations have started treating engineering productivity as the ultimate goal rather than one component of broader organisational effectiveness.
That distinction matters.
A faster engineering organisation does not automatically become a faster business.
Teams can reduce delivery cycles from weeks to days while the company itself struggles to move with greater speed or clarity. In many cases, the real bottlenecks exist outside engineering entirely. Priorities shift constantly, decision-making slows execution, cross-functional coordination introduces drag, ownership becomes unclear, operational adoption stalls, and customer feedback loops remain weak.
Engineering productivity is a local optimisation. Business performance depends on the entire organisation.
Historically, improving engineering throughput created enormous leverage because software production itself was expensive. Engineering capacity was scarce, and writing software represented the primary bottleneck inside many organisations. If you increased engineering output, the business often moved faster as a direct result.
AI is changing those economics.
As software production becomes increasingly efficient, the bottleneck moves upward into prioritisation, coordination, decision quality, and organisational learning. In many companies, software development is no longer the slowest part of the system.
The organisation is.
That reality is going to become increasingly visible over the next several years. Many companies will dramatically accelerate engineering output while seeing only marginal improvements in actual business throughput. Productivity gains only matter when the surrounding organisation can absorb, operationalise, and compound them effectively.
Improving engineering productivity inside a misaligned company is like turning one road into a highway while every traffic light ahead stays red. Engineering moves faster for a moment, then work stalls in prioritisation, coordination, approvals, and adoption.
The organisations that succeed in the next phase of AI adoption will not simply be the ones generating more code. They will be the organisations that make decisions faster, align teams more effectively, reduce coordination overhead, operationalise changes efficiently, and learn from customers more quickly than competitors.
That is a very different optimisation problem.
The next generation of engineering leaders will not be judged solely by developer velocity or deployment metrics. They will be judged by whether faster engineering execution produces materially better business outcomes.
That is the deeper shift underneath the current productivity conversation, and AI will only make it more obvious.