Changing Org Structures for the Sake of DevOps?

Updated on June 29, 2017 by UpGuard

As it has been said many times: DevOps is not a technical problem, it is a business problem. The struggle for a large, entrenched Enterprise IT shops can't be underestimated and the legacy factor has to be dealt with (aka. why fix something that isn't broken). However, there is mounting evidence to suggest that independent, discrete teams are in fact becoming more common in these large Enterprises. While the fully-embedded model (sometimes called NoOps because there is no visible/distinct Ops team) that the unicorns have deployed work for them, a more discrete team to learn how to 'do DevOps' makes a lot of sense for the larger Enterprise.

On April 16th, we held our second webcast as part of the DevOps Experts Series. The webcast featured a panel of experts that navigated the ins-and-outs of DevOps for the Enterprise:

Along with other topics that we explored was the ever-pressing question as to how a DevOps team gets built. As it has been said many times: DevOps is not a technical problem, it is a business problem. The struggle for a large, entrenched Enterprise can't be underestimated and the legacy factor has to be dealt with (aka. why fix something that isn't broken). However, there is mounting evidence to suggest that independent, discrete teams are in fact becoming more common in these large Enterprises. While the fully-embedded model (sometimes called NoOps because there is no visible/distinct Ops team) that the unicorns have deployed work for them, a more discrete team to learn how to 'do DevOps' makes a lot of sense for the larger Enterprise. The impact of different devops cultures from start-ups vs. enterprise IT has to be considered.

One interesting example is Rob Cummings (@opsrob) of Nordstrom and their journey (he calls it Leveling Up Your Change) of spinning out a team to figure it all out and then reintegrating them back in once they've proved it worked in the context of their business. If you want to brush up on DevOps patterns and team topologies, check out Matthew Skelton's (@matthewpskelton) great overview here.

Two thirds of all respondents have changed or are considering changing their organizational structure for the sake of DevOps.

In our webcast, we posed the question "Are you considering changing org structure for the sake of DevOps?" as a live poll to the audience and learned that nearly two thirds of all respondents have changed or are considering changing their organizational structure for the sake of DevOps. In our live poll, 13% of all respondents responded that they have already changed their organizational structure with another 47% stating that while they haven't made the formal change, they are actively talking about doing so. Only 27% of all respondents said they were not considering changing the org structure. What will be interesting to watch for is further evidence of these teams (whatever form they take) beginning to be created inside of large Enterprise settings and to learn how they create and drive business transformation in the face of change.

Exactly which DevOps team structure or topology will suit an IT Enterprise depends on several things:

  1. The extent, strength, and effectiveness of technical & business leadership; whether IT and the business have a shared goal.
  2. Whether an organization has the capability or appetite to change.
  3. The solution set of the organization: fewer products make for easier collaboration, as there will be fewer natural silos.
  4. Whether the organization has the capacity or skills to take the lead on operational concerns.

In reality, a combination of more than one org structure and team design, and one transforming into another over time, will often be the best approach.

Are you considering changing your organizational structure for the sake of DevOps? How so and more importantly why? Leave your comments!

Other Great Resources on This Topic