Teaching DevOps: Cheaply, effectively, fairly.

John Contad
Apr 25, 2019 · 8 min read

Over the next couple of minutes, I’m going to talk about some of the ways that we teach DevOps to graduates — in a way that’s cheap, effective, and fair. But also, fun. And while this is focused on graduates, I hope that this also somehow applies to onboarding new team members (and maybe even your own goal setting exercises).

Bit of background: Like many other companies, my current company offers a graduate program that allows for “rotations” — to join teams for a finite amount of time. This gives the graduates opportunities to get discipline-specific knowledge (Mobile Dev from a mobile team, Backendy bits from a Backendy team…), and find things that they really care about.

My crew provides a DevOps-focused rotation — a rotation that’s now the highest-rated within the org.

Unfortunately, they’ve inherited my terrible taste in fashion. Oh well.

Journey Outcomes, and Breaking It Down.

If teaching is a process, then it’s probably important to be clear about what outcomes we want. It’s a good idea to ask your graduates if they want to learn anything specific, but remember: people who don’t know a lot within a discipline won’t know a lot of what they should know. Don’t be afraid to be prescriptive.

We decided that a graduate leaving the crew after 3 months of rotating in doesn’t necessarily need to be an encyclopaedia of operational knowledge — that would be absurd. However, we can support them so that they are able to solve problems for modern systems. Put in a simple, practical statement, the first iteration was:

Grad must be able to deploy production-grade software to K8S or AWS infrastructure, and make CI/CD pipelines.

Mind that that statement doesn’t need to be 100% correct, you just have to start somewhere. Because after deciding on the outcome, you can cut it up quickly:

Yep, it’s a story map. Each of the columns is a capability that the graduate must have, followed by a sequence of bits that they’d need to know to be able to do that. Additionally, we need to be able to make them understand the whysWhy should you care about availability? Why is security and observability important?

It’s important that we sequence the information bits, because technical knowledge domains have dependencies. For example, being able to understand AWS VPCs means that you at least need to understand how networks work at a basic level. It breaks down like this:

(Again, it doesn’t have to be 100% correct. Just Good Enough is fine.)

On Acceptance Criteria.

So we took 12 cards and wrote them out like this:

The cards are to be “cashed-in” with crew members until they understand the subject. Each of them refer to a specific topic that the graduate must “get”.

But how do we know if they “get” it? Well, we wrote the success criteria in the back:

In Instructional Design, “knowledge checks” are an incredibly important part of constructing teaching material. These are sections of your journey where you’re verifying if the recipient of the knowledge has retained the information you’re transferring. It’s the quiz at the end of your book chapter, or that scary bit at the end of the lesson where the teacher asks you questions.

Knowledge checks also rely on what your learning outcomes are. By learning outcomes, I’m referring to the decision that you’re making on what the graduate should be able to do at the end of their card. We didn’t want them to just be able to repeat information we provided — it was important that they comprehended the material and were able to apply that knowledge.

And to help us make that decision, we leaned on Bloom’s Taxonomy of Learning:

Credits: Darlo Higher Education

It’s probably worth noting that we were not prescriptive at all in how the graduate is to acquire the knowledge necessary to execute on the knowledge checks. Everybody has a learning style, and it’s important that we respect what works best for people. Some people like to be alone and put headphones on, and some like pairing. That’s okay.

But that also makes knowledge checks more critical — as it sets a “boundary” on what is enough information. From a rotation perspective, we didn’t really care for graduates knowing about sticky bits or ulimit — so having an “end state” prevents them from going on the deep end.

Checkpoints and Bossfights.

Initially, we implemented checkpoints mainly as a way to encourage our graduates to relate those individual domains to each other. Now that they knew what “productionize” meant and how to create pipelines for different use cases, how would they deal with a non-synthetic (“real-life”) version of the problem?

What we found later on was that this was the most “fun” part of the rotation. They’ve spent time in the training chamber, and now it was time to show off.

One card in particular (“Improve a team”) meant going to a team who wants to uplift their infrastructure, and having 10 days to create better infrastructure and pipelines for them. All interactions, kickoffs, tech decisions, and sessions were to be led by the graduates. They had to interface with teams and get signoff on changes that could affect production.

(They weren’t alone of course. We had team members acting as “parachutes” — but we’ve rarely had to intervene, only spectate.)

This was also important, as this gave them the skills and confidence to handle the “people” bits of software development. A mantra that we hold dear and constantly remind graduates is this: software development is 5% code, and 95% being able to work with other people well.

Whiteboards Will Never Lie.

A recurring validation loop we have is “Whiteboard this!” — where the graduates explain as much as they can using a whiteboard or a piece of paper. This works incredibly well, as it provides visual feedback on how much a graduate understands, as well as the parts where additional study might be warranted.

For starters, we start each rotation with a “baseline” whiteboard — asking them what they think happens when somebody clicks on a website hosted in AWS:

As they take on more and more cards, we repeat the exercise — knowing that they can provide a little bit more information. Over time, we show the graduates the deltas between each iteration. This provides them with a real, verifiable sense of growth, and some degree of autonomy in deciding which part they should fill in.

It’s also worth noting that a big version of this exercise is part of the exit interview for the rotation. This is where they get to prove out everything that they’ve retained — but more importantly, show the mental associations they have between those bits of knowledge.

From your desktop to the pod: what happens?

Here’s another one:

Here’s another one.

We also use this methodology in some of the Code Like A Girl DevOps classes. It may not seem like much: but mental models are significantly more important than being able to repeat command incantations.

Code Like A Girl for Docker Basics. They were able to draw this with a couple of hours of workshops.

Teaching More Than Just DevOps.

The big spoiler here is that the things that are not on the cards are the most important things that I want them to take away from our rotation. And they’re really not about DevOps.

At the end of a rotation, they should be able to:

A.) Write their own cards. I want them to be able to look at any domain in the eye, and set their own goals. Write their own milestones. Be able to define “how much is good enough”. Be able to have the self-awareness to seek out subject matter experts and ask for help.

B.) Work well with other people. I hope that at the end of their journey, they would have absorbed some bits about managing expectations, owning your commitments, and being honest about what you can and cannot do. About how sometimes, the people that you work with have different opinions, and how they’ll have to navigate that.

I love software development. But there’s a significant part of this discipline that’s not related to technical aptitude, or the ability to rattle off how much you can remember off some small, arcane thing. The weird peopley bits that have to do with asking the right questions, making things better, and thinking outside your own domain of what is “correct”.

Those are harder to write acceptance criteria for. I can only hope that we’re at least mildly pulling it off.

After all, as W.E.B. Debois says: “Education must not simply teach work — it must teach life.”

Follow us on Twitter 🐦 and Facebook 👥 and join our Facebook Group 💬.

To join our community Slack 🗣️ and read our weekly Faun topics 🗞️, click here⬇

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇

Faun

The Must-Read Publication for Aspiring Developers & DevOps Enthusiasts. Medium’s largest DevOps publication.

John Contad

Written by

DevOps. Stories. Guitars. Motorcycles. Melbourne.

Faun

Faun

The Must-Read Publication for Aspiring Developers & DevOps Enthusiasts. Medium’s largest DevOps publication.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade