From DEVOPS to devops

CC Original from Matt Moor modified by me.

When I discuss devops with people, whether at an event or online, inevitably, the topic of measurement comes up. That’s not just because measurement is a pillar of devops, but because people want to know, “Am I good at devops?” That’s a valid question. The follow-up question is, “How do you write down the word ‘devops’? Do you capitalize the D and O, or just the D, or all of it?” In fact, the way you capitalize “devops” is a measurement of how well you’re doing.

You start with DEVOPS. I write in capitals to start with because it looks completely bonkers, just like devops is when you’re doing it wrong. It looks like something that came on a DOS formatted floppy disk, and allows you to ask “Why are you yelling DEVOPS at me?” So, we start with the fully uppercase word. Review the following criteria, and consider how your organization measures up. For each item you think you’re above the bar on, convert the letter to lowercase. It’s that simple!


Don’t start with a rename. Your devops initiative shouldn’t begin with a rebranding of a department or team. If you all you do is rename your operations team to the devops team, all you’ve really done is agree to pay more for the role. In my experience, offering a named devops role means you’re willing to pay more than a traditional technical operations role. This also signals to people what they used to do isn’t cool any more. I really don’t want to have teams/roles named devops at all, but that’s enough of a hot- button to fill a whole post. So, if you didn’t rename an existing team as the kickstart to your devops initiative, you’ve passed this checkpoint.

Evolve your thinking. Your practice isn’t simply about automation. It’s about aligning to the business requirements, or at least the requirements of your customers. Customers could be end-consumers, or other teams in your organization, depending on the size of your firm. Regardless of the setup, the more you understand things beyond your immediate team interfaces, the more you can direct your efforts toward value rather than simply technology. To me, this means you should probably care about the business your company is in. If you don’t, it’s difficult to drive alignment with any conviction. (Ask me how I know.) Are you expanding your team’s sphere of influence by learning about your direct customer’s customers? If so, carry on.

Variable reduction. Simpler equations are easier to balance. This is true in math. It’s true in process flow, as in, remove “if” statements and things are easier. It’s true with technology. If you support five operating systems and versions for servers, stop. Have a goal of one. If you have four database platforms, stop. Reduce. While reduction of technology stacks is not simple in and of itself, it pays off in velocity and understanding in the end. You can even apply classic 6Sigma methodology here. Reduce the type of defects (problems) you’re experiencing, then raise the quality level. If you’re comfortable with the number of items, configurations, and services you’re supporting, you may pass this gate.

Obliterate silos. One of the things that really drew me to devops was the holistic approach to getting things done. Gone are the days where a team of four manages DNS and DHCP, and that’s it. Gone are the days of load balancer specialists, database trolls in cubicle caves, and the server administrator who never leaves the comfort of white noise (from AC units running in the dead of winter) behind a badge-to-enter door. To keep things moving today, you need to be able to own a stack. Be a generalist. Automate common cases, and eliminate uncommon cases. If there are many handoffs from team to team to deploy a service, reevaluate. Could that be pulled into one team? Why is a second, third or fourth team involved? Is it because of control, or the unwillingness to give up control? Fewer silos means fewer handoffs. Plus, the practitioner gets to learn new things all the time. I find that very fulfilling. Are you working to reduce context switches, tickets over the wall, and not being able to take care of the work yourself? If so, great. Move along.

Prevent the hero. If somebody is rewarded for working 24 straight hours to solve a problem once, maybe that’s okay. If it keeps happening, heroes might be the norm rather than the exception. First off, look at incentives. A culture that rewards firefighting breeds arsonists. Secondly, look into why you always need those heroes. Is the person in that role unwilling or unable to educate others on the team about what they know? What happens if they want a vacation, or find another role? A good culture is a team sport. It’s not about a few individuals being great and crushing it. It’s about a team that supports each other, solves problems together, and actively works to make each person on the team better. Many of the the best engineers I’ve known have made themselves totally replaceable. If you’re not depending on people wearing tights and a cape, that’s a good thing.

Share the pain. When I get asked on how to measure devops success, I almost always respond with something along the lines of, “Do the people making bad decisions have to live with them?” If you write bad code, that shouldn’t be operations’ problem. That should be your problem. If you can’t scale a database cluster, that should also be the problem of the application team that needs that type of scale. The application team will need folks with that type of expertise in the fold. Realistically, people who have to carry the pager tend to make better decisions. This is about aligning incentives to do the best work. You need to bug (page) the people who are authoritative and capable of making the changes to improve. If pain is a shared resource among those who develop, deploy, and monitor, I think you’ve got this.

Conclusion

You’ve run through the fun above. How does your org look? DEvoPs? devoPS? DEVOps? If my math is correct, there are 64 possible values for this measurement. You’ve reached peak devops when you’re fully lowercase, like the e e cummings of devops.

And that’s it! One you’re fully lowercase, you can ascend to thought lordship and collect those fat keynote paychecks.


In all seriousness, thanks to Nigel Kersten for providing the spark for this idea a few years ago. If you’re looking into measurements of devops, have a look at devopschecklist.com.