This article is based on first-hand observations and delegate conversations gathered at the DevOps Enterprise Summit (DOES19) in London. The original piece was written by Mark Smalley, published on devops.com, and draws on his experience as a DevOps practitioner and speaker known as “The IT Paradigmologist.”
Background: Listening at DOES19
The DevOps Enterprise Summit (DOES) is one of the most respected annual gatherings for technology leaders navigating large-scale DevOps transformations. At the 2019 London event, Mark Smalley spent three days at the GamingWorks booth speaking with delegates about a single question: What is your biggest DevOps transformation challenge right now?
The answers clustered into seven recurring themes. What follows is a summary of those themes, enriched with practitioner commentary. If you recognize your own organization’s struggles here, you are far from alone.
1. Business Value
- Understanding the link between day-to-day IT work and overarching business strategy.
- Gaining end-to-end visibility and transparency across the delivery chain.
- Measuring the right things — team performance expressed in terms of business outcomes, not just technical metrics.
Commentary: Many IT professionals struggle not only to understand the business value of their work but also to articulate it clearly to non-technical executives. Bridging this communication gap requires a shared vocabulary and agreed-upon outcome metrics that resonate beyond the engineering team. Frameworks and whitepapers on the business value of DevOps — such as those produced by the DevOps Agile Skills Association (DASA) — offer useful starting points for structuring that conversation.
2. Governance
- Finding the right balance between centralized standardization and team-level autonomy.
Commentary: Governance is frequently cited but rarely well-defined. The core tension is this: standardization can drive efficiency and compliance, but applied too broadly it creates bureaucracy that slows down the very teams it is meant to support. In complex, unpredictable systems, professionals need latitude to exercise judgment. The guiding question should always be: Does this standard actually improve outcomes for the value stream, or does it simply satisfy an organizational need for uniformity? If the answer is the latter, decentralized decision-making often produces better results — even if it costs slightly more to operate.
3. Velocity
- Delivering quickly without sacrificing quality.
Commentary: Speed versus quality is a false binary. The real challenge is sustaining all five dimensions simultaneously: better, value, sooner, safer, and happier — a framing popularized by Jonathan Smart and Sonja Blignaut at Deloitte under the hashtag #BVSSH. Resilient operations, co-created customer value, and regulatory conformance must all remain in the picture as delivery cadences increase. Automating quality gates within CI/CD pipelines is one of the most effective levers teams have for maintaining this balance.
4. Value Streams
- Breaking down organizational silos.
- Improving collaboration across team and departmental boundaries.
- Granting teams greater autonomy over their work.
- Integrating DevOps practices into predominantly non-DevOps parts of the value stream, and vice versa.
Commentary: At conferences, value stream thinking is widely understood. In most IT departments, it remains an alien concept. There is a real risk that practitioners develop an echo-chamber view of how far adoption has spread. The practical implication: when beginning a transformation, meet teams where they are rather than where you wish they were. Cross-team collaboration consistently ranks as one of the hardest soft skills to develop — something confirmed by DevOps Institute (DOI) skills surveys that identify it as a top-priority competency. It may be called “soft,” but it is anything but easy.
5. Operations (Ops)
- Defining what modern ops looks like in a DevOps context.
- Transitioning from traditional, process-heavy ops models to leaner, more adaptive ones.
Commentary: The evolution of ops is one of the most active areas of change in the industry. Frameworks such as ITIL 4 have moved toward a less prescriptive, more value-oriented model — emphasizing value streams, co-creation with service consumers, and human judgment over rigid process compliance. However, ops work is fundamentally different from development work: it is often more interrupt-driven, involves higher stakes around availability, and requires different patterns of working. A healthy DevOps culture must accommodate and respect those differences rather than simply importing dev-centric practices wholesale into ops teams.
6. Organizational Change
- Sustaining momentum after the initial enthusiasm fades.
- Overcoming resistance and organizational inertia.
- Accepting the full consequences of committing to DevOps.
- Unlearning decades of entrenched working habits.
- Building the skills needed to lead and execute transformation.
- Assessing and managing the risks of transformation itself.
- Sharing practices across teams and learning from peers.
- Scaling what works beyond pilot teams.
Commentary: Organizational change is where most DevOps transformations succeed or fail. Too often there is enthusiastic talk at the executive level followed by underwhelming commitment in practice. There is no shortcut. As Taiichi Ohno, the architect of the Toyota Production System, observed: “You have to think for yourself and face your own difficulties instead of trying to borrow wisdom.” Borrowed frameworks and copied playbooks can only take you so far. Genuine transformation requires deep, context-specific problem-solving. Notably, similar patterns were observed at the DOES18 USA event, suggesting these are systemic, industry-wide challenges rather than isolated organizational issues.
7. Culture and Emotions
- Building diverse, cross-functional teams.
- Getting people with very different personalities and working styles to collaborate effectively.
- Building mutual trust across team and organizational boundaries.
- Addressing the perception that non-DevOps teams are less valued.
Commentary: Culture is finally getting the serious attention it deserves in enterprise DevOps conversations. Psychological safety — the degree to which team members feel comfortable speaking up, raising concerns, and being themselves — is a foundational enabler of high performance. Research by Amy Edmondson at Harvard Business School has made this concept mainstream, and it regularly surfaces in Phoenix Project simulation workshops as a critical factor in team effectiveness. Burnout researcher Dr. Christina Maslach offers a sharp analogy that captures the stakes: “You want less toxic mines, not more resilient canaries.” Resilience is a virtue, but it should never substitute for fixing the systemic conditions that cause harm in the first place.
8. Tooling
- Navigating tool sprawl and confusion in the DevOps ecosystem.
- Integrating disparate tools into a coherent, orchestrated toolchain.
Commentary: The DevOps tooling landscape is vast and grows more complex each year. Teams frequently struggle with two distinct problems: first, selecting the right tools from a crowded market; second, making those tools work together reliably in a coherent pipeline. Tool selection should follow strategy, not precede it. Defining what outcomes you need to achieve — faster deployments, better observability, automated security scanning — and then choosing tools to serve those outcomes is far more effective than adopting tools because they are popular or because a vendor presented them well.
Key Takeaways
The challenges reported at DOES19 London are not new, and they are not unique to any single organization or industry. The fact that the same themes — business value alignment, governance balance, collaboration, culture, and sustainable change — recur at every major DevOps event points to something important: these are deep, structural challenges that no tool, framework, or conference talk will solve on its own.
Progress requires honest self-assessment, genuine executive commitment, and the patience to build capability incrementally. Start from where your organization actually is. Measure outcomes that matter to the business. Invest as heavily in people and culture as in tooling and process. And share what you learn — the DevOps community grows stronger when practitioners are candid about what is hard, not just what worked.
Original reporting and commentary by Mark Smalley, published on devops.com. Mark Smalley is a DevOps practitioner, DASA contributor, and speaker known as “The IT Paradigmologist.”