Growing Tech Talent: An Interview with AL’s DevOps Academy Trainer Steve Shilling

AL decided to take a ‘grow your own talent’ approach to sourcing top quality DevOps Engineers. To do this we partnered with one of the best trainers in the industry, created a unique syllabus and selected candidates from STEM backgrounds with the attitude and aptitude for DevOps. I got to catch up with him to see what it is that sets our Academy apart and grows some of the top talents in the industry with no prior experience. Here’s what he had to say.

How did you get into DevOps?

Well, I initially started out as a Mechanical engineer, but I’ve been doing it since 1982, though not commercially. Commercially I’ve been in IT since 1987.

It all started when the company I was working for as a mechanical engineer knew I could write software. So, the other engineers would tell me the algorithm and ask me to programme it. This meant I got sent on a CAD course, where I started learning Unix. So, I started working as an engineer after taking the course, the end of summer ‘87. That’s where it all began.

So, after that, I was looking after the companies data processing department, as the 2nd in command. Then as a sysadmin for Linux.

After that, sysadmin led into DevOps, software development and systems administration, creating large-scale infrastructure. The year 2000 was the first exposure to what is now known as modern day DevOps.

What do you consider to be DevOps best practice? Is there such a thing as best practice in an increasingly agile world?

There should always be best practice in an agile world. The reason being, you have to change so rapidly, if there isn’t best practice from the outset you’ll lose control very quickly and chaos will reign.

The most important practice that people still don’t always seem to adopt, but DevOps is adamant should be there, is the communication rule. DevOps is all about feedback to make sure everyone knows what’s happening. It ensures a smooth transition of the project.

As well as communication, there should be a lack of fear.

If you’re too frightened to break something in the first place, you shouldn’t do the job.

The ones that aren’t scared are the ones that will happily break it just to see why it broke and work out how they fix it. They’re the people you want in DevOps.

How was the Academy designed?

It started with discussions with Kris and Norm (our partners and co-founders) and Nick and Matt (two of our senior engineers). We all sat down together and discussed how AL operate and what their engineers were doing. I adapted my plan based on AL’s practices and the customers they were working with.

There are too many technologies to learn in 3 months, so we had to streamline and pick the best of the differences. For example, Ansible and Puppet, Ansible is one method of how we provision systems by doing a push method, Puppet is the same style but does a pull. Though they’re similar in the ground, they have different underlying aspects. We wanted to make sure the grads knew these different methods and how they worked.

The initial programme started with premise style DevOps moving into the cloud. This gave the grads the ability to pick up technology such as shell script, Linux, and core concepts of IT, but hands-on, rather than having to learn just the theory. This year we saw that premise is becoming less of a requirement. So, we modified the programme to adapt it to them starting in the cloud earlier.  We did away with on-premise and hardware. There’s already such a big change from last year, it just shows the programme is agile.

We obviously need to give the graduates a broad range of skills and technical abilities, but also they need to apply them to understand how they work. We use assessments and practical sessions to give context as to when and where they should be using these tools. As part of any assessment or exercise, they have to adopt agile processes such as sprint planning meetings. We encourage them to do daily standups every morning to cover what they’ve done, what they think they know, and what they’re still not sure on.

How does the Academy differ from other training?

1. The students have the consistency of the same trainer throughout. Although some of the senior engineers spend time with them, talking through their experience, they have one core trainer throughout.
2. They also have constant access to a number of senior DevOps engineers throughout the entire process, and they’re actually encouraged to use this support network to gain insight.
3. This might sound a little harsh, but it works: we set unrealistic tasks. The context behind that is that we want them to identify the MVP (minimum viable product). This in a way, is a skill in itself, being able to identify how much you can realistically deliver within the time-frame given. Especially in project teams, they need to be able to work out which task each person can do, and whether they would be able to meet the deadline for it.
4. We teach them what universities don’t. We teach them how to fail. More importantly, we teach them what to do when they fail. DevOps is what you can deliver in the time you have. Essentially they experience something harder than what we expect them to get in the real world, that way they’re prepared for the worst.

Running the AL Academy, you have worked with Grads from different academic backgrounds, from mechanical engineering to chemical engineering. What are the core skills that give someone the aptitude to become a DevOps engineer?

Engineering degrees always have an element of problem-solving capabilities. That’s one of the things you want to be able to do. To be able to ask yourself, can I see a problem and be able to come up with one or several potential solutions?

Those with the engineering backgrounds are able to see a problem in a different way and approach it from a different angle. They’re not restricted simply by the technology.

Which tools do you think are the most important when getting started with DevOps?

Any automation server like Jenkins, TeamCity or GoCD – an automation server is always good. Then you’ll need at least one scripting language, so Bash, Python, Ruby, and a bit of PHP. Perl is my favourite but no one really uses it anymore. Linux OS of course, will always be the tool to start with.

For somebody just getting into it and wanting to get ahead of the game, you would want one of the orchestration tools (provisioning systems) such as Ansible, Puppet, Chef etc.

What do you think are the most important non-technical skills to have is?

Being able to communicate. For DevOps that is definitely the most important.

Which methods have you found to be most effective when teaching?

My favourite method is to task the Academy grads to do things themselves. Start by giving them some context first, then a few ‘follow my lead’ demos so they get the idea of how to use it. Then, just drop them in it by giving them example assessments. They can start to investigate themselves and ask me questions as they go.

Nature or Nurture? Basically, does it take a certain type of person to excel at DevOps, or could anyone pick it up?

Anyone can do it, but at what level is a different story. Rather than a natural aptitude, it takes a genuine passion for what you’re going to do. You need to eat, sleep, breath the thing you want to be able to do. But yes, if you have the passion, you can learn. If the inklings not there, it’s not going to happen.

What do you think it takes to be a great DevOps engineer?

Passion, communication, and a really good understanding of how systems work. So, that could be Linux, Windows, network equipment or how systems communicate with each other. That’s the technical side, on the interpersonal side, it’s great communication.

‘’Basically be able to articulate what it is you’re trying to do and achieve, be a good listener, work out what your client is actually trying to tell you, and have good documentation skills, so you can move onto your next project without leaving your customer with issues’’

If you can’t document, you’ll be stuck doing the same job over and over, because no one will ever know what you’re doing.

At AL we pride ourselves on our values and on our mission to ensure automation is a force for positive change. How do you think organisations should be enabling young people to have the skills organisations will need in a digital world?

Try to attract grads early and invest in training. They’re the ones that have new and interesting methods and ideas to solve the problem. One of the things AL does is encourage our people to question the norm.

In DevOps, because it’s fast pace, people want things to happen, and they want to be able to change their mind. You’ve got to keep an open mind in this industry, and if you’re closed minded – DevOps is not for you.

Interested in joining our award-winning academy? Take a look here.