Allen Teaches Kubernetes

Lessons Learned from Teaching Professionals about DevOps in New Zealand

Last year I had the opportunity to join Assurity Consulting in Wellington, New Zealand. I joined as a DevOps consultant and figured I would be responsible for DevOps related projects – setting up build pipelines, automated testing strategies, continuous delivery pipelines… Within my first week, I was asked if I’d like to help create some course material for a training course. 

At the time, I had no business saying yes to this request. I simply didn’t have the knowledge or the experience to create learning experiences for adults. My colleagues, however, were extremely knowledgeable and with a lot of hard work from our team we created an IC-Agile certified course – The Foundations of DevOps. 

Assurity really takes its education seriously. Assurity arranged for me to attend Sharon Bowman’s Training from the Back of the Room, Baz Caitcheon’s Smartphone Video Production, Luke Hohmann’s Game Design Workshop, and a Visual Facilitation workshop.  These four trainings have proven to be immensely valuable as we have created and refined the course content over the last year.

The first year of Foundations of DevOps has come to a close. In our first year, we have certified over 100 folks in the Foundations of DevOps and have delivered the course over 10 times. By any measure, that is an amazing success for the team. 

Peter-John Discusses DevOps
Peter-John Discusses DevOps

Our first year was not without its struggles. We tragically lost one of the course creators Peter-John Lightfoot, and that loss was felt deeply by all of the Assurity family.  Peter-John was deeply involved in the creation of the course content and exercises – so his loss was particularly challenging for the team.

The Assurity team is an amazing group of talented folks.  We currently have 5 trainers certified to deliver The Foundations of DevOps and I think its important for me to say:

Michael Harrod, Mrinal Mukherjee, Kay Johnson, Peter-John Lightfoot, and Nigel Charman – your hard work, creativity, dedication to excellence, and genuine interest in DevOps has made working with you during this last year an amazing experience.  Thank you!

With that, I would like to share the 10 lessons I have learned this year from delivering this course to professionals in New Zealand.

Lesson 1: Teaching ain’t easy

I have been incredibly blessed by all measures. No measure illustrates how blessed I have been more than the quality of the teachers I have had in my life. 

My parents were outstanding teachers. I remember my father trying to teach me trigonometry at age 8. He attempted to argue to a judge that there was no way that an officer could have reliably clocked him speeding from that distance. “A mere half degree of movement on the hand-held gun would equate to a wild 64 foot swing of the centre of the radar beam!” he proclaimed!  My dad is an intense, passionate person – and so, like all fathers, when he sees a great teaching moment he takes full advantage. 

My Dad’s Version of Basic 8-Year Old Curriculum

My mother, on the other hand, taught me more practical skills. One of her primary lessons of life, “Remember the number one management rule: listen.” She’s a big fan of patience and listening. She also taught me how to fish. That’s about the most useful thing I somewhat know how to do to be honest.

In school, I was fortunate enough to have incredibly dedicated and talented teachers in the Azle Public School system.  After that, I spent four years at Rice University learning from some of the most gifted minds in the world. People that put cameras on Mars, built nano-materials that can cure cancer, world-renowned bioethicists, and builders of biological processors that push the envelope of Moore’s law.

By all measures, I’ve had an amazing run for teachers in my life. I never really appreciated how lucky I was until I stood in front of a class and was expected to teach them something for nearly 16 hours.  Keeping material interesting, parsable, useful, understandable is an insanely hard thing to do. To stand in front of folks you have never met – and try to keep a coherent narrative for 16 hours is immensely difficult. 

If anything, teaching this course over the last year has given me an immense appreciation for anyone who attempts to teach a group of folks something they don’t know. School teachers, college professors, parents, peers – anyone who takes the responsibility of another’s journey of learning has an immense amount of respect in my eyes.  

Lesson 2: Designing Education for Adults is Fun

I have learned quite a bit about how adults learn best. Getting folks to sit and listen to you as you drone through 16 hours of slide after slide is probably the best way ever invented to fail to teach anyone a single thing.  Hours of lecture to adults simply doesn’t work. In fact, anything more than 15 minutes of lecture doesn’t work. 

Long Lectures go straight to work inducing the “itis”.

At the root of this is the Reticular Formation that sits at the base of the brain. The minute there is a lull, the RAS kicks in and tunes you out and puts you to sleep. If the body and mind don’t have to be engaged and waste the energy, then, much like the energy saving features on your laptop, your brain puts you in sleep mode.  You can’t teach folks effectively by talking at them for hours. 

Sara Bowman’s Training from the Back of the Room has been extremely valuable in helping me see how training for adults fails and how it can be improved. Activities that create learning experiences are the most effective way for adults to learn. I can sit at the front of the room and present 3 different ways folks define DevOps, or I can lead them on a journey through the training room discovering what these definitions are and help connect those definitions to their experience. I can then allow them to create their own models for DevOps such that they can personalise the learning. Activities like this have created some extremely insightful responses from attendees, such as the Ouroboros of Value!

The Ouroboros of Value – Continuous Measurement, Improvement, Feedback and Value

Lesson 3: “This maybe a stupid question” is always followed with great questions

DevOps spans a lot of material from software development and IT infrastructure operations. The knowledge-space for the field is extremely broad and jargon intense. As a result, when folks are exposed to the breadth of it in a 16 hour course – they are unsure if their uncertainty would be considered stupid or not. With that weariness in mind, and hopefully the feeling of a safe space where they can ask questions, they raise their hand and start “This maybe a stupid question… “

Thou Shall Pass!

Every single time, the question that follows that phrase, is extremely insightful. It typically illustrates the person is applying exactly what I said to even broader problems, and attempting to fully synthesise their understanding of the topic discussed. Every time I hear the phrase now, I have come to expect very very good and insightful questions. 

Lesson 4: DevOps must be taught in a targeted fashion

DevOps is an extremely broad field. Depending on who you ask it includes everything from how developers check code into version control systems, to folks trying to stand up a highly adaptive and secure container networking architectures on Kubernetes. People who wish to learn “the DevOps” typically are either in development and deployment of application code, or in the operation and maintenance of infrastructure.  They come from the Dev side of things or the Ops side of things. 

You can’t walk into a room of operations and infrastructure professionals and tell the story of DevOps completely from the continuous integration and delivery of application code. They will tell you that they don’t build application code – and wonder how it applies. You have to help connect the DevOps practises to the activities people are currently involved in. Likewise, if you go into a room of sales people and testers and do a deep dive into defining infrastructure as code so that you can do zero-downtime deployments, they will likely struggle to internalise the learnings in their day to day. 

With the Foundations of DevOps we quickly discovered that how we told the story of DevOps really had to be tailored to the audience in the room. We developed a training needs analysis questionnaire that we provide to attendees before they get into the training room so that we can tailor the learning experience to what they currently do. Our Training Needs Analysis has been immensely valuable in helping us ensure that folks get the best training experience possible.

Over time we have developed a variety of modules for the course that apply depending on who is in the room. For teams that are actively involved in operating production services, we might add in a deep dive on Site Reliability Engineering and automating the delivery of infrastructure changes at scale, and spend less time on the mechanics of small batch sizes on development streams.  It really depends on where folks are in their journey.

Lesson 5: New Zealand Professionals are Really Really Really Smart

The New Zealand course attendees have been a real joy in the training room. I have a very loud Texan voice, and I often get quite a bit of slack for being distracting in the office when I am training.  But the volume of my voice is direct measure of how excited I get when the professionals in the training room are really engaging with the material and learning. I can’t help it – I get loud when people are engaging with the nerdy DevOps things I talk about in the training room. New Zealand has people that really like to talk about DevOps.

Kiwi’s find the volume that I am capable of to be quite distracting – especially when folks want to talk DevOps!

That being said, it’s also been a joy to surprise Kiwi’s with a “ya’ll” every now and then. Theres been quite a bit of discussion as of late about the phrase “You guys” being a micro-agression – a bit sexist and offensive. I tend to agree, and in Texas we have solved that problem with the much more inclusive and gender neutral – “Ya’ll”.  I try to spread the gospel of the “Ya’ll” as much as I can. 

Lesson 6: Slides are a great way to fail to engage with learners

F(r)ODO Baggins of the Shire doesn’t like PowerPoint Slides

When we first built the Foundations of DevOps (FODO) we built out quite a lengthy slide deck. 16 hours of material is quite a bit of material to cover so the slide deck functions as a fail safe – should I forget to cover something the slide deck will save me!

The slide deck has yet to make anything I have presented better. The slide deck is an all too familiar crutch. I have found after observing myself deliver training material from slides – that the slides are simply too easy to read from. I easily slip into reading the bullet points to people. I realise I am doing it, but I become powerless to stop it. I can only imagine the annoyance folks have when I read basic bullet points to them like a child.

To get away from this familiar pattern I have mostly done away with slides in my delivery of the course material. I took a lesson from my college professors – who almost universally never had slides – and began delivering from the white board. It takes some practise – but folks are much more engaged when I don’t read to them.

Lesson 7: Market forces have made DevOps intimidating

