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:
This week I have talked about a couple of books that have impacted my work and career. Please go back and read the following posts about two that have shaped me into the engineer and manager that I am today:
The book that really gave a gut punch to my specific day to day capabilities was Site Reliability Engineering: How Google Runs Production Systems
This week I am going over a few resources that I have run across that have shaped, changed, or completely rocked my career in technology. Today I want to start with the book that started my current career arc in a way that led to some of the best outcomes like working a sane number of hours per week, dealing with fewer panicky late night issues, and having an overall increase in career and personal wellness. I know that is a lot to put on just one book, but it was so impacting in a way that made me realize that I should not just keep doing my job the same way “because that’s the way we’ve always done it”.