The website uses cookies. By using this site, you agree to our use of cookies as described in the Privacy Policy.
I Agree

"Today I'm going on a rant about the term DevOps. Join me, friends! Here's the rant

Today I'm going on a rant about the term DevOps. Join me, friends! Here's the rant: the term DevOps originally had a completely different meaning from how it's now commonly understood, and I'd like to talk a little bit about why that matters, and what you can do to change it. /1
First, a definition: "DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality." That's from 2008. en.wikipedia.org/wiki/DevOps /2
That's what DevOps is: a set of practices that encourage continuous integration into production. Here's what it's not: a job title, a software tool, a team name, or magic enterprise fairy dust. No practices, no DevOps. /3
More than that, it's a mindset. If you think Devops is something you get by sprinkling DevOps Engineers into your organization without buying into the mindset then you're never going to get the benefit from it that you're hoping for. /4
If you think DevOps is a toolkit and not a practice you're missing the point. If you think it's a role and not collaboration between roles you're missing the point. If you think it's a team and not an organizational feedback loop you're missing the point. /5
The goal of that journey is the acknowledgement and recognition that software is safer when people with complementary skillsets in technical operations and software development work together, not apart. /6
The role of engineering leaders in that journey is to encourage collaboration by creating the right feedback loops. "Balance of power" theories of team structure are dead. The organization doesn't win unless everyone is deploying safely, all the time. /7
If you create a DevOps team, but don't create the right feedback loops, you end up right back where you started: with people in camps that have competing motivations and orthogonal skillsets. Your delivery process might get incrementally better, but the org won't. /8
Here's how you know it's gone wrong: DevOps engineers don't trust product engineers to deploy and don't understand the changesets. Product engineers don't trust the deployment process and don't understand the mechanics. Deployments are unreliable. Nobody is happy. /9
Because DevOps has become a title and not a way of thinking, there is now so much skillset—rather thank mindset—junk attached to the job that we've lost the plot almost completely. The fact that the above failure states are all too common is testament to that. /10
So what can you do to change it? I'd suggest walking away from DevOps titles, but that ship has sailed. Instead do what you can to inhabit the practices on both sides of the aisle within your organization. /11
Don't accept the answer that your responsibilities are completely isolated from, or dedicated to, DevOps. Inhabit the practice of collaboration. Share every last bit of knowledge you have with your neighbors. /12
If you find yourself in a DevOps team then ask yourself: Am I creating incremental change that serves my customers? Am I creating the right incentives for the teams I support to do the right thing? Am I teaching others how to write deploy scripts? /13
If you find yourself in a product engineer team then ask yourself: Am I taking responsibility for change? Am I keeping my changesets small? Am I willing to go on call, or build empathy and share the journey with those who are? Do I understand if my software is healthy? /14
The secret sauce of software development—the philosophical origin of most advancements in thinking over the last 20 years—is incremental change, tight feedback loops, shared knowledge, and mutual respect. /15
Understand that and you understand DevOps. /fin.
While I have you all here: go read The DevOps Handbook. This is a wonderful guide whose chief flaw is the title, which should instead be The How You Should Probably Be Thinking About Software Development These Days Handbook. amazon.com/dp/B01M9ASFQ3 /PS1
Also: I'm currently looking for gigs. If your org is looking to hire someone to run literally anything other than a DevOps team, hit me up, fam. /PS2
Measure
Measure
Summary | 8 Annotations
definition: "DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality."
2021/05/04 10:35
That's what DevOps is: a set of practices that encourage continuous integration into production
2021/05/04 10:35
More than that, it's a mindset
2021/05/04 10:36
If you create a DevOps team, but don't create the right feedback loops, you end up right back where you started: with people in camps that have competing motivations and orthogonal skillsets. Your delivery process might get incrementally better, but the org won't
2021/05/04 10:46
Don't accept the answer that your responsibilities are completely isolated from, or dedicated to, DevOps. Inhabit the practice of collaboration. Share every last bit of knowledge you have with your neighbors
2021/05/04 10:51
Am I creating incremental change that serves my customers? Am I creating the right incentives for the teams I support to do the right thing? Am I teaching others how to write deploy scripts?
2021/05/04 10:52
the philosophical origin of most advancements in thinking
2021/05/04 10:52
is incremental change, tight feedback loops, shared knowledge, and mutual respect
2021/05/04 10:53