Too often and to the detriment of many engineers, those striving to improve developer experience and platform engineering focus on cutting costs and eliminating waste as the sole investment drivers for these initiatives. This has pushed key thought leadership in that direction, which is felt in multiple areas in the software industry. It can be observed in everything, from the way engineering managers fight uphill cultural and political battles to drive new DevEx investments, to the hollow messaging many direct software sellers use to present new tools and solutions to decision-makers.
The true business value of providing a best-in-class developer experience is not being articulated enough, and that is — improved developer experience is a profit driver, not a cost center. The elimination of toil and waste that seems to always be the focus of discussion is merely serving the greater interest of accelerating feature time to market, which, if your product is lucrative, means making money faster.
Of the three agreed-upon drivers behind most purchasing decisions — risk reduction, cost savings and accelerated profit — it is commonly agreed that accelerated profit is the most attractive one. This is the story we can and should be telling for investing in improved developer experience, not the banal promise of lower operational costs. Luckily, there is plenty of precedent to be found in the foundational wisdom of our current practices.
The Theory of Constraints and the Value of Throughput
In Eli Goldratt’s transformative novel ‘The Goal,’ a groundbreaking perspective called ‘The Theory of Constraints’ is introduced, continuing much of the intellectual underpinnings that would go on to give rise to practices like lean, agile, DevOps and now platform engineering. In fact, the bestselling book ‘The Phoenix Project,’ often vaunted as “life-changing” by many of its adherents in the DevOps space, is a direct homage to The Goal. Even Gene Kim, the book’s primary author, famously recommends that people read Goldratt’s work before reading his own.
Goldratt explores the multiple intersections between the physics of complex machinery and the operations of a product-focused business as the central hypothesis of The Goal. A cardinal rule of the theory of constraints and machine physics is that a complex machine can be abstracted down to three core concepts: inventory, cost and throughput. In the world of complex machinery, there are specific definitions to each of these concepts:
Inventory: The raw materials that make up the machine itself
Cost: The activation and fuel energy that must be provided to the machine for it to perform its functions
Throughput: The act of the machine performing its function
Another cardinal rule of the theory of constraints is that throughput should be prioritized as often as possible. The whole purpose of having an inventory and applying a cost is for the machine to perform its function, i.e., for the machine to have throughput.
So, a lawn mower is made of spinning blades, a housing, a motor, etc., and that comprises its inventory. It has fuel costs, gasoline or increasing electricity and generally (with the rising exception of robots) it needs a human to push it across the grass. And its job, or throughput is clear, to cut grass — ideally a lot of grass in a short amount of time. If it is not doing that, then it is just a pile of inventory and cost, not a lawn mower.
Clear Bottlenecks in Developer Experience to Drive Profits
Goldratt’s genius was to realize that since just about every complex system can also be thought of as a complex machine, be it a factory, a human being or in our case a business that profits from software and/or digital transformation, we can begin to think of many broad ways to apply these definitions.
In the case of a software-driven business, or just about every business, we can think of our definitions as:
Inventory: Code, whether bespoke or dependency library
Cost: The human and tooling cost of assembling code
Throughput: Money
If throughput is the job of a complex machine, the throughput of a business is to make money. To further apply Goldratt’s thinking, the goal of a software-driven business should be to assemble as much profitable code as possible, to ship features that are lucrative to the business as efficiently as possible, to drive the throughput, and ultimately profit for the business.
And this is where I’m convinced that we’ve been getting everything wrong, concerning the way influencers are approaching those who have the purchasing power to make real investments in improved developer experience. It needs to be more widely understood that the outcome of investing in developer experience is accelerated time to market and profit, or real, transformative investments will never be made.
Developer joy and accelerated global innovation — these are real and tangible benefits, but they are too esoteric for large organizations to make budgetary decisions. If we want to drive investments in developer joy, we should come to those decision-makers with a profit story.
Improved Developer Experience Means Improved Throughput
Going back as far as The Coding War Games, we have data that shows that the most productive software organizations are the ones that provide the most frictionless experience for their developers. That is still true today, in fact, it can be argued that, given the advancements in automation and orchestration in the delivery pipeline that DevOps has provided, developers have never been more of a primary bottleneck.
When we poll our developers in lower-performing organizations, we find so many reasons for these bottlenecks in their culture: Too much cognitive load directed to valueless tasks, an unreasonable amount of context switching, poorly organized systems of record, sprawling and disorganized toolchains, etc. In other words, poor developer experience.
Conversely, the culture of highly profitable software organizations universally is the result of significant investments made in every area of developer experience, from the onboarding of that developer into the organization, to their day-to-day support and the availability of a continuously improving developer platform. They make investments in highly effective internal developer portals and establish teams of dedicated engineers to focus on developer experience and productivity.
Leaders at the highest level must consider that within the value stream of every software-producing organization, the experience of the opinionated knowledge worker, i.e., the developer, is the area where friction can most critically impact the throughput of the machinery of the organization. We, as thought leaders, not only do a great disservice to our developers and engineers when we focus only on the costs they represent, but we also miss enormous industry opportunities for profit acceleration by not investing heavily enough in the most optimal developer experience possible.
To learn more about Kubernetes and the cloud native ecosystem, join us at KubeCon + CloudNativeCon North America, in Salt Lake City, Utah, on November 12-15, 2024.
