DevOps Culture Clash: Think Process

Even the most charismatic leader can't just tell people to change from a silo-based culture to DevOps. You have to gradually introduce new goals, one pilot project at a time.

Lori MacVittie, Principal Technical Evangelist, f5

October 14, 2014

4 Min Read

I'm a fan of the "CAMS" approach to defining DevOps, which brings together the concepts of culture, automation, measurement, and sharing as a way to understand what DevOps is all about. What I'm not a fan of? Focusing on culture over all else.  

If DevOps is a cultural shift, something must initiate that shift, and that something must be powerful enough to change the practices, values, and goals of operations (across all of IT, but that's a topic for another day). Unfortunately, even the most charismatic team of consultants can't just walk into an organization, point out why its current silo-laden culture is broken, and tell people to change.

Well, they could, but it wouldn't do any good.

Changing a culture is a process that requires leaders to introduce new goals and incentivize practices that gradually shift values and attitudes toward the desired outcome. If you want to engender a culture of collaboration across longstanding IT silos, you can't just send a memo. Leaders must support initiatives that challenge the status quo.

[Here are 10 things we wish Apple would make happen in its next operating system: Mac OS X Yosemite: What's Missing?]

Leaders must also realize that change doesn't happen lock, stock, and barrel over a few weeks. That's akin to rip and replace, and it's never been a successful IT strategy. Ever. An IT leader does not set his people and organization up for failure by introducing unattainable goals. Saying all of IT will meet ambitious objectives for MTTR, error rates, and frequency of deployments by the end of the quarter is unreasonable.

Instead, focus on a single project. That's not only reasonable but is typically how any new technology or methodology is brought in to the enterprise -- through an initial "pilot" project. Select a venture that will benefit from automation and ops' collaboration with development teams to improve the overall deployment process and ensure it meets the desired measurements.

Assuming success, the pilot gets "rolled out" to other efforts, and so on, until the entire IT organization has embraced the changes, accepted the measurements, and the culture it embodies is established as the new normal.

A few more concepts: You can't change culture overnight, and when a bunch of engineers are involved, you also can't do it by appealing to "soft" outcomes. In a "society" like IT where culture may be defined as "the set of shared attitudes, values, goals, and practices that characterizes an institution or organization," change happens when you prove results.

Ultimately, the folks who have to meet goals are interested primarily in, well, meeting goals. That means showing what actions they need to take, and how to make results happen. They will necessarily focus on automation and programmability because those are the tools that will enable them to succeed -- and keep their jobs.

Culture is a byproduct of results.

Extending a DevOps approach to operations isn't going to happen overnight any more than agile was adopted overnight by development teams. Heck, agile adoption -- another cultural change -- is still not pervasive. Though most organizations have "gone agile," they have done so only for a portion of their projects.

DevOps is likewise going to "go DevOps" (yes, I said it, and I'll probably say it again in the future) for only a portion of projects initially. With hundreds (and often thousands) of applications needing deployment, an organization simply can't flick a switch and become DevOps. It takes time, and practitioners in the trenches need concrete direction to enable that cultural change.  

Is DevOps about culture? Yes. But it isn't about forcing a culture on an organization by implementing strict measurements and requiring absolute adherence to meeting them on Day 1. Cultural shifts take time, and they spread from person to person, group to group, project by project. As successes mount, more and more groups and projects will want "in" on the secret because they, too, are struggling under an increasing load of apps and services that the business needs now and consumers need fast. They want to become more efficient, better able to scale out to meet demand. DevOps makes that not only possible but probable.

Don't try to push a cultural change from the top down. Focus on empowering operations across all of IT to achieve goals, and your people will embrace sharing and collaboration and personify the cultural shift we all agree has to occur.

InformationWeek's new Must Reads is a compendium of our best recent coverage of project management. Learn why enterprises must adapt to the Agile approach, how to handle project members who aren't performing up to expectations, whether project management offices are worthwhile, and more. Get the new Project Management Must Reads issue today. (Free registration required.)

About the Author

Lori MacVittie

Principal Technical Evangelist, f5

Lori MacVittie is the principal technical evangelist for cloud computing, cloud and application security, and application delivery and is responsible for education and evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University. She also serves on the Board of Regents for the DevOps Institute and CloudNOW, and has been named one of the top influential women in DevOps. 

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights