A great barrier to DevOps is a lack of transparency in how decisions are made or in how something gets done or in explaining why something happened.

I’ve seen so many times throughout my career that someone doesn’t want to explain something. A software or a service vendor explaining a malfunction is my favorite example because engineers or salespeople or support technicians don’t want to say anything about what went wrong. They’re fearful of speaking if their words will be taken as if on the company’s spoken word, and they’re quite sure that they’re not authorized to speak like that. And so they ask themselves the same old question “How much am I allowed to say, and what do I defer to my supervisors to explain?” When in doubt, they and we all will say as little as possible.

That strategy of silence is a generally strong one. On the two extremes of no information or of all the information, the much less common extreme is being able to give all of the information openly. There’s many reasons why we couldn’t give all the information on an incident post-mortem: security concerns, privacy concerns, competitive advantage concerns, or any of a number of other concerns. This leaves the remaining two options: no information or a tiny little bit of information.

The above hypothetical abstract thoughts on a scenario are geared towards business-to-business (B2B) interactions. B2B is a clear battle line: two businesses interacting with each other trying to maneuver for the best deal possible for each of themselves.

A much less clear idea of a scenario is a business that has a software development team, a project management team, a software operations team, a quality assurance team, an accounting team, a business analyst team, and every other team you might think of. The battle lines here might seem as obvious as each team fighting for what’s best for their team and for the business. But then there’s that catch that all these teams ostensibly share a common purpose: to do what’s best for the business.

What is best for the business? Keeping the lights running is the first order of business. Yes, perhaps there’s new product development, there might always be that. The unsung heroes of the business world are those brave souls quietly working on what’s already there and doing their best to make it better. So of course I’m going to pick on those poor brave soul’s world.

Assisting the unsung heroes or being the unsung heroes are the Subject Matter Experts (SMEs). SMEs are everywhere and they have one or both areas of knowledge: international and compliance standards practices, or whatever the heck the business is doing to operate. These experts aren’t limited to any profession or job title. The reason that I bring SMEs up, is that they are the eternal gatekeepers of knowledge and information, and knowledge is a dangerous thing.

A competent subject matter expert ladling information out of their soup of a brain will often distill a vast amount of knowledge down to what the request actually asked for, no more and no less. This is amazing! Unfortunately the only thing more dangerous than knowledge is a subset of that knowledge.

The worst part about giving a tiny little bit of information and about being transparent is that observers now believe they are informed. And the first thing that “the informed” do is stop asking questions and start using that information to make assumptions and decisions.

When a subject matter expert is asked a question, what follows internally in their mind may be a whole mental calculus. The years of experience, the step-by-step formulation, and the assumptions that they make will not be visible to the questioner.

To cut to the chase, I am differently phrasing the need for non-ceasing communication. Communication is the backbone of DevOps as most relevant literature keeps saying. Anyone who makes the mistake to stop asking questions on the basis they know enough has made the wrong choice.

Now returning to those poor brave souls keeping the lights running: many employers have existed for years, and are likely to exist for at least a few more. Over time, most any employer will come up with some internal system of culture, of politics, and of achieving balance and perhaps harmony. The most limiting form of culture is where fear reigns. The most intriguing form of culture is where transparency and openness reign.

Transparency is a good pathway towards DevOps. Transparency in how a decision was made is extremely useful. Receiving an answer to a question is so important and is so valuable. Even more valuable is when a DevOps practitioner can be given the entire step-by-step of how a decision was made.

Utilizing all available information in order to make the best decision possible is a time-honored tradition that everyone should do. And the best accompaniment is the knowledge that we don’t have all knowledge. The best way to get the knowledge we don’t have is communication in a culture of transparency.