A guest blog post from Mike Loukides, Vice President of Content Strategy for O’Reilly Media, Inc.

The systems we build—whether they are technical, social, or organizational—are increasingly complex and distributed. We’ve reached a point where we can’t understand, see, or control all the moving parts, yet we are responsible for the resilience and performance of these systems.

How do we build websites that perform well, scale to millions of users, and are always up? One place to start is breaking down the wall between development and operations. The following is an excerpt from my recent article, The Evolution of DevOps, in which I explore the impact and expanding influence of DevOps culture, and how to leverage DevOps at your organization.

The Culture of DevOps

There’s a continual debate within the DevOps community about whether DevOps is fundamentally about culture, or whether it’s about processes (like CD) and tools. I’m sympathetic to the idea that DevOps is first and foremost about creating a culture in which developers and Ops staff work with each other with mutual respect. But to take either side of this debate by itself invites trouble. Effective DevOps is a good resource for balancing the roles of culture, methodology, and tools.

Many tools are associated with DevOps. I’ve mentioned some of them (in a very general way). But one of the biggest mistakes management can make is mistaking the tools for the reality. “We use Chef to automate deployment” doesn’t mean you’re doing DevOps. All too often, we see organizations that “automate deployment” without changing anything about how they work: they’re using the tool, but they’re still doing big, complex, multi-feature releases. Or they’re using the tool in production, but not in development. Managers need to avoid “cargo culting” at all costs: adopting the terminology and the tools without changing anything significant.

A less common, but equally fatal, mistake is to swallow uncritically the line that DevOps is about culture, not tools. So gather all your devs and Ops staff around a campfire and sing Kum Bah Yah. DevOps is all about automating everything that can reasonably be automated, and that inevitably involves tooling. You’ll see tools for testing, for continuous integration, for automated configuration and deployment, for creating containers, for managing your services, and more—even for randomly breaking things. The tools can’t be ignored.

Focus entirely on culture, or entirely on tools, and you’ll lose. You need both.

Doing DevOps

How do you get an organization “doing DevOps?” “Doing DevOps” isn’t that good a phrase, but there are some answers. Don’t go out and hire a bunch of “DevOps specialists.” Thinking about DevOps as a distinct specialty misses the point: DevOps is about getting existing groups working together, not about creating a new specialty or a new group. Definitely don’t go out and pick new DevOps-friendly office furniture. (I won’t give you the link, but that’s not a joke.) Seriously: mistakes like these send the message that you don’t know what you’re looking for, and will drive away the people you really want to hire. Though you may end up with better office decor.

If you want to get started with DevOps, start small. It started as a grassroots movement, so let it be a grassroots movement at your company. Pick a project—perhaps something new, perhaps something that’s been a problem in the past—and see what happens when you get the development and the operations groups working together. See what happens when you build pipelines for continuous deployment, use modern tools for monitoring, and get your developers and operations staff talking to one another. A top-down “We are now going to do DevOps across the company” message is likely to fail. Instead, start small, and let everyone see the results. The report DevOps in Practice shows how DevOps was introduced at Nordstrom and the Texas state government.

You don’t need to start with the project that’s most excited about doing DevOps—that might backfire. It’s hard to evaluate your progress if everyone is heavily invested in seeing a new practice succeed. By the same token, you should probably avoid groups that are resistant to change, or that see ideas like DevOps as a fate worse than death. They’ll only be convinced when they see results in other groups.

It doesn’t matter a whole lot where you start, as long as you start. DevOps isn’t about heroes, rock stars, ninjas, or unicorns; it’s about regular developers and Ops staff getting out of their silos and working with each other. It’s about automating everything that can reasonably be automated, because doing so reduces the time spent fighting fires and increases the time you can spend improving your products and services. Ultimately, that’s what’s important.

To learn more about how to leverage DevOps at your organization, attend the O’Reilly Velocity Conference, taking place in New York City (Oct. 1-4) and London (Oct. 17-20).