From DEVOPS to devops


For evangelists, DevOps is a culture and a transformation. For some engineers, DevOps is a set of agile tools and techniques. For managers, DevOps is a probably a methodology. For other people it is just a buzzword and for recruiters, DevOps is a job.

I think DevOps is not just a buzzword but somehow it is a mix of all the above definitions: There is no digital transformation without the right methodologies, the right tools and the right engineers.

When I discuss devops with people, the topic of measurement inevitably 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 organisation 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 organisation, 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. (duh) 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? ping? email? nag? stalk?) 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.

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, you reached the nirvana of devops. And that’s it! One you’re fully lowercase, you can ascend to thought lordship (silly, I know) and collect those fat keynote paychecks.


Trackback specific URI for this entry


Display comments as Linear | Threaded

No comments

Add Comment

Submitted comments will be subject to moderation before being displayed.

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.

Gravatar, Twitter, Pavatar, Identica author images supported.
Markdown format allowed