This article is based on a piece originally published on sdtimes.com (September 2017). The core concepts draw on Lean principles, including the Efficiency Matrix framework described in This Is Lean (Modig & Åhlström, 2013).
The Problem: Plenty of DevOps Advice, Not Enough Direction
Enterprise IT teams are rarely short of reading material on DevOps and digital transformation. What is consistently missing is a concrete map of the journey—a way to understand where an organization actually sits today, what the intermediate steps look like, and what a successful end state means in practice.
Lean thinking fills that gap. More specifically, the Lean principle of flow efficiency over resource efficiency gives organizations an honest framework for diagnosing their current state and charting a credible transformation path.
Flow Efficiency vs. Resource Efficiency: The Core Distinction
Understanding Lean starts with this distinction:
- Resource efficiency focuses on maximizing the utilization of individual teams, tools, and processes. Each function is optimized locally, in isolation.
- Flow efficiency focuses on optimizing the connections between resources—how work moves through a system end-to-end to create value for the customer.
Traditional enterprise IT is built around resource efficiency. Frameworks like IT Service Management (ITSM) and project management organize work into functionally separated silos—development, QA, operations, security—each accountable for its own goals and metrics. When the primary value being delivered is stability, consistency, and resilience for internal customers, this model works reasonably well.
Software delivery, however, has a different goal: to ship high-quality, full-featured software that delights stakeholders—continuously and reliably. Achieving that goal requires treating the entire software delivery lifecycle as a single, integrated, flow-efficient system. That is DevOps.
The Efficiency Matrix: Mapping the DevOps Transformation
The Efficiency Matrix—a concept borrowed from This Is Lean (2013)—provides a practical abstraction for understanding where an organization is and where it needs to go. It plots resource efficiency on one axis and flow efficiency on the other, and identifies five meaningful positions on that grid.
A: The Perceived Starting Position
This is where most enterprise IT organizations believe they sit at the outset: high resource efficiency, low flow efficiency. Teams are locally optimized, tools are in place, processes are documented. Leadership senses that software delivery is struggling, but there is a reluctance to commit to transformation—partly because the status quo appears to be functioning, and partly because past transformation attempts may have stalled.
The rationalization is familiar: Why disrupt working structures for uncertain gains? Can we not just tune the existing resource-based approach?
The hard truth is that organizations relying on traditional functional silos to deliver software are already generating enormous waste—through multiple handoffs, broken workflows, unnecessary approval gates, constant rework, and poor knowledge sharing. The product that eventually ships often carries significant defect load, security vulnerabilities, and technical debt. There is no incremental fix for this; the structure itself is the problem.
B: The Actual Starting Position
The reality is that most organizations are not at Point A. They are already deep in what the matrix calls the wasteland: resources that cannot deliver software without extreme inefficiency, and organizational goals that are fundamentally incompatible with the velocity and responsiveness modern software development demands.
The first and most critical step in any transformation is therefore an honest awakening: accepting that the current state is wasteful in every meaningful sense, not just in isolated areas.
This is often the hardest part of the entire process. It requires changing the perception of senior leadership—demonstrating that the organization is not at Point A, and that the risk of transformation is smaller than the risk of standing still.
A practical approach to building this organizational conviction is to run a pilot: apply DevOps principles to a single team or product, measure the outcomes, and use that evidence to build executive buy-in before attempting a broader rollout. A transformational leader who can translate those results into business terms is essential at this stage.
C: Increasing Flow Efficiency
Path C represents the central work of transformation: moving the organization toward flow efficiency by redesigning the software delivery capability as an integrated end-to-end system.
There is no single universal blueprint for this, but there are well-established foundations:
- Transformational leadership that actively motivates and models change
- A culture of experimentation and collaboration that treats failure as information
- Horizontally structured teams with shared ownership of outcomes, not just tasks
- Extended Agile practices that go beyond development to include operations, security, and product management
- Deep toolchain integration that reduces handoffs and makes work visible across the entire pipeline
The goal at this stage is not yet to optimize individual resources—it is to make the system work as a whole. This mirrors what Lean thinking has demonstrated in manufacturing and other sectors: systemic integration must come before local optimization, or local optimization simply makes the wrong things faster.
D: Increasing Resource Efficiency
Once flow efficiency is established, the organization can begin optimizing individual resources—but now as a deliberate function of the system’s overall performance, not in isolation.
Flow efficiency makes it possible to instrument the system meaningfully: to collect targeted metrics, identify real bottlenecks, and drive continuous improvement with visibility into how any change affects the whole pipeline.
This is when practices such as continuous integration, continuous delivery, test automation, and WIP (work-in-progress) limits can be implemented with a clear understanding of their systemic impact. As W. Edwards Deming observed, the ability to measure everything does not mean everything should be measured. With good integrations in place, it becomes clear which metrics are genuinely decision-relevant.
E: The Final State (Which Is Never Final)
The end state of a DevOps transformation is not a stable plateau—it is a dynamic equilibrium. The organization will continuously encounter new constraints: changing customer requirements, emerging market pressures, technical debt, security vulnerabilities, and unexpected incidents.
Crucially, in this final state, resource efficiency is not maximized. Deliberate slack capacity is maintained so the organization can respond quickly to unplanned work without sacrificing delivery commitments. This is a direct inversion of traditional IT thinking, which equates full resource utilization with efficiency.
A flow-efficient system is dynamic, responsive, and capable of absorbing change—which is precisely why it delivers more value over time than a resource-maximized but brittle alternative.
Conclusion: Flow Efficiency as True North
A DevOps transformation is, at its core, a deliberate organizational choice to design around system-level flow efficiency rather than local resource optimization. In practice, that means:
- Integrating the software delivery lifecycle so that work flows end-to-end without unnecessary handoffs or bottlenecks
- Calibrating individual resources in response to the system’s evolving flow requirements—not the other way around
- Continuously monitoring pipeline health and rebalancing capacity as the business and technology landscape changes
Flow efficiency is the True North of Lean-guided DevOps transformation. Organizations that internalize this principle gain a clear direction of travel—one that makes the abstract promise of DevOps concrete, measurable, and achievable.
Without it, transformation efforts risk optimizing the wrong things faster, entrenching silos in new tools, and ultimately delivering the same waste under a different name.