Automation is the force multiplier that makes a DevOps effort so powerful. While it requires the technical skill and know-how to create frameworks for automating processes in an organization, an automation-first mindset is not easy to start out with. The rest of the DevOps anti-patterns are all about different modes of thinking and this one is no different.
All of the previous cultural pitfalls I discussed have been focused on systemic issues with organizations, teams, or groups of people. This is truly the one that requires individual effort to defeat. Even I have to be intentional about sharing what I know that would make others on my team have the same successes. This differs from the Tribal Knowledge Anti-pattern in that organizations create and force single threaded resources. This forces people to “stay in their lane” which creates hard boundaries in what people know how to work on. Information hoarding usually comes from an individual place of fear and insecurity.
In 2017, I took a very hard look at the issue we caused for Quality Assurance teams I worked with. By automating many Operations tasks, we did not speed up the whole development effort of the projects we worked on. The flow of work through an entire system is the only metric that matters to project leaders and clients, not that one particular piece is better. We had unintentionally created a new, bigger bottleneck by not supporting our QA team properly with what they needed to succeed.
“It is better to ask for forgiveness than permission.” A statement like that is pervasive in an organization that follows a decentralized command and control structure. As organizations become more complex, it is nearly impossible for any single person to fully capture detailed information in making decisions. Yet, many companies still try to run significant decision making authority through single threaded resources.
The technology industry has embraced the DevOps definition around the idea that it is used to break down silos and barriers to teams working together. As a portmanteau, the word DevOps clearly states in its own name the purpose of the philosophy. However, just smashing together a development and operations team does not just automatically eliminate silos within an organization.
Personal responsibility and accountability are important traits team members should have in a collaborative work environment. But Super Heroes in the workplace take this mentality to the extreme end of the spectrum. As I review the issues within organizations trying to implement DevOps, this is the most difficult one to reign in. Because this mentality is not far off from an addiction to work, in which the offending resource feels the need and desire to worm themselves into a situation that needs them to save the day.
As I have been digging into the various cultural pitfalls that operations groups can fall into, tribal knowledge is the first one that teams can dig themselves out of. Imagine you are an executive or director that knows that the information you need for your company to succeed is stuck in the head of one of your employees, but you do not know whose mind or what that piece of information is. It is a puzzle or mystery that can only be solved by the organization as a whole.
DevOps has many different meanings depending on the perspective and experience of anyone you might ask. The tech industry generally aligns on DevOps being a set of practices and culture that an organization adheres to in order to deliver operational excellence. DevOps should not be a team, a set of tools, or something you can bring in a consultant to apply to your organization. Excellent leaders in the DevOps space realize that self-reflection and attempts to correct any issues are the most effective ways to improve.
Thanks to the crew at Lean Agile KC for putting together an exceptional LAKC17 this year. I really enjoyed the interaction with everyone curious about operations practices at VML. It was a pleasure sharing how we fixed our DevOps Culture Anti-patterns by learning on our internal portal. And taking a bit of time to go over some additional learning and practices in an Open Sessions was awesome. Thanks to everyone who continued the discussion. See below for the SlideShare and my notes with some of the things I spoke about not directly in the slides.
I have recently been talking about how various books have helped my career in some unique ways, from helping bring some day to day peace, to changing the way I think about working with other teams. One of the most intriguing books I have ever read that impacted not just myself, but my organization is Lean Enterprise: How High Performance Organizations Innovate at Scale (Lean (O’Reilly)). You can re-read my other posts about the influential books below: