Broken windows is a criminology theory that says that if you let one window to be broken in an unoccupied building, more windows will be broken — as the building degrades, sooner or later a band of squatters will settle in. In a short time, the broken-into building becomes a hub where crime gravitates in the neighborhood. The theory suggests that, by tackling petty offences, police officers can effectively reduce citywide crime.

But broken windows theory goes deeper that just patrolling officers and crime watching.

It deals with changes in the cultural and social fabric of a community. It deals with social boundaries and how people adapt to the increasing diversion that starts with one seemly trivial incident such as a broken glass (or graffiti, littering, etc.). When a person walks by a broken window, perception of the surrounding changes. The domino effect starts with how a person reacts to the proliferation of rundown areas. Most avoid them. Some feel detached from that part of the community. Others join in and break more windows.

As a neighborhood becomes segmented, people tend to avoid the streets and start forming silos. Social silos tend to be intolerant with non-conforming members. They tend to exclude people and do not communicate with other silos. Another consequence to a siloed structured is disregard to a governing body and a general sense of distrust in common goal seeking.

Does it sound familiar?

In an organization, there can be many “broken windows” that pop-up here and there and can quickly degenerate into silos or even ghettos. So what are broken windows in the context of DevOps?

• saying “their problem not mine” is a broken window
• a feature that the customer does not want/need/understand is a broken window
• radical changes is a broken window
• only trusting talented heroes is a broken window
• people trying desperately to deploy into production at 2am is a broken window
• thinking it’s over because it’s committed is a broken window
• a design decision taken unanimously is a broken window
• lack of good, actionable metrics is a broken window
• inconsistencies is a broken window

To remedy silo-formation, organizations tend to throw processes and meetings into them. Committees get set-up. More reviews meetings. Evaluations, bonuses, performance boosters and team-building events with motivational speakers. But all of these are just patchwork that is not actually tackling the root cause.

So how do we avoid broken windows? We can’t. We can’t avoid unwanted behavior to pop up somewhere. You can’t crush creative impulses and human nature by demanding allegiance to the gods of DevOps. This is not about setting up a crime watch program.

The way we avoid broken windows from tempering with our DevOps journey is by promoting transparency from all ends of the cycle. Transparency is what disrupts silos and promotes collaboration, which means not only identifying broken windows early on, but also empowering the organization to change. A team empowered to change can overcome anti-patterns before they snowball. Lack of transparency, on the other hand, is precisely what generates growing distrust among teams.

An empowered team is a team that heals itself

When an organization is transparent and empowered, it starts to generate positive reinforcement, which is how transparency scales up. People who feel empowered to improve the organization tend to be more accountable for their actions. Transparency is therefore a team value that can be both triggered by individuals or trickle down from upper management. That’s how we practice transparency. But how do we implement it? We implement it with technology.

That’s why DevOps IS so much about technology: a lean toolchain with actionable metrics that cover the spectrum end-to-end. Technology is the ultimate enabler of transparency, empowering organizations to deliver and improve continuously, overcoming the fear, uncertainty and doubt that seem to plague broken communities.