DevOps: How A Culture of Empathy Creates Massive ProductivityMarch 1, 2016
The culture of DevOps is based on 4 simple pillars—AKA “CAMS”
- C = Culture
- A = Automation
- M = Measurement
- S = Sharing
CAMS was coined by Damon Edwards and John Philips in Silicon Valley back in the 90s and early 2000s as a way to define the culture of empathy.
The word “empathy” is often thought of as “hippie hug-outs.” But the reality of building company CULTURE is considering how we work with others.
There is Strength In Building Company Culture
The term DevOps is about learning a different way to work. It’s cross—functional.
“It doesn’t mean I do everything myself,” said Matt Stratton, senior solutions architect for Chef. “It does mean that I approach my team in a cross-functional way.”
The CAMS mindset is not compartmentalized—a trap some organizations fall into by rewarding individual achievements at the expense of the team.
“It isn’t I do my thing, and then I pass it off to you. I don’t care what the person did before me, and what the person does after me.”
When you’re looking to bring DevOps talent onto your team, approaching it with this dynamic will teach you how to increase employee productivity and create a more satisfied team.
Automation Creates Replication
“If the build, deploy, test, and release process is not automated, it’s not repeatable.” Jez Humble and David Farley, Continuous Delivery. “ When steps are taken manually, they are error prone, and there is no way to review exactly what was done.”
In order to fix what goes wrong, or repeat what went right, you need to have a system for building company culture in place that can be repeated.
Measurement: Aligning Goals
Once you have a team of DevOps talent, the next question is HOW do you align incentives? When incentives work at cross-purposes, you end up with a lose-lose situation.
For example, Matt’s team at a previous company was challenged to write one new software test. Result: everyone wrote a test, but nobody tested anything. The incentive was tied to writing, not testing, so the strategy failed. Why? The team was not aligned to each others goals.
To understand this better, you need to turn to game theory and outcomes. The beautiful mind of John Nash devised a solution concept known as the Nash Equilibrium.
Using his system, we can determine when we have a Nash Equilibrium, or a win-win situation. A broken traffic signal is a good example of this. Even if there were no police around, the 2 drivers will likely choose to obey the law and stop, so neither driver crashes. One driver must allow the other to go, The other options are they both go, and crash, or no one goes. Cooperation for the best outcome is required. One driver will decide to allow the other to go, or go, and expect the other driver to wait.
Watch a Video on The Nash Equilibrium here
Nurture a Blame Free DevOps Environment
People are adept at hiding problems when they think they’ll be punished for their mistakes. It doesn’t help them make fewer mistakes, and, on top of that, you have no idea what’s going on in your environment or how to increase employee productivity.
One of Matt’s customers developed the “blameless post-mortem.”
“The thing is, people are always going to make mistakes. You can’t fix that. People are human. So stop trying to fix them. Instead, we fix systems. That’s what we mean when we say we have a blameless post-mortem.”
“For example: if a website goes down, we fix it. We don’t sit there and say it’s because John or Jane deleted these files. We identify the slip, but we don’t sit there and say it’s because you messed up. We’ll punish you, so you don’t do it again.
Instead, we say—how was John or Jane even able to do that? Then we make the system more resilient. Then, when a human makes a mistake it doesn’t crucially compromise the system.”
Sharing: Feedback At Point of Foul is Essential
The upside of the Blameless Post Mortem is the opportunity for each member of the team to weigh in on what went wrong.
Where can they automate better? How can the team act to improve? How muck quicker can they turn around and get the product into the hands of the customer?
“It’s a culture of SHARING. People collaborate and work together toward the common end.”
Achieving Continuous Delivery
How do DevOps teams win the Super Bowl Ring of building company culture to get software into the hands of customers—also known as continuous delivery?
They do it by following the CAMS formula.
- They respect the CULTURE by respecting each other
- They AUTOMATE wherever possible to eliminate error
- They MEASURE progress, and
- They SHARE feedback freely without blame
Matt Stratton, Senior Solutions Architect at Chef, is also one of the founders at ArrestedDevOps, a wildly popular podcast devoted to all things DevOps.
His suggestion for how to find and retain DevOps talent: Think like they think.
- Be prepared to develop a team, not just an individual.
- DevOps talent can be called System Admin or Software Developer. It all depends on their current company.
- Don’t just hire. Retrain the people you already have.
- Change behavior, change culture.
- Be intentional about who you’re trying to recruit. Know how their core competencies will meet the demands of your position.
- Align your incentives so teams are not working at cross-purposes.
Read our post on embracing the new company culture of DevOps here
Matt Stratton’s 4 books aspiring DevOps MUST read:
- The Phoenix Project by Gene Kim: The “Why” for DevOps
- Continuous Delivery by Jez Humble | David Farley: Definitive work for DevOps
- Lean Enterprise by Jez Humble: DevOps for companies of all sizes
- Switch by Chip Heath: It’s about transformation