I’ve talked to a lot of people from a lot of organizations about DevOps. For those who aren’t familiar with DevOps and the benefits it can bring, they often ask, “How do I know if I need DevOps?” I’ve discovered a lot of signs that are good indicators of when an organization could really benefit from going through a DevOps transformation. Here are my top five.

See if this situation sounds familiar to you. You start the release window at 10 PM on Friday night. You open a conference bridge so everyone can talk about the issues happening with the release – and there are many. Incorrect configuration settings. Missing files. Inconsistent data. A lot of people saying, “I don’t know what’s wrong. It works in the [upstream from production] environment.” You work through the weekend and barely get the release in before the window closes at 5 AM on Monday… or not and you have to roll it back and do it again in a month during the next release window.

Systems go down. It’s inevitable. No one has yet built a system with perfect uptime. The issue is not so much that a system goes down (it will), but when that system does go down, how long does it take to bring it back up? The metric for this is “Mean Time to Repair” (MTTR). That metric might be a lot higher than you would like. Discovering an outage often starts with customers notifying you of a problem through your support desk, rather than through IT’s monitoring of the system to detect the outage. And that’s just the beginning. Once you know there’s an outage, you have to figure out what caused the outage. And once you’ve figured out what caused the outage, you have to fix the issue and bring the system back up. All of that takes time and results in lost revenue, drops in customer satisfaction, and negative brand impact.

How often does your organization do releases for its systems? Are those releases cycles measured in months or quarters or (gulp) years? The longer the release cycle, the harder it is to respond to change and the more contentious planning and prioritization sessions are because people are trying to get their needs met as soon as possible. What happens if you discover a bug in production or missing feature that could produce a lot of value? How difficult is to make the change to address it and get it into production? Or do you just accept your fate, shrug your shoulders, and say, “We’ll get it in next quarter.” If your competitors have more agility than you, they’re beating you to the punch.

The typical conclusion following an IT failure is that there wasn’t enough review to prevent the failure. So the typical response to this typical conclusion is to add more review and signoffs, usually from people who are the least qualified to provide the review because they are disconnected from the work being done. Ironically, this response only increases the chances of future failures because it increases the amount of work in progress, adds more people into the value stream (who aren’t always adding value), and increases the cycle time for the work being done. All are killers for getting quality work done quickly.

For a simple indicator of an organization with silos, take a look at the IT org chart. Do you see a large number of highly specialized teams? Like DBAs, NetOps, InfoSec, Storage, Servers, Quality Assurance, Configuration Management, PMO, … Does the organization use cross-functional teams to get work done? Or does everyone live in their specialized groups with the exception of the occasional “all hands” meeting? The culture and siloed structure of the organization discourage people from working together and that impairs communication, collaboration, and the organization’s ability to achieve good outcomes.

If you are experiencing any of these signs, you need DevOps. If any of these signs rise to the level of 8, 9, or 10 on the “How painful is it?” scale, you need DevOps now and might also have enough of a case to start a DevOps transformation within your organization. And in any case, there’s always something you can do to address these signs – even if that something is small – to make life better for you, your team, and your organization.