I have had the opportunity to present this topic any many conferences this year and feel it is a critical topic for teams trying to make progress in their DevOps journey. Please feel free to continue the discussion with me on twitter @tomcudd.
Tag: ops Page 1 of 2
Thanks for everyone attending the Nebraska.Code() Conference. After the jump, check out a previous version of my slides and some notes on the topic I collected. I’ll likely be updating the slides a bit more soon, and will post when that happens on twitter.
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.
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 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”.