I think my favourite quote bandied about in the DevOps world is one from Jesse Robbins: "Don't fight stupid. Make more awesome." In just six words he manages to convey the toxicity and dysfunction prevalent in many IT departments as a result of the perfect storm of the internet coming of age and establishing itself as mission critical to all organisations alongside the ever-increasing complexity and fragility of IT systems. And how DevOps is here to help us out of that and into a place where innovation can be pushed to market without friction or risking stability.
Change is Hard
But changing deeply embedded habits is hard and DevOps is all about evolving a culture to one where awesomeness is made and taken to market daily by people happy and enthused by their work. Jesse has some tips on how to enact this kind of change:
But what are these metrics he speaks off? How should we celebrate success and what is a compelling event in this context?
There are hard, quantifiable DevOps process metrics you can use to baseline your state and build business cases:
- Volume and frequency of application release
- Elapsed time for an application release
- Number of defects in a given time period
- Time taken to fix a defect
- Outage occurrence
- Web application performance impact on revenue
Straightforward, huh? Well, not always. It's not always that easy to find these figures especially in environments where there are multiple applications and multiple teams - so the vast majority of them, then. Perhaps this is a good time to focus in on Jesse's advice to start small and choose one application area to focus on at the beginning. And DevOps is about culture right? So where are the cultural metrics then?
It's not impossible to measure cultural aspects - we do it as part of our DMI, but these sort of attributes are more nebulous, more based on human feedback that absolute statistics. They're also extremely difficult to put a number against in a business case. We know that happy employees are more productive and creative employees, but how does a percentage point improvement in happiness relate to a productivity improvement and how can we give that a hard dollar value?
Setting DevOps Goals
We can't but that shouldn't stop us striving for DevOps utopia and all the benefits that brings to an organisation. So we have an idea of what we're striving for, some metrics to baseline against and can build a fit-assessed, prioritised set of work streams to take us there, but how do we set goals? SMART goals are pretty well established these days - there are a few variations to the acronym, but they're pretty much all headed in the same direction:
S - specific, significant, stretching
M - measurable, meaningful, motivational
A - agreed upon, attainable, achievable, acceptable, action-oriented
R - realistic, relevant, reasonable, rewarding, results-oriented
T - time-based, time-bound, timely, tangible, trackable
So what might a DevOps SMART goal look like? Here are a couple of examples to consider:
"Our team will release updates to the core business application, Milton, once a day by the 1st September 2014. We currently perform releases once a fortnight but believe, using automation, this goal is attainable. Not only will it allow us to put revenue generating innovation to market faster, the process will be more consistent and reliable."
Or how about:
"We, the testing team, will reduce the volume of defects from 20 to 2 per week by the end of 2014 and through improved testing techniques reduce the average time to fix a defect from 4 hours to 30 minutes in the same timeframe, thus removing backlog and pushing software improvements to market at greater velocity."
Both look reasonable on the face of it, but with the second one, should it be the testing team who take responsbility for the reduction on defects? Won't they just hide them? They're not creating the defects after all. But you could have a goal for testers to reduce the time to fix a defect. Or could you? Isn't that the developers' job?
So we have a view of what we're aiming for, an idea on how to measure our progress towards it and are starting to identify some goals, but how can we reward success?
Social neuroscience tells us that there are five domains of motivation (See David Rock - 'The Brain at Work'):
S - Status
C - Certainty
A - Autonomy
R - Relatedness
F - Fairness
All of us have each of them in varying degrees; most of us will have one or two that are dominant. I'm primarily driven by Autonomy - the sense that the work I do has an outcome I can predict and see, and secondarily by Relatedness - the feeling that I am working with friends, not foes, that we all have the same goals and there is trust in the environment. And these are primary drivers - social neuroscience shows us that threats to the motivations that are important to us trigger threat responses similar to threats on our lives - and conversely, when we receive positive outcomes in these areas our reward system rewards us with a hit of dopamine and that feels nice.
This is useful in that it helps us gain an understanding of our own behaviours at work, but it also provides an opportunity to think a little bit harder about how to work better with the people around us if we can understand them better too. And then, when we're thinking about how to celebrate success with the goals we are setting on our path to DevOps utopia, can we be smarter about how we reward individuals by considering their primary motivating characteristics?
Rewards fall broadly into two categories: intrinsic/internal - the feelings we generate inside ourselves when something good happens, and extrinsic/external - when someone gives us something that makes us happy.
Here are some examples of intrinsic rewards:
- A sense of progress
- A sense of accomplishment
- A sense of meaningfulness/purpose
- Opportunity to shine
And some external:
- Gift card/vouchers
- Time off
- Flexible working hours
- Personal development
So, how do you match rewards to motivations?
Here's what we think works:
If you're status driven, you're likely to enjoy receiving a promotion or a job-title that shows your achievement or cash, awards, prizes or trips. If you're certainty driven you're more likely to be into qualifications, a longer contract or notice period, having a voice at a higher table or being given more long-term project ownership. If you're into autonomy you're likely to appreciate opportunities to leader, seeing your ideas acted upon and being given opportunities to showcase success. If relatedness is more your thing, then you'll more likely be happiest with opportunities of team based play (these bonding type activities trigger oxytocin - the attachment chemicals), or mentoring - either to mentor other people or to be assigned a mentor. And if fairness is your primary motivating driver, you may well enjoy being given the opportunity to give something back through voluntary work for example.
So there we have it - a vision, baseline and target metrics and a path to get there, goals along the way, an understanding of motivation and associated rewards - all we need to do now is get started, right?
Well, not quite. Daniel Pink, former advisor to Al Gore and author of Drive, has some words of caution. There's a TED Talk if you don't want to read the whole book but, essentially, what Dan's saying is that for simple, repetitive tasks extrinsic rewards can be very effective (we'll give you a 10% bonus today if you construct 100 of those things where you normally only manage 80) - they have the desired effect of creating focus and concentration on the task in hand. But when tasks are more complex and require more cognitive effort, extrinsic rewards can impair thinking, even send us in the wrong direction. He advises focusing on creating cultures which foster autonomy, mastery and purpose - exactly what DevOps aims to do. Here's Dan's flow chart on how to decide when a reward is appropriate:
So there's a fair amount to think about when you're planning your program of cultural change and you'll probably want to set expectations that you'll be tweaking your approach as you go along and see what works well and what isn't so effective. Be DevOpstastic.