What's the point of DevOps?

True organizational culture change helps you bridge the gaps you thought were uncrossable.
611 readers like this.
left and right brain


Think about the last time you tried to change a personal habit. You likely hit a point where you needed to alter the way you think and make the habit less a part of your identity. This is difficult—and you're only trying to change your own ways of thinking.

So you may have tried to put yourself in new situations. New situations can actually help us create new habits, which in turn lead to new ways of thinking.

That's the thing about successful change: It's as much about outlook as outcome. You need to know why you're changing and where you're headed (not just how you're going to do it), because change for its own sake is often short-lived and short-sighted.

Now think about the changes your IT organization needs to make. Perhaps you're thinking about adopting something like DevOps. This thing we call "DevOps" has three components: people, process, and tools. People and process are the basis for any organization. Adopting DevOps, therefore, requires making fundamental changes to the core of most organizations—not just learning new tools.

And like any change, it can be short-sighted. If you're focused on the change as a point solution—"Get a better tool to do alerting," for example—you'll likely come up with a narrow vision of the problem. This mode of thinking may furnish a tool with more bells and whistles and a better way of handling on-call rotations. But it can't fix the fact that alerts aren't going to the right team, or that those failures remain failures since no one actually knows how to fix the service.

The new tool (or at least the idea of a new tool) creates a moment to have a conversation about the underlying issues that plague your team's views on monitoring. The new tool allows you to make bigger changes—changes to your beliefs and practices—which, as the foundation of your organization, are even more important.

Creating deeper change requires new approaches to the notion of change altogether. And to discover those approaches, we need to better understand the drive for change in the first place.

Clearing the fences

"In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."—G.K Chesterton, 1929

To understand the need for DevOps, which tries to recombine the traditionally "split" entities of "development" and "operations," we must first understand how the split came about. Once we "know the use of it," then we can see the split for what it really is—and dismantle it if necessary.

Today we have no single theory of management, but we can trace the origins of most modern management theory to Frederick Winslow Taylor. Taylor was a mechanical engineer who created a system for measuring the efficiency of workers at a steel mill. Taylor believed he could apply scientific analysis to the laborers in the mill, not only to improve individual tasks, but also to prove that there was a discoverable best method for performing any task.

We can easily draw a historical tree with Taylor at the root. From Taylor's early efforts in the late 1880s emerged the time-motion study and other quality-improvement programs that span the 1920s all the way to today, where we see Six Sigma, Lean, and the like. Top-down, directive-style management, coupled with a methodical approach to studying process, dominates mainstream business culture today. It's primarily focused on efficiency as the primary measure of worker success.

The "Dev" and "Ops" split is not the result of personality, diverging skills, or a magic hat placed on the heads of new employees; it's a byproduct of Taylorism and Sloanianism.

If Taylor is our root of our historical tree, then our next major fork in the trunk would be Alfred P. Sloan of General Motors in the 1920s. The structure Sloan created at GM would not only hold strong there until the 2000s, but also prove to be the major model of the corporation for much of the next 50 years.

In 1920, GM was experiencing a crisis of management—or rather a crisis from the lack thereof. Sloan wrote his "Organizational Study" for the board, proposing a new structure for the multitudes of GM divisions. This new structure centered on the concept of "decentralized operations with centralized control." The individual divisions, associated now with brands like Chevrolet, Cadillac, and Buick, would operate independently while providing central management the means to drive strategy and control finances.

Under Sloan's recommendations (and later guidance as CEO), GM rose to a dominant position in the US auto industry. Sloan's plan created a highly successful corporation from one on the brink of disaster. From the central view, the autonomous units are black boxes. Incentives and goals get set at the top levels, and the teams at the bottom drive to deliver.

The Taylorian idea of "best practices"—standard, interchangeable, and repeatable behaviors—still holds a place in today's management ideals, where it gets coupled with the hierarchical model of the Sloan corporate structure, which advocates rigid departmental splits and silos for maximum control.

We can point to several management studies that demonstrate this. But business culture isn't created and propagated only through reading books. Organizational culture is the product of real people in actual situations performing concrete behaviors that propel cultural norms through time. That's how things like Taylorism and and Sloanianism get solidified and come to appear immovable.

Technology sector funding is a case in point. Here's how the cycle works: Investors only invest in those companies they believe could achieve their particular view of success.  This model for success doesn't necessarily originate from the company itself (and its particular goals); it comes from a board's ideas of what a successful company should look like. Many investors come from companies that have survived the trials and tribulations of running a business, and as a result they have different blueprints for what makes a successful company. They fund companies that can be taught to mimic their models for success. So companies wishing to acquire funding learn to mimic. In this way, the start-up incubator is a direct way of reproducing a supposedly ideal structure and culture.

The "Dev" and "Ops" split is not the result of personality, diverging skills, or a magic hat placed on the heads of new employees; it's a byproduct of Taylorism and Sloanianism. Clear and impermeable boundaries between responsibilities and personnel is a management function coupled with a focus on worker efficiency. The management split could have easily landed on product or project boundaries instead of skills, but the history of business management theory through today tells us that skills-based grouping is the "best" way to be efficient.

Unfortunately, those boundaries create tensions, and those tensions are a direct result of opposing goals set by different management chains with different objectives. For example:

Agility ⟷ Stability

Drawing new users ⟷ Existing users' experience

Application getting features ⟷ Application available to use

Beating the competition ⟷ Protecting revenue

Fixing problems that come up ⟷ Preventing problems before they happen

Today, we can see growing recognition among organizations' top leaders that the existing business culture (and by extension the set of tensions it produces) is a serious problem. In a 2016 Gartner report, 57 percent of respondents said that culture change was one of the major challenges to the business through 2020. The rise of new methods like Agile and DevOps as a means of affecting organizational changes reflects that recognition. The rise of "shadow IT" is the flip side of the coin; recent estimates peg nearly 30 percent of IT spend outside the control of the IT organization.

These are only some of the "culture concerns" that business are having. The need to change is clear, but the path ahead is still governed by the decisions of yesterday.

Resistance isn't futile

"Bert Lance believes he can save Uncle Sam billions if he can get the government to adopt a simple motto: 'If it ain't broke, don't fix it.' He explains: 'That's the trouble with government: Fixing things that aren't broken and not fixing things that are broken.'" — Nation's Business, May 1977

Typically, change is an organizational response to something gone wrong. In this sense, then, if tension (even adversity) is the normal catalyst for change, then the resistance to change is an indicator of success. But overemphasis on successful paths can make organizations inflexible, hidebound, and dogmatic. Valuing policy navigation over effective results is a symptom of this growing rigidity.

Success in traditional IT departments has thickened the walls of the IT silo. Other departments are now "customers," not co-workers. Attempts to shift IT away from being a cost-center create a new operating model that disconnects IT from the rest of the business' goals. This in turn creates resistance that limits agility, increases friction, and decreases responsiveness. Collaboration gets shelved in favor of "expert direction." The result is an isolationist view of IT can only do more harm than good.

And yet as "software eats the world," IT becomes more and more central to the overall success of the organization. Forward-thinking IT organizations recognize this and are already making deliberate changes to their playbooks, rather than treating change as something to fear.

Change isn't just about rebuilding the organization; it's also about new ways to cross historically uncrossable gaps.

For instance, Facebook consulted with anthropologist Robin Dunbar on its approach to social groups, but realized the impact this had on internal groups (not just external users of the site) as the company grew. Zappos' culture has garnered so much praise that the organization created a department focused on training others in their views on core values and corporate culture. And of course, this book is a companion to The Open Organization, a book that shows how open principles applied to management—transparency, participation, and community—can reinvent the organization for our fast-paced, connected era.

Resolving to change

"If the rate of change on the outside exceeds the rate of change on the inside, the end is near."—Jack Welch, 2004

A colleague once told me he could explain DevOps to a project manager using only the vocabulary of the Information Technology Infrastructure Library framework.

While these frameworks appear to be opposed, they actually both center on risk and change management. They simply present different processes and tools for such management. This point is important to note when to talking about DevOps outside IT. Instead of emphasizing process breakdowns and failures, show how smaller changes introduce less risk, and so on. This is a powerful way to highlight the benefits changing a team's culture: Focusing on the new capabilities instead of the old problems is an effective agent for change, especially when you adopt someone else's frame of reference.

Change isn't just about rebuilding the organization; it's also about new ways to cross historically uncrossable gaps—resolving those tensions I mapped earlier by refusing to position things like "agility" and "stability" as mutually exclusive forces. Setting up cross-silo teams focused on outcomes over functions is one of the strategies in play. Bringing different teams, each of whose work relies on the others, together around a single project or goal is one of the most common approaches. Eliminating friction between these teams and improving communications yields massive improvements—even while holding to the iron silo structures of management (silos don't need to be demolished if they can be mastered). In these cases, resistance to change isn't an indicator of success; an embrace of change is.

These aren't "best practices." They're simply a way for you to examine your own fences. Every organization has unique fences created by the people within it. And once you "know the use of it," you can decide whether it needs dismantling or mastering.

This article is part of The Open Organization Guide to IT culture change.

User profile image.
Matt Micene is an evangelist for Linux and containers at Red Hat. He has over 15 years of experience in information technology, ranging from architecture and system design to data center design. He has a deep understanding of key technologies, such as containers, cloud computing and virtualization.


As a person with a career of over 30 years in the industry, I watched the rise of DevOps and other buzzwords first with some curiosity and then alarm.

Your article touches only glancing on the people issue in the equation and what it really means.

The entire purpose of development and operations is to create an entity or tool for people (customers is another name for them) to use. If, for any reason, the tool is not usable, useful or available that purpose fails.

Making sure of availability (operations) doesn't garner kudos, in fact if done correctly, in time the question of "why do we even have you" rises.

Making cool new things, using the latest buzzword tools, that benefit the business (and it's customers) is VERY high profile and garners MANY kudos; the faster we get the new tool out, the more opportunities for kudos as we can make more cool new tools... Fix it or enhance it if the customers don't like it? That's not fun and usually has less opportunity to be high profile and garner rewards (see operations above).

THIS is the entire people issue of devops. Small wonder so many operations people want to be developers. Even smaller wonder that developers look with disdain on operations, dismissing the goals of availability.

Unfortunately, devops simply panders to this, trying to hide it and does NOT cure the issue, pretending instead that it doesn't exist.

hello bruce,
I would like to argue some of your comment. But i will say sorry for my bad english, feel free to correct me. i'm only a netwonderer.
i will start with:
The entire purpose of development and operations is to create an entity or tool for people (customers is another name for them) to use. If, for any reason, the tool is not usable, useful or available that purpose fails.

yes, as developer they produce tools for costumers ( consumer ) but as costumer any consumer need money to buy the tools. Even how good a tools is if the costumer doesnt have the capacity or knowledge to efford it , that tools will be a failure, or only effordable or usefull for the few. wish equale to more unequality
And with our technology advancement today, we could robotise, publicise and distribute nearly everything, with a program. and as programing, networking advancement is getting better and better.
who will gain from the developer tools ? those that can afford, exploit or develop.
And who will loose from it ? those that are behind in technology and will keep being behind.
Will a poor kid in africa, or a persone who already having difficulty paying his house bill because he lost his job. be your costumer (consumer) ?
Because with the advancement of today standard, we will not be able to be anybody costumer, if we are not a developer yourself. Simply because tools, are here to replace works (workers, people). And that why the possibility to be a consumer in today standar would be the people who know how to exploit the tools, the one who develope it or the one that can efford it. But if we are not any of them who are we then.
If we keep having a few developer developing tools for fewer and fewer costumer, how will we ever be able to creat more useful tools ? Because even how good a tool is, if the most people don't know how to use it (or doesn't have the means to efford it), with only a few who know how to and have the means too use (exploit). what will the tool be ? What will we be able to develop with a few developer to a few costumer ? Because availability need consumtion, but without consumtion there will not be any need of availability
Making sure of availability (operations) doesn't garner kudos, in fact if done correctly, in time the question of "why do we even have you" rises.
I tried to simplyfied it to my understanding: The second problem would be what if we are all developer creating everything our own tools. who will need developers. ( please correct me if i'm wrong)
My personal point of view would be even how different we are, and how different we as a persone might think or be, we will always have something in common ex: (dream, ambition, goal, expectation, ect ). The difference would be (order, preoritiy, structure, ect).
Only when we can combine the mutual goal and the uncertainity, that is then we will have the possibility to creat something that was unthinkable. we will need (group, organization), wish is corporation today that need a change. But as an uncertainity goes, it can both go well and wrong. That is why the more the better.
will we keep going the way we did even though we already know that is the wrong way. Or are we whiling to take the risk for a better future.

In reply to by Bruce Ferrell


Thanks for taking the time to comment.

I agree with your comments the visibility of daily work to the business. I used to tell my managers (when I was still in ops) that the less they heard from (or about) our team, the better we were doing our jobs.

I argue that the very issue you mention, that places less value on maintenance than new features, is one of the business culture facets that a successful DevOps plan needs to correct. The separation of these phases of application lifecycle into different teams isn't a "natural" split in software engineering, but imposed on software engineering by business thinking.

One way this is reflected is how the business accounts for costs for each team. Capital expenses are tied to the means of generating profit and usually viewed as an investment potential. New application development is usually placed in this category. Operational expenses are tied to ongoing costs and are usually thought of in terms of reductions to the lowest levels without impairing production. Application operations are usually placed in this category. This sort of accounting model is the legacy of hard goods manufacturing, and the latest guidance generally hasn't kept up in software to practices like Agile.

I agree it's also central to people over tools in DevOps. A tools-only or tools-first will simply paper over the culture problem and not cure it. Culture is about the beliefs held by a group of people, and in a business context value of labor and output is part of that culture. This has be to recognized at all levels and conscious effort is needed to change the thought process.

In reply to by Bruce Ferrell

Matt, this is a very fine article! So nice to see the long view and the "why" combined in such a thoughtful fashion. Bravo.

Great article Matt. Here in Tokyo, I'm running into those walls all the time and wonder if they should be there or not. Half of my career I have been on the marketing side (developing markets) and had little connection with the product development people. Now, I'm working directly with those product development people, and we are finding markets globally together. Lots of fun.

Two things you wrote about really resonated with me.

One, is that a changing environment can bring organizational change. With front-line people having access to the same information and sometimes better information than superiors could change the way decisions are made. In some cases a new environment is forced on us. I have a feeling it might be better to go out and seek those new environments.

Two, focusing on new capacities and not on old problems may be the gateway to organizational change. So true.

Ron, thanks for taking the time to comment.

You make a great point, while I focus on the development / engineering split here, these sorts of divides happen all over the organization. The same cultural forces are in play, just different players. Your mention of product development reminds me of an example within Sony where 3 different groups launched 3 separately developed portable music players at the same product launch event.

As an aside, there's also a great next thread that leads to Japan in the storyline. A good portion of current thought in technology draws from The Toyota Way via LEAN and Kanban. Much of the early work in Toyota came from Peter Drucker's work on management science. A seminal piece of Peter Drucker's work came from a 2 year study of Sloan's GM. There are more connections that can be easily explored in a short time.

In reply to by Ron McFarland

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.

Download the Open Organization Guide to IT Culture Change

Open principles and practices for delivering unparalleled business value.