Updated on July 5, 2016 by Greg Pollock
There’s no right place to start with DevOps, but there are reasons that different people choose to start. There are also ways of communicating that make it more likely to take succeed in your organization. Being aware of the people you are talking to and the processes they work within can make your DevOps experiments more likely to grow into a business-wide culture.
A forthcoming study sponsored by Microsoft and conducted by independent research firm Saugatuck Technology digs into the expectations different groups have for DevOps. Spoiler alert: not everyone likes DevOps for the same reasons. You probably know why DevOps sounds useful to you, but getting buy-in from other teams is crucial and tricky. Knowing what others are likely to care about can make it way easier to get them on board and make DevOps a reality.
Developers are most interested in optimizing resources, both in terms of people and infrastructure. This is likely because they do project-based work where a schedule of milestones formalizes how they will be evaluated. Unfortunately, developers have thus far seen less benefit from DevOps than Implementers or Leadership, perhaps because their involvement in deployment appears to be extra work that jeopardizes hitting milestones. (If you’ve never experienced the conflict between “hitting milestones” and “shipping a good product,” The Phoenix Project gives a spot-on depiction.)
If you’re talking to a Developer: Tell them about a development cycle where stable deployments mean less time fixing bugs. Better accounting for deployment work means they can give more accurate scoping and have a more consistent workflow.
Not surprisingly, Implementers are disproportionately interested in automating release cycles and improving mean time to recovery. Whereas Developer work is typically evaluated through a formal project management strategy, Implementer work is commonly viewed through the binary lens of “is the site up or down.” Implementers see the value of DevOps in preventing the latter.
If you’re talking to an Implementer: For years, Implementers have been catching the pig when Development tossed it over the fence. DevOps is the way to make that handoff more graceful. Tell them about a release process with greater visibility and faster recovery when something does go wrong.
The IT Leadership has much higher expectations than Developers or Implementers for their adoption of DevOps in the next two years. They also think their companies have done a much better job adopting DevOps principles than Implementers or Developers do. The disconnect between the perception and expectation of Leadership and the rest of the IT team is a potential source of resistance to DevOps--when one group thinks they’re already half way there while another thinks they’ve barely begun, the distance to the finish line appears drastically different.
IT Leadership is more interested in scaling operations and improving communication and collaboration than the other groups. This is likely because they are more concerned with long term strategy and processes than people doing the day to day work on the next release.
If you’re talking to an IT Leader: Talk about the long term benefits of investing in DevOps. Cultural change in particular is slow to come, but it also yields the biggest dividends.
While the relative interest in a given benefit of DevOps varies between group, the overall trends are fairly similar. Everyone is most interested in improved application/IT quality and more quickly responding to business requirements.
If you’re talking to a random person who you know nothing about: Tell them that DevOps helps business requirements become action items sooner.
Maybe you already knew that Developers, Implementers, and Leaders have different interests in DevOps. After all, you probably are one of those people, and there's a good chance you've experienced miscommunication with other departments. As we dig deeper into the Saugatuck research in coming articles, we'll pull out more interesting facts that can help avoid those awkward moments. Next time: what different business sizes expect from the DevOps and who is experiencing the most success with DevOps today.
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.