Why giving back is important to the DevOps culture

Our habit of not sharing knowledge is doing us harm.
180 readers like this.
Bubble hands

Opensource.com

In the DevOps CALMS model (which stands for Culture, Automation, Lean, Measurement, and Sharing), Sharing is often overlooked or misunderstood. While each element of CALMS is just as important as the others, sharing knowledge is something that we often neglect.

What happens if we don't share?

Jeff Smith, director of production operations at Centro, tells this story:

A change to the level of granularity that gets stored in one of our reporting tables was made. The change increased the disk space usage on the database instance by 8x. Not only did this cause our existing database instance to rapidly fill up, but it also made operations question if the design pattern made sense. Because they weren't included in such an impactful change, all of the design decisions that went into the new process architecture were viewed as suspect and underwent a constant re-examination from ops. In a nutshell, a little bit of faith and trust was lost.

The damage caused by eroding faith can't be understated. Collaboration is based on trust. Every time this trust is chipped away, energy is spent on questioning the validity of decisions made by others.

What are the benefits of sharing?

Today's systems are incredibly complex. The days when one person could hold an entire infrastructure and system interdependencies in their head are long gone. Communicating across boundaries of expertise makes our entire organization more robust and resilient.

Sharing isn't just about the technical data or access, though. "Inter-team communication should always start with the goal, not with one team's proposed solution to a problem," Jeff says. "When you start with a solution, the conversation veers in the wrong direction."

Emily Freeman, CloudOps advocate at Microsoft says "Collaboration is impossible without sharing information." She points out that having a "mental map" of the skills and knowledge of other teams "enables people to ask questions more efficiently and reduces the fear they're asking too many questions or look stupid."

How can we share better?

"Sharing doesn't have to be a drum circle every Tuesday at 10:30am," Emily says. "It's openness and authenticity. It's removing the shadows from your organization and ensuring everyone is honest and forthright and accountable."

At a minimum, there should be read-only access to logs, code, and after-incident reports for everyone. Before you cry "separation of concerns," please consider that the data that cannot be shared with everyone in the organization is a much smaller set than we usually think it is. It might require some additional effort to scrub and protect this small subset than to default to "nobody can see anything but their small part of it," but the benefits outweigh the effort.

"If anyone's excluded, they aren't part of your team, no matter what the org chart says," Emily reminds us.

It's more than the logs and the tooling, though. "The 'S' is often just seen as knowledge sharing, training, etc.," Jeff says. "But if it doesn't include the sharing of responsibility and ownership, it can be difficult to get your organization to that next level of productivity."

Why don't we share?

There are many reasons that sharing information and knowledge isn't the default position for knowledge workers, but both Emily and Jeff agree it usually comes down to fear.

"Teams may feel that only their circle is capable of performing a particular task with the zeal and delicacy it deserves," Jeff says. "So information gets siloed, access gets restricted, and gates get constructed. But that diminishes our responsibility to build safe systems, instead leaning on 'operator expertise' as a crutch."

Emily agrees. "DevOps cultures never look to change the past," she says. "Instead, the companies that thrive at embracing the DevOps philosophy are realistic about where they are and work toward continuously improving their process so everyone on the team can thrive."

What to read next
Tags
Matty Stratton
Matty Stratton is a HumanOps Advocate at PagerDuty, where he helps dev and ops teams advance the practice of their craft and become more operationally mature. He collaborates with PagerDuty customers and industry thought leaders in the broader DevOps community, and back when he drove, his license plate actually said “DevOps”.

3 Comments

Sometimes people want to share but they don't know how. Do you have any experience how to solve this cases?

Use Twitter as sort of a concise blogging platform. Just a quick tip about something that you did today can be enough! Beyond that, you can try building a blog with WordPress or Gatsby for making it more useful.

Often it's better to write a blog and quote yourself than to quote a resource that might not be there one year down the road.

Hope that helps.

In reply to by Nelson Marcos (not verified)

This is so true. I truly believe sharing can make things better. What I try to do is encourage more and more Developers and DevOps folks to have blogs. Those are always fun to read — sometimes better than companies engineering blogs.

Experiences shared by people in a similar situation as you — go a long way in helping build trust between them + you (and sometimes even with the company you work for).

Peace! ✌️

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

Download the ultimate DevOps hiring guide

Build your DevOps team with these best practices for prospective employees and hiring managers.