Category : Uncategorized
Automation in IT is great! It removes boring tasks, gets managers off your back and lowers the FTE required for complete departments. But the widespread use of Automation, Desired State Configuration and Infrastructure As Code in IT has led to a foreseen but untackled side effect:
The step up from a junior position is getting bigger and bigger.
Here’s how this works.
Imagine a junior sys admin, Edd, starting out in a new position. What are the kinds of tasks that he gets entrusted with? Creating new users, doing password resets and sorting out which tickets should be sent back to the service desk (or fixing it himself since that’s less of a hassle) and which should go on to the senior sys admins.
After the first few weeks, Edd gets his hands on a request for change for some new server VM and gets his first chance at writing up a plan, getting it reviewed and installing and configuring the actual VM. After a year or two, Edd has seen and done enough in the environment to be left in control of the day-to-day IT operation.
While Edd is running the operation, the seniors have started automating. They decided to use Powershell, Azure Resource manager, Desired State Configuration and Azure functions to automate most IT tasks, ranging from password resets by the end user up to spinning up new, fully configured VM’s. Now all the things he used to do at the service desk and most of his current daily work is automated (this is of course an ideal hypothetical situation), leaving him with routing the tickets from the first line service desk to the senior sys admins. Anything that can’t be handled by the service desk is either automated or too complex for Edd to handle on his own.
Luckily for Edd, the seniors involve him in the automation process and the few incidents that still pop up in the IT operation, but HR will have to find a cost-efficient way to get the next sys admin up and running without having to hire a senior right off the bat.
So what are the options?
At first glance, the most logical option
would be to train juniors on the job, but this is getting less and less
feasible as there is little work left for juniors. Instead,
training needs to be done intensively, via longer courses provided by the employer or an external company. The former would require company trainers, but could end up more tailored to the company’s specific characteristics. In contrast, the latter could be either cheap and generic or expensive and tailored.
The challenge is that you need some form of actual experience with a system before you can automate it. For stand-alone automated systems like an AD with Exchange or VM creation, setting up a course with enough hands-on experience is very doable. But with complete Identity Management automation, automated monthly billing reports or any product that incorporates multiple systems, it’s the intricacies that make the 3 or 5-day courses that we typically see in the IT world almost impossible.
The alternative, to only hire seniors, would probably be too expensive and would diminish the recruiting pond over the years. In the end, training your juniors while under contract, though challenging in various ways, still seems like the best option.
Train your juniors to know your products and to quickly and correctly figure out how these products should connect. Give them test environments to create things manually and break things while trying to automate it. Give them a tutor and time-managed (!) play time. And most importantly, involve them in breakages and incidents arising from integrations between systems. Yes, your seniors can do it faster, but invest in your Edds so that they can become your future seniors.