Keep CALMS and DevOps: S Is for Sharing

One day, my son came home from kindergarten and was waxing lyrically about: “Sharing is caring.” A simple phrase taught to a child to help them to understand that sharing provides a benefit. I realize that there is a pattern developing here with my use of children’s sayings to convey a point about DevOps, but perhaps that is because these sayings are basic truths. “Measure twice, cut once”, “Sharing is Caring”: the messages are so basic, yet we often don’t follow the wisdom of these simple truths.

Source: The Peanuts Movie

So, if to share is to care, then the opposite must hold true, namely, not sharing means not caring! This might seem harsh, but if we ever find our inner monologue saying, “That’s not my problem” or, “Let them figure it out,” then we are harming ourselves in the long run, because it’s harmful to the success of our company. We can show that we care about our organization by simply sharing. We need to share more and more. Here are some examples of where we could show we care more by sharing:

• If you ever leave the building (“Get Out of the Building”) to visit a customer, prospect, analyst, conference, then you have an obligation to share your findings with everyone.
• If you investigate a new technology, then share your findings.
• If you answer a support query, don’t just provide the answer, go further and explain how you came to your conclusion – “give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime”.
• If we win or lose an account, then we should be able to share findings with the organization, so that continuous improvement actions could take place to improve either people, product, or process.

We should share experiences, successful or not, to enable others to learn. Keep in mind, sharing works both ways; we must take an active interest in learning, we must seek to learn. If we ignore what is being shared, then we are just as guilty of not sharing.

We should be cognizant of our culture and know that most of our sharing will naturally be at our local watercooler. We need to come up with more global watering holes, so that we can share. We must adopt a common practice of sharing knowledge globally to build a stronger more competitive organization.

It boils down to learning and improvement: turning local knowledge and discoveries (what a single person knows) into global knowledge and discoveries (what your entire team or organization knows). We must continuously improve and learn.

Every team needs a convenient way to organize and discuss their work. Suitable team collaboration software is a big help when you need to create a knowledge base, share files, plan projects, collaborate on tasks, store and distribute documentation. Your organization could have a lot of disparate collaboration tools which may be impeding the flow or access to information within the organization. Regardless of the state of your collaboration tools everyone should know where to go and for what i.e.

• Office 365: use this for writing and collaborating on documents and presentations
• Confluence: good as system of record (i.e., final design/architecture, epic details)
• Slack\MS Teams: good for chat and video. Greater adoption and usage required to get to “ChatOps” level.
• JIRA: issue tracking/backlog management. System of record for all work being carried out by a team; critical to the delivery

As we’ve previously identified, to err is human and stuff happens. When something goes wrong, getting to the "what" without worrying about the "who" is critical for understanding failures and improving. We need to trust our team members in that nobody knowingly would make a deliberate mistake. If they did intentionally make a mistake, then that would be sabotage and their next conversation needs to be with HR. We must accept that failure happens, systems are complex and humans make mistakes. Enter the blameless post mortem, this subject is worthy of a blog entry on its own, or read this excellent post from Etsy.

"The cost of failure is education." – Devin Carraway

The individuals involved in a post mortem must feel that they can give this detailed account without fear of punishment or retribution. No finger pointing! Writing a post mortem is not a punishment – it is a learning opportunity for the entire company.

We should adopt the retrospective prime directive:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. At the end of a project everyone knows so much more. Naturally, we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass,” writes Norm Kerth in Project Retrospectives: A Handbook for Team Review.