DevOps transformations look simple on paper. Take an existing environment, add the Spotify model, throw in SAFe, sprinkle some Team Topologies, add DevOps and platform engineering, stir well, add as many tools as possible, and stir again. What happens? It crashes. And people say “DevOps is bullshit.”
The problem is not DevOps. The problem is how organizations approach the transformation. In this video, I share the anti-patterns and lessons learned from my years of doing DevOps transformations across industries at Zühlke.
What Companies Want to Achieve#
Before diving into the anti-patterns, let me clarify what companies actually want from a DevOps transformation. The top five goals I encounter are:
- More value for the money (increased efficiency)
- Faster time to market
- Higher quality
- Higher customer satisfaction
- Top qualified employees (winning the war for talent)
And the challenges they face? Legacy systems and processes, budget constraints, talent management, culture and change management, and the alignment between IT and business.
Anti-Pattern 1: Missing Sense of Urgency#
The first lesson learned is about the sense of urgency at the C-level. When top management lacks urgency, the transformation becomes a series of meetings with many PowerPoints but no decisions. Topics get discussed endlessly without progress.
The sense of urgency can come from two sources: a burning platform (the company must change now) or a visible future threat (a challenger is coming). When management wants to do a DevOps transformation, I always ask “Why?” at least five times to get to the root cause.
I use Dr. John P. Kotter’s Eight Steps of Leading Change, where the first step is creating that sense of urgency. If you cannot establish urgency at the C-level, you can stop right there. You will only achieve a small transformation because you lack the mandate for big changes.
“If you don’t have a sense of urgency at the C-level, the only thing you will do is a small DevOps transformation.”
Anti-Pattern 2: Missing Leadership Commitment#
Even when the C-level has the sense of urgency, middle management can block progress. They like the status quo. They fear losing control and influence. They focus on short-term wins and may completely lack understanding of what a DevOps transformation aims to achieve.
The solutions:
- Peer learning: Connect your managers with peers from companies that have already done the transformation. This is one of the best recommendations I can give.
- Education and training: Middle managers need to understand DevOps to lead the change.
- Clear expectations: The C-level must set explicit goals, KPIs, and measurements for the transformation.
- Business alignment: Extend the transformation beyond IT to include the business, or face massive resistance.
- External experts: Engage people who have been through it before.
Anti-Pattern 3: One-Size-Fits-All#
“We implemented the Spotify model.” “At Google, they do it this way.” This is a dangerous path. Your context is different. When you implement a framework by the book without thinking, you get confusion, resistance, and relabeling. Your three-month release cycle becomes a “PI” (Program Increment). Your project manager gets the new title “RTE” or “Scrum Master.” Nothing actually changes.
The solution: define your own values, not the values of a framework. Define your principles that guide decisions. Define outcomes, not outputs. Establish a clear purpose that answers your employees’ question: “What is in it for me?” And always inspect and adapt.
“Use frameworks as a toolbox. Take out what fits your need and solves your problem. Do not apply them by the book.”
Anti-Pattern 4: Forming a DevOps Team#
This happens on the lower management level: “We want to do a little bit of DevOps, so let us create a DevOps team.” That DevOps team becomes just another silo between development and operations, adding more walls of confusion to the value stream.
The root cause is resistance to change. The solution is to have a clear goal, adopt a product mindset, organize across the value stream, and apply budgeting according to value streams instead of departments.
Anti-Pattern 5: Busyness#
Everyone is busy. Calendars are completely full. Everything is done to only 60%. There is no excellence. And burnout rates are high.
The root cause is multi-loading: people assigned to multiple roles, multiple products, and multiple projects simultaneously. I regularly encounter people assigned to 10% across ten different projects. They can attend meetings and align, but they cannot create real value.
My rule: people contributing to a product or project must work at least 60% on that single product or project. If they cannot, they are not part of the team (they might be subject matter experts, but they are not contributors). If you cannot find enough people at 60% or more, you do not start the project, or you stop another one first. This is nothing else than limiting work in process by limiting capacity.
Anti-Pattern 6: Going Full DevOps Without a Platform#
“All product teams will now do you-build-it-you-run-it and handle everything themselves.” The result: inconsistency, redundancy, bad time-to-productivity, and burnout. The cognitive load is simply too high when every team must manage infrastructure, CI/CD, monitoring, security, tooling, and cost management on their own.
The solution is platform engineering. A platform team builds a centralized platform with standardized tooling, secured environments, and self-service capabilities. Product teams build on top of this platform. They still own their products, but the platform reduces their cognitive load so they can focus on creating value.
This is not a new silo. The platform team creates a product that other teams want to use.
The Digital Factory: Putting It All Together#
When you apply all these lessons, you arrive at the digital factory model:
- Board level: Lean portfolio management with a clear vision and prioritized initiatives based on monitoring data
- Product level: Product management that connects strategy with execution
- Team level: Empowered product teams that build, run, and maintain their products
- Platform level: A platform team that provides the foundation with standardized DevSecOps, runtime, security, monitoring, and CI/CD
The platform team generates value for the teams. The product teams generate value for the customers. Data flows from monitoring back to teams for improvement, and back to the board for strategic decisions.
Success Criteria for DevOps Transformations#
- Know what you want to achieve. Get C-level backup, define clear goals and outcomes (not outputs), and take a holistic view.
- Your context is different. Use frameworks as a toolbox, not a prescription. Use your brain.
- Leadership, leadership, leadership. Leaders must lead by example with an agile mindset. If leadership does not go first, it will not work.
- Build the right thing. Use lean portfolio management to prioritize initiatives and focus on outcomes.
- Build the thing right. Invest in platform engineering, standards, and quality.
- Hire software engineers, not programmers. You need engineering discipline, not just coding skill.
- You are never done. A DevOps transformation is not a project. It requires continuous improvement forever.
Key Takeaways#
- Sense of urgency is non-negotiable. Without it at the C-level, you will only achieve marginal improvements.
- Leadership commitment at every level is essential. Use peer learning to bring resistant managers along.
- Never apply frameworks blindly. Define your own values, principles, and outcomes. Inspect and adapt continuously.
- Avoid creating DevOps silos. Organize across the value stream with empowered product teams.
- Fight busyness with focus. Enforce a 60% minimum allocation per person per product. Limit work in process.
- Platform engineering prevents cognitive overload. A standardized platform enables product teams to do DevOps at scale.
- We are entering the age of industrialized software development. Digital factories, built on platform engineering, are how organizations will continuously deliver value.