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.
Category: Technology Blog
Here you will find my walk throughs, musings, thoughts, and experiences in working with technology over the years of my career.
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.
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”.
A friend shared this link with me and asked if these are good steps to making a transition into a DevOps role form more traditional IT experiences.
https://enterprisersproject.com/article/2017/9/devops-jobs-5-tips-transitioning-devops-jobs
I have some issues with these five things that are supposed to help transition someone to a “DevOps” job. Instead of focusing on trying to find a job that fits some key buzzwords, I suggest working towards some general career development goals.