At the Enterprise DevOps Summit last week, there was a great deal of conversation around finding the right kind of skills, and taking different approaches to getting work done. Forrester VP and Director serving Infrastructure and Ops professionals had a slide that was rather blunt and received a great deal of attention once tweeted out.
— Eric Minick (@EricMinick) October 22, 2014
Clearly a nerve was struck. Listening to the crew at Hangops discuss this, it was clear that the tweet lacked some of the subtlety that Glenn discussed. So let me first try to describe what I heard*. Glenn addressed the fear than many have that they’ll automate themselves out of a job. While some jobs may diminish with DevOps, others will emerge. If you automate yourself out of a job, you will also likely position yourself very well for the next job, often with the same company. Companies that routinely lay off people who deliver huge efficiency gains tend not to prosper. At the same time, those job titles on the left need to prepare for significant change.
My understanding is that while knowing how to tune a thing is still going to be a key skill, it’s going to be equally important to know how to express that tuning in a way that is versionable, and can be applied to dozens, hundreds or thousands of similar systems.
“Dying” is too strong
I meet people all the time who do jobs that a slide like this would have flagged as “dying” ten or twenty years ago. As the Hangops guys pointed out, mainframe development was supposedly dying long ago, but you probably get better paid to be a Cobol developer than a .Net or Java developer. At the same time, there is probably more new code being cranked out in either of those languages than Cobol.
I don’t expect mass layoffs
I’m sure there will be shops that have hired a Sysadmin for every handful of servers who put in place something more scalable and lay off a bunch of admins. Some executive will get a bonus. What I hear though is usually a different story. A team will start to have way more servers than they could manage the old way, probably “because cloud” and learn to automate. Or modern development methods like Agile or Kanban will cause a rate of change that’s intolerable with existing methods. Either way, the volume of stuff we are asking our admins to manage is often growing extremely quickly, and they are forced to look to DevOps techniques just to keep up. The biggest risk is that the admins fight these changes as unreasonable, a rogue group starts taking over bits of their work within the subset of applications that are undergoing the cloud or agile transformations and eventually takes over.
DevOps has been driven partly by Agile speeding up development enough to break operations. Looking at what happened to jobs closer to developers a few years ago should shed some light on what lies in store.
The SCM Team
Ten years ago when I talked to someone who worked on the “Software Configuration Management Team” they usually focused on the care and feeding of the source control system. They helped devs with big merges, crafted config specs, and helped with the nasty build processes. As Agile took over, the trend was towards simpler and lower maintaince source control tools, frequent small merges, and continuous integration tools that ran the builds. Most SCM teams eventually took over the build systems driving rapid feedback to developers, and making sure that a builds were done in a traceable way. Some continued towards continuous delivery and are probably rebranding their team the DevOps Team now.
Lots of Gantt loving project managers got lost in the swing to Agile, especially in those shops that shifted away from projects and towards a product view of their applications. At the same time, organized, responsible people who understand the business reasonably well are generally in demand. So we saw a range of conversions. Some retrained and became Scrum masters. Others took roles as business advocates within IT. Others shifted towards release management as that discipline emerged.
See a lot of people following a written test script by hand and recording the results? That kind of tester probably represents the worst case scenario for the “administrators” that Glenn identified as at risk. The low value that many shops put on quality is partly to blame. Those with engineering skill have often found a home writing a lot of test automation, or others are focused more creative exploratory testing.
General rule: work gets more interesting
Jobs that are in danger of being automated are usually the ones that require the least humanity. Machines can follow a script well. People problem solve and use creative judgement. To the degree that you are problem solving something other than remediating errors in a manual process your job is probably secure. Otherwise, it is probably time to begin automating yourself out of your job. Testers provide the map of the road forward. Those who are just skilled at diligently following a script are at the greatest risk. If you don’t automate yourself out of a job, someone else will. The people who build the automation of the future are probably going to stick around expanding that automation, optimizing it, and caring for it. That’s more fun than following someone else’s poorly written instructions anyway.
Ironically, automating yourself out of a job is probably the best thing you can do for your job security.
* Correction: I’m pretty sure Glenn said “watch out” not “you’re in trouble”.