This article draws on ideas attributed to Mirco Hering, Asia-Pacific Agile and DevOps lead at Accenture and author of DevOps for the Modern Enterprise, as reported by TheServerSide.com.
The Hidden Problem with Most DevOps Transformations
Many of the mental models applied to DevOps processes originated in manufacturing — lean production, flow efficiency, waste elimination. These concepts are genuinely useful, but they carry an implicit assumption that is dangerously wrong when applied to software organisations: the idea that a transformation has an end state.
According to Mirco Hering, Asia-Pacific Agile and DevOps lead at Accenture, the fundamental flaw in most enterprise DevOps programmes is exactly this. Organisations treat DevOps as a three-to-five-year transformation project. They invest heavily, reach what they call an “end state”, then reduce headcount and investment. Without continuous attention, technical debt begins to accumulate, capabilities erode, and the cycle eventually starts over — often with a new consulting engagement.
The pattern is expensive, disruptive, and entirely avoidable if organisations change their underlying model.
DevOps Is a Journey, Not a Destination
A more effective approach is to treat DevOps as a continuous, evolving practice rather than a finite project. This means accepting that today’s tools, architectures, and methodologies will eventually be replaced by better ones — and designing the organisation to make that replacement manageable and routine rather than traumatic.
Hering describes this as an “anti-transformation transformation”: instead of pursuing a big-bang change programme, organisations build the internal capability to change continuously. When there is no finish line, developers and managers think differently about the choices they make today. Architecture decisions account for future replaceability. Tool selections weight vendor lock-in more heavily. Governance processes are designed to evolve.
“Agile or DevOps is not something you can do. It is a journey.”
Mirco Hering, Accenture
The Three Dimensions of a Sustainable DevOps Strategy
Hering identifies three interlocking dimensions that software development managers must address together. Improving only one or two of them produces limited, fragile results.
- Technology architecture — how systems are structured and how easily they can change
- Organising and managing knowledge work in IT — how teams, processes, and governance operate
- Ecosystem of vendors and applications — the external partnerships and products that DevOps depends on
1. Technology Architecture: Holding Costs vs. Transaction Costs
Architecture decisions carry two distinct types of cost that organisations frequently conflate. Holding costs are the ongoing costs of maintaining existing systems and infrastructure. Transaction costs cover everything involved in releasing new software: governance approvals, environment provisioning, testing pipelines, security reviews, and deployment processes.
A common failure mode: a team adopts smaller batch sizes and shorter release cycles — a sound DevOps practice — but leaves its governance process unchanged. If that governance process was designed for a nine-month release cycle, it becomes a bottleneck that negates the throughput gains from CI/CD pipelines. Reducing transaction costs is not optional; it is a prerequisite for continuous delivery to deliver its promised value.
2. Organising Knowledge Work: Replace Status Decks with Data
Governance costs also show up in how teams communicate with management. In many enterprises, development teams still produce slide decks for programme reviews. Those decks get filtered, summarised, and polished as they move up the management hierarchy, until the version that reaches senior leaders contains little actionable information.
A more effective approach is to instrument projects with consistent metrics from the start, then use that data to generate real-time dashboards tuned to each layer of management. When data is normalised to standard metrics across projects, outliers become visible automatically — and managers can focus attention where it is actually needed rather than on polished summaries that obscure problems.
This also means rethinking how developers are engaged. Hering notes that many developers build exactly what they are specified to build — which does not always produce business value. Bringing people together from across the software development lifecycle to discuss real business challenges gives developers the context they need to make better decisions at the feature level, without waiting for a business analyst to translate requirements through multiple layers.
3. The Human Implications of Automation
Automation is frequently discussed as straightforwardly positive for DevOps maturity, but its human and metric implications deserve more careful thought.
Simple, repetitive tasks — password resets, environment provisioning, standard deployments — are the easiest to automate. These are also the tasks typically handled by more junior staff. Automating them shifts the overall composition of work toward more complex, creative, and difficult problems. The team becomes more experienced on average, and the work remaining is harder on average.
This has a counterintuitive effect on metrics. A measurement like mean time to restore (MTTR) may actually increase as DevOps matures, because automation handles the quick, easy incidents immediately, leaving only the genuinely hard problems for humans to resolve. If leadership is watching MTTR without understanding this dynamic, they may conclude that DevOps is making reliability worse — the opposite of reality. Understanding this context is essential before using MTTR or similar metrics to evaluate DevOps programme health.
Applying DevOps Thinking to Vendor Relationships
The third dimension — the vendor and partner ecosystem — is where business model inertia does the most damage. A genuine DevOps culture requires the freedom to experiment, which means accepting that some experiments will fail. Most enterprise vendor contracts are structured in a way that penalises failure, creating a contractual barrier to the very experimentation DevOps depends on.
“The contracts in place prevent people from trying new things. To address this challenge, managers need to develop a relationship with partners that allows some kinds of failures that don’t kill the business.”
Mirco Hering, Accenture
Vendor selection criteria also need to change. Feature lists are easy to compare on a spreadsheet, but they are a poor proxy for the engineering quality that DevOps actually requires. When evaluating platforms and tools, software development managers should weight capabilities that directly support DevOps practices:
- Autoscaling — can the platform scale up and down automatically in response to load?
- Self-healing — can it detect and recover from common failure modes without human intervention?
- Observability — does it expose the telemetry needed for meaningful monitoring?
- Changeability — how easily can the solution be modified, extended, or replaced as requirements evolve?
What This Means for Engineering Leaders
The practical implication of Hering’s framework is that DevOps adoption is not primarily a tooling or methodology problem — it is a business model problem. Organisations that invest in CI/CD pipelines, containerisation, and automated testing while leaving their governance structures, vendor contracts, and management reporting unchanged will see limited returns and are likely to end up repeating expensive transformation cycles.
The organisations that sustain DevOps benefits are those that build continuous improvement into their operating model: treating architecture decisions as temporary, governance as a metric-driven activity rather than a document-driven one, vendor relationships as collaborative experiments, and automation as something that changes the nature of work rather than simply reducing headcount.
There is no end state. Engineering leadership that internalises that fact is better positioned to build organisations that improve consistently rather than transform expensively and repeatedly.