Training others in the dark arts of DevOps Automation

If you are the Automation hero, why would you EVER share that stage? You are basically reducing your value to the organization by sharing your secrets. Right? Wrong! You are actually doing yourself a lot of harm, as I discussed in the the first blog post. How can you move on to other exciting challenges if you have to maintain your work of automation genius?

That is why the the IT Automation Curator’s job description has training as a core requirement:

  • Collect existing automation, and then Catalog it where others can find it (See Part 2)
  • Develop new automation based on requirements from IT (See Part 3)
  • Train others on how to use the automated processes
  • Maintain the existing automation

I had a great comment from jamesmarcus in the first blog post. Here is what he said:

“As a Director of IT I look to tools that promote easy automation, documentation, andbest practices. I try to design networks and setups with the “if I disappear” rule in mind. Meaning another sys admin of lesser knowledge should be able to look at my work and understand how why we did something in a certain way”.

I think this is a great perspective at the core of why I included training in my job description. Very few programmers, sysadmins, and other IT techies enjoy documenting their work. I don’t either – when it is after the fact. It is so mind-numbing to document your automation after you are already done and want to move on. So, that brings us to our first post.

Build your Automation to be well-documented and re-usuable

While performing amazing feats of scripting judo can impress your colleagues and get you kudos online, it is not a good long-term objective. One thing I learned early as a programmer is that creating incredibly efficient and elegant code seemed great, but it was really bad if even I couldn’t figure out what I had done a year later. That all comes down to great comments while you are writing the code. I know this may seem basic, but I have seen too many IT organizations with automation scripts, packages, etc. that no-one understands anymore. This is essentially a guarantee that the automation in question will be left alone to become outdated, brittle, and even “dangerous”. And if you are the only one that understands it, then it is your burden to bear.

So, basic to our train function of the IT Automation curator. How can you possible train people if your automation is over-complicated, un-documented, and impenetrable to mere mortals? Only with difficulty, and no one (especially you) will enjoy the experience. By documenting your automation very well as you write it, and building it to be as straightforward and simple as possible, you increase your chance of handing it off successfully. Writing well-documented and straight-forward automation has to be part of your process – bottom line.

Find automation disciples, and train them in the dark arts

While I see no reason why you can’t “teach” a class on automation as part of this role, I don’t think that is optimal, or even desirable for most people (stage fright anyone?). I have always envisioned a much more personal approach to automation training. Not every sysadmin, administrator, or IT techie extraordinaire will have an aptitude for, or interest in, designing automation. The right person has a somewhat rare combination of programming know-how, patience, troubleshooting skills, and IT systems knowledge. Obviously, everyone will use the automation, but only a few will write it.

The IT Automation Curator should be a mature, senior IT operator that has an eye for spotting talent. Like Mr. Miyagi in Karate Kid, you can watch for the young IT admin with lots of promise and fire in their belly, but unable to conquer the IT problems with their lousy karate skills. In all seriousness, I think mentoring promising candidates on automation best practices is more enjoyable and effective than the typical shotgun approach. The best part is that you can let the young upstart take care of the boring automation bits, while you save the best for yourself!

So, in summary:

  1. You can’t pass on automation that impenetrable to anyone but yourself
  2. One-on-one mentoring is a much more effective way to pass on your automation skills and knowledge

So, here is a parting challenge for all of you out there that actually remember Karate Kid. What might the IT Automation equivalent be of Mr. Myagi’s “catch a fly with chopsticks” trick?

Advertisements

5 thoughts on “Training others in the dark arts of DevOps Automation

  1. Pingback: IT Automation Curator – Good for techies, good for business, good for DevOps | Newtonian Nuggets

  2. Great post… No doubt that Devops must inherit Lean ideas which include systems thinking and optimizing the whole. However, one of the things that often gets missed by just Lean thinking (IMO) is to much focus on customer value and waste. I think Deming and Goldratt best summarize my thoughts about focusing only on customer value and waste respectively. Deming believed that all parties involved had to be satisfied (the worker, management, and the customer). Some have credited Deming for coining the phrase Win-Win. I am not sure of that but it is clearly the core of his philosophy. Deming believed that everyone in the equation had to have a win. Sometimes Lean practitioners tend to be too dogmatic in regards to the focus on “customer value”. Customer value at all cost and doesn’t take into account the other components of the system. You can talk about customer value all you want, but if you are not giving the worker value there will be no joy in mudville. Simon Sineck, in his awesome book “Start with Why”, says that the most important part of an organization’s life cycle is not the shareholders, not the customers, it’s the employees. Great employees create great customers who create happy stockholders.

    Goldratt has what I believe is a minor spin on Lean waste. Again, some Lean practitioners get dogmatic abut eliminating waste at all costs. In fact, it is my believe that Value Stream Mapping can sometimes promote this type of thinking. After a VSM it is very simple to identify the big pockets of waste and then wind up doing local optimizations that can possibly hurt the global flow. I would argue that Goldratt’s view would be to not to focus on waste but to focus on flow. In his book “The Goal” he illustrates clear examples of too much attention to efficiency and waste can lead to bottlenecks. Goldrtt is the inventor of Theory of Constraints which teaches us that not all waste/efficiencies are equal. In fact eliminating some wastes that look like they can have a huge positive impact can actually create a huge negative impact.

    Bottom line is that you have posted a great article and I am pretty sure Goldaratt would agree that without a clear cut view of the systems, local optimizations are better than nothing. In other words focusing on customer value and waste are a good start, but only a part of a bigger story for this thing we call Devops.

    Deming to Devops
    http://itrevolution.com/deming-to-devops-part-1/

    John Willis
    @botchagalupe

    • See my previous comment here.

      One additional thing I would say in this context. Maybe my vision of personal, more mentoring-style training is the way we really get the “line” employees on board. Instead of the “suits”/management pushing lean methodology down, senior engineers are much better placed to influence more junior administrators in a lasting way. They can establish a mentor relationship that will be much more effective. And in the end, the people doing the work are the best source for innovation around improving the process. We need to equip and enable them, and give them a system where their ideas can be heard.

  3. Fyi, There is a good book out there (not great) that shows an example of how LSS and TOC can either collide or work well together. It’s called “Velocity: Combining Lean, Six Sigma and the Theory of Constraints to Achieve Breakthrough Performance – A Business Novel” . It’s not a great book; however, it gives a fantastic example of how dogma can ruin both LSS and TOC.

  4. Pingback: Training others in the dark arts of DevOps Automation | Thoughts in DevOps | Scoop.it

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s