DevOps team of One

DevOps culture is much talked about. There are a many who believe that an organization must embrace DevOps from the top down in order to reap benefits. While I believe that this would be ideal, it's also a bit all or nothing. The genesis of DevOps adoption in The Phoenix Project is dramatic. The book is a novel after all, but it is my hope that this isn't the only path for people to embrace DevOps.

I believe that there are many opportunities for individuals or teams within an organization to begin reaping the benefits of DevOps without a mandate or even the support of managers. Taking advantage of the opportunities may not have the same dramatic effect as in the book, but any progress is a positive thing. This holds true if it only improves small things for small groups.

So, what can individual contributors do to embrace DevOps?

Start small. There is no need to print up handouts and offer proclamations of the virtuous path DevOps offers. Find something small to improve and involve others. For example I used to work in Academia. Part of my job was handle large print jobs for various University departments. Most of the time we had a student deal with a couple of old line printers (yeah, the ribbon feed green bar type). One of my staff would handle it if the student wasn't available. Sometimes it fell through to me. I hated that part of the job. The printers were troublesome and dealing with the ancient VAX VMS box that did the printing was also a pain. It was also a big expense, since there weren't many of those printers around and support for them cost a large amount of money. After a particularly grueling day in the machine room where I saw the fruits of my labor go into the recycling bin (after the 2 important pages of a 300+ page report were extracted) I decided to fix this. I talked to the customers of the print jobs and my superiors. After a handful of meetings over the course of a week I had buy in to try something new. By the time it was all said and done we had a couple of modern laser printers kicking out the jobs more reliably and much faster. We also replaced the old print spooler with something that didn't require Ops experience from over a decade ago. The new system allowed customers to check on the status of their print job before making the treck to pick them up. We even replaced some of the print outs with an email and massive semester printouts with a CD. It wasn't a huge project, but had some significant benefits. Not least of which is that our customers very much appreciated it and started thinking of our group as a resource. It was a clear win and didn't require a DevOps mandate.

So, how do you go about it:

  1. adopt the Toyota Kata for yourself
  2. build relationships across operational boundaries
  3. identify opportunities for Kaizen or continuous improvement and take action

Start with small things. There are likely frequent manual tasks that you or others do that offer a great place to start. Perhaps some recovery steps to make failures less painful or something to make provisioning more self-service and immediate?

It's really just about finding a problem and making it less of a problem. Often times as an individual (it's true for me) it's about reducing or eliminating a personal pain point. If others can be involved in the process it's even better. Odds are there are others who are suffering from the same pain point.

Sure, the ultimate goal of greater automation, continuous integration and deployment etc can seem a long way off. That doesn't mean that small steps aren't helpful and after all a journey of a thousand miles begins with a single step.

There is no perfect time to start down the path of DevOps, but there is "now". Is there a better time to begin leading by example and make things better for yourself, the team, and the organization?

\@matthias