How I can be wrong about the death of sysadmin jobs

February 22, 2012

In my entry on the death of 'system administration' I included a parenthetical aside where I said that I expected this death to cost a bunch of people their currently well paid jobs. Since then I've gotten some pushback to this, such as Philip Hollenback's tweet:

#devops @allspaw observes that he is hiring *more* people as automation increases: link Discuss! (hey @thatcks)

So let me discuss how I can be completely wrong in what I said about the job loss.

My model of how automation would result in less sysadmin jobs is what I think of as the traditional model of how automation costs jobs: automation allows companies to do the same amount of work with less people and the people who are left are generally in positions that require different and higher skills than before. A bunch of robots replaces a room full of factory workers and leaves behind a couple of production engineers and a robot maintenance technician. This model implicitly assumes that either that the company doesn't have anything else more advanced and productive it wants those replaced workers to do or that they can't be up-skilled to do it.

On the surface we can make this match system administration. We assume that maintaining a company's IT infrastructure requires X man-hours today, that the company has the people for those man-hours, and that automation will replace much of those man-hours with automation-hours instead. The company could do some more with its infrastructure but probably not more (just like the factory could expand production but probably not a lot), and working on the automation mostly needs drastically different skills from the skills to do the non-automated IT work.

When I put it this way it's easy to see how this could be dead wrong. It's even a stereotype that typical sysadmin environments are swamped with work to the point where people are far too busy with day to day activity to step back and take on worthwhile larger-scale projects (to the point where I wrote about how this is a bad thing). These environments are not work-constrained the way the factory model is but are instead staff-constrained; automation means that they have more available staff time and means that they can do more.

(This happens in the factory model too but we pay much less attention to it, because it's considered a good thing; this is when better machinery increases the productivity of the factory workers.)

As for the skills of the job-losing sysadmins, well, that's clearly an assumption too; my model implicitly assumes both that their current skills aren't too useful in the new automated world and that they either can't upskill themselves given the opportunity or won't be given the opportunity by their employers (ie, the employer would prefer to fire the factory workers and hire some engineers instead of having factory workers turn themselves into engineers). Stated this way, I think that there are good reasons to be dubious about this. Depending on how fast the automation develops and what sort of automation it is, many current sysadmin skills may transfer without problems; to recast what I wrote in my entry about one downside of automation, if you already know how to configure Apache all you need to learn in the new automated world is something about Chef or Puppet.

(There are ways that this still can go off the rails, per WhatWillKillSysadmin. But even then you just need more skills.)

At a conservative minimum, this contrary viewpoint makes my initial gloom about future jobs somewhat pessimistic and overdone. In the optimistic view, system administration is now at the point in its development where the textile factory workers start getting things like electric sewing machines; our productivity is about to start really going up from having better tools and this will benefit everyone.

(I still think you should have a talk about this issue with any junior people you have. Whatever exactly comes to pass in the future, I don't think that system administration is going to go on unchanged. And I remain a strong believer in 'upskilling' into being able to program, for all sorts of reasons.)

PS: I continue to stand by my main argument that it will be a great thing when we stop having to install machines by hand, configure Apache yet again, and so on, because all of that will be reliably automated. As lots of people have said, that frees us up to do more productive and interesting work.

Sidebar: Answering 'what if everything moves to the cloud?'

One of the doom scenarios for sysadmins is companies moving all of their servers to the cloud and getting rid of most of the sysadmins that used to maintain them. However, for this to result in a reduction in sysadmin jobs instead of a transfer of jobs to cloud computing companies we need to assume that companies aren't now going to want to do more computing.

More precisely, we need to assume that the growth in extra demand for (cloud) computing is less than the efficiency gain (and thus the staff reduction) that the cloud computing vendor gains from running at large scale. (We already know that running at large scale can be done more efficiently than at a small scale; there are lots of examples of scaling up computing significantly without scaling up sysadmin staff as much.)

(There's an additional assumption embedded in the cloud gloom scenario too, but I'll let my readers find it and argue over it.)

Written on 22 February 2012.
« Using and understanding Python metaclasses (an index)
Blogs and the problem of indexes »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Feb 22 23:30:01 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.