The “S” Is For Sharing
Mike Tyson, the fearsome heavyweight boxer that ruled the late 80’s, once said:
“Everybody has a plan until they get hit.
Then, like a rat, they stop in fear and freeze.”
It’s quite a striking visual, pun fully intended. The other variant is “until they get punched in the face”.
That is what most “culture change” feels like. When I was at Siebel Systems, the executives felt the company was losing its focus during a period of rapid growth. The grand idea was to have everyone read the book “Who Moved My Cheese”. This was not well received.
What they saw as “losing focus”, I saw as people getting too comfortable reciting the sales scripts and corporate messaging. Hubris was taking hold, we were not listening to customers and prospects, and we were not seeking advice from colleagues.
So I started sharing what I learned about my customers. I wrote up and presented market analyses, key challenges & opportunities, anything that would help us gain a better understanding of our customers. I even created day-in-the-life demos so teams could see how customers used our software to do work.
The impact was immediate. I was regularly called on to assist in deals that eventually turned into hugely successful customers. But there was no systematic way of incentivizing sharing, so useful information more often than not was horded or forgotten. This was my first inkling into an intractable problem in large companies, the lack of shared learning across teams.
Fast forward fifteen years later, there are better ways of sharing information inside companies. There are chat rooms and email listservs, social workplace platforms, wikis and discussion forums, etc. For developers though, finding useful shared learning, the type that helps solve problems, is still a major struggle (and rarely addressed by management).
This is starting to change with the growing adoption of DevOps. As businesses realize the criticality of software delivery performance to achieving business objectives, they are taking DevOps more seriously and looking at frameworks like CALMS to assess progress of adoption.
“The CALMS model gives a good frame of reference to compare the maturity of a DevOps team, and as such, is invaluable for assessing the state of teams for the transformational change that goes with it.”
Culture is the foundation of DevOps, and change is an inevitable aspect and outcome of adopting DevOps. However executives often attempt to force culture change from a top-down, command-and-control fashion, issuing decrees with the expectation that staff will fall in line. This never works as the change is superficial, holding only long enough until new leadership takes over.
This is why the “S” in CALMS is so important. The “S” is for sharing, and since the stated goal of DevOps is for developers and ops to work better together to get code into production faster, it stands to reason that sharing would be a necessity for DevOps adoption.
Organic sharing flips the top-down approach to culture change on its head. Change happens on the ground as people exchange value directly. Instead of silos and information hording, the organization shifts to a “default open” culture where shared learning becomes the cultural norm.
So how exactly does one enable organic sharing? I spoke at length about the marketplace dynamics of knowledge, and the key is having content worth sharing so that value and incentives for content contribution can be established.
Does this have to be a big, bold initiative? No, we want to avoid the top down approach and allow developers to connect and help each other instead. One idea is to use community platform to become the “knowledge exchange”, building a trust bank that grows with usage and time. Each deposit to the trust bank is an answer to a question asked by someone else, building the repository of content, and adding value to many others.
There are of course other ways to enable sharing. What makes a community platform unique is the value exchange mechanism. Then you can integrate systems like chatbots, messaging apps, social platforms, etc., to ensure faster and wider distribution. Thus the community creates the canonical body of institutional knowledge collecting and sharing content across these other communication and collaboration channels.
A community driven platform is the best, low friction way to enable the fast exchange of knowledge that can be easily found and reused. Especially in the context of DevOps, such a platform has enormous value in keeping teams across development and operations on the same page while helping developers be more productive.
This is the subtle insurrection that launching a community introduces. By helping developers to help each other, it builds an organic, bottoms-up approach to culture change, or as I like to say:
“Open sharing is the delivery mechanism for changing culture.”
Does culture change in your organization feel like a “punch to the face”? How are you enabling sharing to more organically foster culture change?
How can a company recover after a Glassdoor debacle?
Oof, that’s gonna have an impact on hiring devs…
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.
