Organizations that have built a positive DevOps culture have transformed as part of a continuous and ongoing journey. The members of the organization should have a noticeable difference in how they behave presently versus how they behaved in the past. If the ultimate goal is to change the way the entire organization functions and operates, that means two things: changing the way everyone in the organization thinks about how they work and changing the way people behave.
Tag: culture
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.
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”.