This article is based on analysis originally published by Principal Analyst Charles Betz at Forbes, drawing on Forrester’s Predictions 2020 report. The original post appeared on December 5, 2019.
What Was Predicted for DevOps in 2020
As 2019 drew to a close, analysts at Forrester Research laid out their forecasts for where DevOps practices would head in 2020. Three predictions stood out: chaos engineering moving into governance contexts, business value displacing velocity as the primary success metric, and the rise of embedded, just-in-time developer learning tools. Each of these reflected real tensions that engineering teams were already grappling with at the time.
Prediction 1: Chaos Engineering as a Controls Strategy
For most of its early history, chaos engineering was treated as a purely operational discipline — a way to harden distributed systems by deliberately injecting failure. The conventional wisdom was that production was sacred and that risk had to be contained through environment boundaries: development, staging, QA, and only then production.
The Forrester prediction challenged that framing. As systems grow too complex to fully exercise in pre-production environments, chaos engineering becomes one of the few practical tools for identifying risk at scale. Rather than viewing “testing in production” as inherently reckless, the argument was that disciplined chaos experiments — with proper observability and blast-radius controls — could serve as a legitimate mechanism within governance, risk, and compliance (GRC) frameworks.
In practice, this means treating chaos experiments as structured risk identification exercises rather than cowboy operations. Teams that can demonstrate they have systematically probed failure modes in production-like conditions are arguably in a stronger compliance posture than teams that rely entirely on pre-production testing that cannot replicate real-world scale or dependency complexity.
Key implications for engineering teams
- Chaos experiments should be documented, scoped, and tied to specific risk hypotheses.
- Observability infrastructure (metrics, tracing, alerting) must be mature before meaningful chaos testing is possible.
- GRC and platform engineering teams need a shared vocabulary for discussing controlled failure injection as a risk management practice.
Prediction 2: Business Value Will Overtake Velocity as the Favored Metric
Deployment frequency, lead time for changes, and similar velocity-oriented metrics — popularized through frameworks like DORA — were the dominant way DevOps teams demonstrated progress. The prediction was that this would shift in 2020, with business outcomes taking priority over throughput proxies.
The underlying driver is the narrowing gap between IT and the broader business. As digital products become core revenue streams rather than supporting infrastructure, executives and product owners increasingly want to know what software delivery is actually producing in terms of customer value, revenue impact, or risk reduction — not just how fast code moves through a pipeline.
Velocity metrics are valuable, but they are proxies. A team deploying fifty times a day can still be building the wrong things, or shipping features that do not move key business outcomes. The prediction anticipated that mature DevOps organizations would add outcome-oriented metrics — things like feature adoption rates, customer retention impact, or revenue attributable to specific releases — alongside, or instead of, pure throughput measures.
Practical considerations
- Teams need instrumentation that connects deployments to downstream business events, not just pipeline stages.
- Product management and engineering need shared dashboards and a common definition of “value delivered.”
- Velocity metrics remain useful for diagnosing bottlenecks; the shift is about what gets reported upward, not about discarding engineering-level telemetry.
Prediction 3: New Tools Will Help Developers Learn Without Leaving Their Workflow
The third prediction addressed a structural challenge in how engineering teams are built and maintained. The traditional approach — rotating individuals across teams based on skill-set needs — was identified as increasingly counterproductive. Research into high-performing teams consistently shows that cohesion, shared context, and established working relationships are significant contributors to team effectiveness. Constant reorganization erodes these qualities.
The alternative is keeping teams stable while investing in continuous learning within the team. However, the pace of change in development tooling, cloud platforms, and architectural patterns makes traditional training approaches — multi-day offline courses, certification programs, batch learning — poorly suited to the pace of daily engineering work.
The prediction was that tooling would emerge to support “just enough” learning integrated directly into the development workflow. Rather than pulling engineers away from their work to learn new technologies, learning would be embedded in the context of real tasks — documentation surfaces, interactive examples, AI-assisted guidance, or in-IDE prompts that provide relevant knowledge at the moment of need.
What this looks like in practice
- Context-aware documentation and code examples surfaced inside the IDE or CI/CD interface.
- Lightweight learning modules triggered by the specific technology or pattern a developer is currently working with.
- Team-level knowledge sharing practices (internal wikis, architecture decision records, mob programming sessions) that spread knowledge without requiring individuals to leave the team.
Beyond the Three: Broader Trends Worth Watching
The Forrester report also noted two additional dynamics that were shaping the DevOps landscape at the time. First, DevOps practices were expanding into new vertical markets — industries like financial services, healthcare, and government that had historically been slower adopters. Second, and perhaps counterintuitively, release frequency across parts of the industry was stagnating or declining, suggesting that the broad DevOps adoption narrative was masking significant variance in actual practice maturity.
Both of these trends point to a maturing field that is moving beyond its early-adopter phase into the harder work of mainstream adoption — with all the organizational, regulatory, and tooling challenges that entails.
Takeaways for Engineering and Platform Teams
Looking back from a later vantage point, these predictions identified real directional forces even if the specific timelines were compressed or extended by events. Chaos engineering has continued to mature as a discipline. Business outcome measurement remains an active area of investment for platform and product engineering teams. And the question of how to support continuous learning without disrupting team stability has become more pressing, not less, as the tooling landscape has expanded rapidly.
For teams building or refining their DevOps practices today, these three themes — risk-aware experimentation in production, outcome-oriented metrics, and embedded continuous learning — remain worth engaging with directly.
Original analysis by Principal Analyst Charles Betz, Forrester Research. Originally published via Forbes.