Breaking Down the Wall in DevOps

The Wall.

This phrase is often used in the DevOps world to describe the proverbial barrier between teams that prevents collaboration. For example, you might say a development team “throws code over the Wall” to the operations team. The Wall stands as a mental and emotional barrier to an imagined utopia where development, operations, security and quality assurance (QA) all go frolicking arm and arm in a field full of flowers, ready to tackle every problem together.

But what, exactly, is this barrier? If we know it exists, why can’t we make the Wall disappear? No matter how many times someone says DevOps is dead (or old hat or obsolete) while trying to entice you to the newest, shiniest thing, the Wall still appears. The barrier might shift within the organization — after all, every dev seems to want to own a platform (that’s sarcasm), but it is always there, even if the infrastructure responsibilities slide underneath.

What Is the Wall?

In the modern organization, the Wall represents a barrier of ownership, a transition point where teams meet and hand over responsibility for nurturing some part of a product to the next owner. Simply making developers the owners of the infrastructure, as many initially tried when teams moved to hyperscalers, just moved the Wall’s position. The barrier is still there and still a problem.

At any of these transition points, conflict may be found. From ops demanding answers about messy dependencies to devs demanding others treat their project as a golden ideal, the conflict arises at the moment of a handoff, no matter how many times you try to move the Wall. Some organizations try putting everyone on the same team, but there’s still a handoff of responsibility. It’s also not as simple as having one person own everything all the way through, because that owner delegates responsibility to different people at different steps of the process based on their expertise.

These transition points also represent changes in measurements. Development is measured by how many features are released. Operations are measured by how much uptime is gained or maintained. Security is measured by how many systems aren’t breached. QA is measured by how many bugs don’t appear in customer reports.

From a high level, an executive examining the Wall may be baffled at why there is conflict; after all, we all just want to keep the company running and customers happy, right? However, when a developer passes a mistake over the Wall to the operations team, the ops team’s uptime declines. When an ops team decides not to update an operating system for another week to maintain stability, the security team’s concern about a breach increases. People fundamentally cannot take in the wider viewpoint when their job may be threatened by someone else’s choice. Instead, the first instinct is to protect themselves by meeting their measurement. And thus, the Wall persists.

Breaking Down the Wall

If you want to enact change in an organization, you might try to use tooling to overcome the Wall and bring about a cultural transformation. Or you might try to adjust the culture first by shifting ownership around before choosing tooling. An organizational transformation is about making a radical shift to improve an organization. So a cultural organizational transformation is a radical shift that improves an organization’s culture; it’s not necessarily a radical shift in culture that improves an organization. As such, one initial step toward breaking down the Wall may be shifting the company’s measurement structure so that everyone starts and ends on the same page. That radical change in measurement can improve the culture by enabling people to care about other teams’ outcomes.

From a more practical standpoint, to truly remove the Wall does not mean getting rid of ownership — the idea of having a project without an owner is patently ludicrous — or having one person own something the whole way through. It also does not mean isolating layers of your systems so that they are always owned by one team. To truly remove the Wall is to make the transition of ownership more seamless and less conflicting.

Often, we are told that a healthy organization is one where strong communication and psychological safety (among other things) are considered critical. There are key things you can do to reduce conflict: Use common language when starting the software development lifecycle (SDLC) so that there are no surprises when you meet to hand something off. Make mistakes less problematic by making small enough changes on a fast enough cadence that the impact of a mistake is minor and temporary. Address technical debt quickly to avoid overloading any team with too much ownership of something that will never get fixed.

This is the true goal of DevOps. The goal of DevOps is not to scale the Wall with more tooling. Instead, the goal is to erode it, reducing it down to where you can step over it with ease while sharing the burden of ownership — much like carrying a picnic basket together into the next field.