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 Opensource.com’s forthcoming guide to open organizations and IT culture. Register to be notified when it’s released.