To get the most value from DevOps, top enterprises avoid these 6 pitfalls
By Bradley Clerkin, CTO
By now, you’ve probably seen hundreds of articles on how to “do DevOps.” Like our posts on optimizing the digital triad, DevOps dos and don’ts, and more.
So, in this post, let’s talk about ways NOT to do DevOps and supply some methods that savvy CIOs use to avoid these common anti-patterns and operationalize DevOps in a way that leads to their ideal digital outcomes.
1. DevOps is owned by X.
Can a specific team own DevOps? No. Not if you want to optimize DevOps correctly. Saying one team handles DevOps is like saying there’s one group responsible for the whole of IT management. It must be a full-team effort.
IT leaders who claim they have one team covering DevOps may be thinking of DevOps from a pre-digital lens, in which asset management was the prevailing concern. Perhaps they’ve bought a technology with DevOps in the title and have one team using that technology. Thus, the team using “DevOps technology” becomes the team who owns DevOps in their mind. But using DevOps technology does not make that team capable of performing the broad transformation needed to optimize DevOps.
2. We can buy DevOps.
Again, this goes back to the pre-digital, asset-focused mindset (if you haven’t read our post on pre- and post-digital values, read it here for a better understanding of this article). Leaders falsely think that if they check all the boxes in the ‘DevOps catalog,’ securing all the assets in the DevOps toolchain, they’ve suddenly operationalized DevOps. This procurement only ensures that the company has spent a considerable sum of money to access beneficial technology. When IT leaders truly operationalize DevOps, they realize it’s a mindset, not just a tool set.
3. DevOps is something we can hire.
The enterprise can’t hire their way toward optimizing DevOps. For now, the idea that you can publish the proper job postings and hire enough DevOps engineers to operationalize DevOps is false. Not only is the technology management operating model too broad to be one person’s or team’s job, but it’s also challenging to find the right people. Just because a well-meaning engineer puts DevOps in their title or resume doesn’t mean they will be able to operationalize DevOps throughout an organization. Their experience could come from a company who misunderstands DevOps...
4. DevOps is a developer thing.
We see non-developers assume that DevOps doesn’t apply to them. This feeling likely comes from DevOps’ branding and naming issue, which leads people to think DevOps is about the processes that guide software development. It’s much broader than that and involves nearly everyone on the team—not just developers. 5. We can train our way to DevOps.
Leaders can’t simply train their teams on DevOps to optimize it in the organization. After the training, the employees will better understand DevOps technologies. But without a change program that includes leadership, it won’t be truly optimized.
6. Executive edicts that announce, “full-scale change.”
We often see this as the first approach companies go toward because they’re early in their digital transformation and don’t know any better, or as the last-ditch effort when their operationalization is failing, and they think it’s their only option. The truth is the amount of work necessary to perform a full-scale institution is a considerable investment that will likely not pay off. When companies try to go “full-scale,” they’re inserting DevOps everywhere, losing sight of their specific goals. It doesn’t make sense to add DevOps blindly. It would help if you pragmatically instituted DevOps in places where you’re going to see the most benefit in terms of goal realization. The addition of digital revenue generating channels is too important for your business; don’t let these anti-patterns inhibit your success. At BreakFree, we’ve created a roadmap of how to avoid these anti-patterns to properly operationalize DevOps, Cloud and Agile. Check it out in this article.