The immensity of the DevOps tools space has really made the field intimidating. Facilitating this class has made me more cognisant of exactly how intimidating it can be to folks. DevOps Engineer job descriptions usually have a slew of technical jargon and specific tools listed as requirements for the position. The IT industry really needs to break this habit. The complexity of this tool space, and familiarity with any subset of it, doesn’t necessarily make a good engineer. Every time we put out a job description that says “must be familiar with Chef, Jenkins, and Azure” we unnecessarily segment the talent pool into ever smaller and unreasonable partitions of micro-expertise.  

We need to make our job descriptions much more general. Where as “Chef, Jenkins, and Azure” are great at specifying tools that you use, a better job description for that position – that is more inclusive of folks and has less intimidating “tool-speak” would be something like “Configuration Management, Continuous Integration, and Public Clouds” While these topics are much more general (and arguably more intimidating), they don’t serve to unnecessarily fragment folks into tool buckets.

Lesson 8: The Future Is Probably Kubernetes

A lot of the course material talks about really cool techniques and practises that you either need the right platform for, or you need to develop very careful delivery pipelines to perform. Things like chaos engineering, blue-green and canary deployments, dark launches, feature toggles, A/B testing, high availability failover and resiliency, micro-service architectures, containerisation, elastic, scalable infrastructure… 

Every single one of them are made easier with the selection of Kubernetes as your platform. Kubernetes has a bit of a learning curve, but should you spend the time learning Kubernetes, you will unlock the ability to perform advanced deployment, testing, and operational techniques that previously were done with expensive or limited PaaS solutions. Kubernetes handles a lot of the fancy work around operating scalable distributed applications. I am seeing tons of new development being undertaken with Kubernetes as the main platform. 

We have reached peak Kubernetes.

In addition to that, Ice Cube just performed at Kubecon. That is as good a sign as any that Kubernetes is likely going to be the enterprise platform do jour for the coming decade. 

Lesson 9: Imposter Syndrome is caused by a lack of empathy from experts

Being in front of a class room talking about very technical things to folks of mixed experience has made me very observant of when folks are feeling out of their depth with the content. The industry likes to talk quite a bit about imposter syndrome – the feeling of being an imposter or fraud around their peers – especially when the topic of discussion gets out of their experience.

I identify with imposter syndrome, and routinely feel victim to it – especially when I get around a whole bunch of Terraform geeks who know more about the tool than I do.  Being a course facilitator, I am on the other side of this coin. I am the one spouting geek jargon with an intense, boisterous amount of confidence – I have to be extremely careful to observe the folks in the room and ensure that I’m not making it easy for them to feel like an imposter. I have to empathise, and see myself in their place – if I was listening to me would I feel like an imposter?  Am I presenting the material in a way that doesn’t allow folks to speak up if they are uncertain? Folks who exhibit empathy, can prevent imposter syndrome.

Lesson 10: Psychological Safety is more important than DevOps

The final lesson I have learned from this course is that it doesn’t really matter what sort of technical stack you are dealing with or what your previous experience or knowledge capacity is. When teams feel psychologically safe in their workplace – they will unlock almost magical abilities to build amazing, high performing software and services. I cannot overstate how important the idea of psychological safety is to building great teams.

The DevOps world likes to talk about how DevOps is a “culture” – but ultimately theres nothing DevOps about being psychologically safe in the workplace. You could have the smartest developers and operations teams in the world on a team, and if they don’t feel psychologically safe and connected to their work – they wont amount to anything remotely resembling a team of novices that do. 

Cohesion happens not when members of a group are smarter but when they are lit up by clear, steady signals of safe connection.

Coyle, Daniel. The Culture Code: The Secrets of Highly Successful Groups (p. 26). Random House Publishing Group. Kindle Edition.

I have recently done quite a bit of study on the idea of Psychological Safety (Truth: I read one book called the Culture Code), and it has greatly changed my view on how I coach teams and train folks to engage in DevOps practices.  If folks don’t feel constant, safe, future oriented connections with the work and their fellow team members, no amount of continuous integration and delivery is going to help them create customer value faster. 

It’s a difficult thing to try to teach – the culture of being safe. But it’s not a DevOps idea, it just so happens that teams with these safe, connected cultures tend to come up with really great, agile ways to deliver value continuously to their customers. To me, the idea of Psychological Safety is really what unlocks the power of any new way of working. If safety and connection are a prerequisite to how a team works – then they will typically encourage each other to find the optimal way to deliver value. 

It just so happens that, that optimal way really looks a whole lot like DevOps 🙂

When you ask people inside highly successful groups to describe their relationship with one another, they all tend to choose the same word. This word is not friends or team or tribe or any other equally plausible term. The word they use is family. What’s more, they tend to describe the feeling of those relationships in the same way.

Coyle, Daniel. The Culture Code: The Secrets of Highly Successful Groups (p. 6). Random House Publishing Group. Kindle Edition.