Most engineering organizations do not fail at DevOps because they picked the wrong tools. They fail because nobody mapped how capabilities (including AI), metrics, and day-to-day practices are actually supposed to reinforce each other. Teams adopt CI/CD, containers, and dashboards, then plateau, because the tooling was never connected to a coherent strategy for how the organization changes its behavior.
That gap, the space between "we bought the tools" and "we actually changed how we work," is what my latest peer-reviewed research addresses. The paper, "Strategic initiatives in DevOps adoption: a case study," was just published in the Software Quality Journal (Springer), and it is the practical continuation of the PhD research I completed at ISCTE-IUL on DevOps capabilities and metrics.
The problem the paper investigates
Organizations integrate DevOps to move faster, but mapping the dynamic interrelationship between capabilities, metrics, and processes in practice remains a persistent challenge, both academically and operationally. Most DevOps transformation efforts I have seen, and led, treat metrics as a reporting exercise rather than a steering mechanism. Dashboards get built. Nobody changes behavior because of them. That is metrics theater, not DevOps maturity.
The research designed a structured case study to trace how strategic initiatives, not just tools, actually drive successful adoption: which relational mechanisms make the difference between an organization that measures activity and one that measures outcomes and adapts.
Why this matters beyond the paper
I did not write this from a purely academic vantage point. I have run the version of this problem at scale: driving platform engineering for 53 Kubernetes clusters and 22,800+ servers, and more recently owning engineering-metrics tooling that gave a security engineering team its first trustworthy, real-time view of throughput and escalation aging. The gap between having metrics and using metrics to drive strategic decisions is not theoretical. It is the single biggest lever I have seen separate teams that plateau from teams that compound.
What I would tell any engineering leader running a DevOps transformation right now:
- If your metrics do not change a decision within a quarter, they are not strategic initiatives; they are noise with a dashboard.
- Capability maturity and tooling maturity are not the same curve. Organizations regularly buy their way to the second without touching the first.
- The relational mechanism between capability, metric, and process has to be designed on purpose. It does not emerge from good intentions or good tools alone.
If you are in the middle of a DevOps or platform transformation and want to talk through where the strategy is or is not connecting to the metrics, I am always up for that conversation.
Full paper: https://link.springer.com/article/10.1007/s11219-026-09765-4