Voices in Cloud – Episode 15: A Conversation with Jayne Groll of the DevOps Institute

Guest

Jayne Groll is co-founder and CEO of the DevOps Institute (DOI). Groll’s IT management career spans over 25 years of senior IT management roles across a wide range of industries. Her expertise covers multiple domains including DevOps, Agile, ITIL and Leadership, and is a recognized and respected IT thought leader and influencer.

In addition to authoring the Agile Service Management Guide, Jayne has co-authored several IT position papers including “Modernizing IT Operations in the Age of DevOps” that was published in 2018 by IT Revolution.  Jayne is very active in the global DevOps, ITSM and Agile communities and is a frequent presenter at local, national, international and virtual events.

Transcript

Jon Collins: Hello, and welcome to this edition episode of Voices in DevOps, where I’m here to speak to Jayne Groll. I hope I pronounced your name right there, Jayne. Let me check I’ve got that right from the start.

Jayne Groll: Yeah, you did.

Excellent, excellent – who’s CEO of the DevOps Institute. I’m literally reading from the website here – advancing the humans of DevOps, which we’ll definitely get into. Before we do, as we like to do on these podcasts, how about we just start with a little bit about you, your background, and what brought you to be running the DevOps Institute and talking to me at this moment in time?

Thanks, Jon, and hi, everyone. I am Jayne Groll. I’m CEO of the DevOps Institute. My path to DevOps has been really fascinating and almost accidental. I’ve been in IT a long time. I’ve served in several senior management roles, and then about 15 years ago, founded ITSM Academy at the early days of ITIL Along the way I got to know a bunch of very interesting people, one of whom is Gene Kim, author of the Phoenix Project.

In 2012, Gene invited my business partner and I to a DevOps Days in Mountain View, California. It was really the early days of DevOps, where there was still debate about whether DevOps would be able to cross over the chasm into the enterprise community. There was just a spirit or a spark there. We saw it and said, “This is something very different and very special. It doesn’t fit into different models.”

Then fast forward to 2015. A couple of us got together and said, you know what? DevOps is really starting to reach into the enterprise space.There’s so much information about it because it’s so broad. We really do need to create a community, a member community where creation of these emerging practices occur; really helping to stand up communities of practice, and then also looking at: ‘what are the skills associated with successful transformation?’

We introduced seven certifications, very skill-specific certifications around DevOps. Since that time, our community has grown exponentially. We just joined the Continuous Delivery Foundation. We do an annual community survey known as ‘upskilling.’ We really look at skills transformation from a... which skills – if you’re a human of DevOps, which skill should you be focusing on? I’m very fortunate to talk to people like you and other influencers in this space to really understand, what are those voices of DevOps?

Yeah, that remains to be seen. We haven’t finished this yet. You might change your mind. I’m fascinated by one thing you said, which was ITSM. What I have seen quite frequently in the world of DevOps is – I spoke to Andi Mann – I’m sure you’re familiar with Andi at Splunk – about this previously. A lot of DevOps is seen as ‘big dev, little ops.’ Anyone that’s got the background that’s ops-related doesn’t necessarily see big ops, little dev, but certainly sees a bit more balance there. I’m interested in your perspective, in terms of that big, small or big, big. Some people say, for example, we don’t need ops at all. It’s just no ops. It gone – not a problem.

It is fascinating. Of course, I know Andi really well. We’ve collaborated on the term ‘new ops,’ which by the way, I coined. I’m proud of that.

He did not say that.

I know. He never says that, but it’s true. In any event, it’s really interesting because there’s some that think it’s dev, dev, and there’s some that think it’s ops, ops. I can put a little data behind that, actually. I mentioned we run this annual survey, which will, by the way, launch again in August, looking at what skills are considered important.

Ironically, from a functional skill perspective – by the way, half the respondents self-identified as dev, and half the respondents self-identified as ops – couldn’t ask for better, right? Number one process skill was software development life cycle. Everybody needs to understand SDLC. Number one, two, and three functional skills that everybody needs to know was IT operations, infrastructure, and security – again, kind of fascinating that regardless of what role you’re in, we need to cross-pollinate.

The term ‘no ops’ had a good intention that we need to be able to automate more of the operational toil that’s coming out of SRE. We need to be able to reduce that amount of manual work. The problem with no ops is, people interpret it as no job, no respect. They didn’t necessarily hear that no ops necessarily meant ‘new ops.’ From an operational perspective, everybody needs to understand operations. But if you look at emerging practices like site reliability engineering, which very much is trending very fast and very high right now, operations is still quite alive. I think that organizations are hiring really hundreds of SREs because it’s a real job. Its approach to service management is that marriage of people, process, and technology. If you don’t mind, let me just say one more thing about ITSM because I think it’s –

Sure, please do.

I have a long heritage in the ITIL and ITSM space. I absolutely think that those that suspect that ITSM is dead are wrong. We will always need to manage services. Products roll up into services. How we do that, I think, may change. SRE, I think, is a great example of that – doesn’t mean that ITIL and others are no longer valid. But I think that we have to start to look at: ‘How do we modernize that?’

Loyalty to a particular framework, loyalty to a particular set of guidance is where IT’s going to run into its challenges. It’s like the seven kingdoms of Game of Thrones, where everybody’s very loyal to their realm, and thinking that each of these ingredients is the silver bullet. It’s not. We will need to manage services. We obviously need to have operational practices. Developers need to learn that, and operations folks need to learn how to code.

I think as you were speaking, I was recording a webinar with Sauce Labs this week. We were talking a lot about automation. What was fascinating about the conversation around automation was the fact that automation is very hard, which you know. I know. Anyone that’s actually tried to automate things knows because you’ve got complexity breathing down your neck as you’re trying to automate anything. You automate the simple stuff, and then you spend the rest of your life trying to make it work for everything else.

The no ops – there is still this assumption that all the problems are going to go away, whereas in my experience with automation, there’s always more to do. Having been an IT manager, an IT director and so on, you’re never done. There’s always a thousand more things that you’d get around to if only the even harder things got out of the way. There will always be jobs. There will always be things to do. That’s my opinion.

Oh, I absolutely agree with you. Automation doesn’t happen through other automation. Jez Humble, in his Continuous Delivery book says, “Let the computers do the boring, repetitive work. Let people do what only people can do, at least for today (hello, AI) which is critical thinking skills.”

We need people to be able to automate. We need people to feel really comfortable with automating that repetitive, boring – SRE calls it ‘toil.’ You say the word toil, and you can almost feel that burden on your back. We’ve done a really good job of automating the rest of the world. We just haven’t done a really good job of automating ourselves. You’re right. It’s hard. Yeah, it’s hard.

With that in mind, and I’m staring literally at your skills, knowledge, learning ideas picture on your website, which anyone else can look at exactly the same as I am, so it’s not like I’m staring at something no one else can access. DevOps Institute, what do you bring to the party, etcetera, but let’s segue into, how do you see the challenges for the organizations that you’re looking to help? What are the real ‘crying out for help’ cries that you get?

Thank you, by the way, for looking at our website. We very much focus on the human aspects of DevOps. We use the word ‘human’ intentionally because regardless of any other characteristics, we are human. Regardless of where you are, regardless of other aspects of your life, we’re all human. I’m going to go a little bit in reverse, Jon. One of the biggest challenges is that a lot of organizations are confused about the human aspect of DevOps.

Automation, even though it’s hard, it’s easier. We know how to buy software. We know how to implement applications. We’ve been doing that a very, very long time. Even though we’re looking at it from a different perspective, it’s a comfort zone for most in IT because it’s what we do. Updating software, adding virtual infrastructure, going to the cloud – yeah, there are some challenges, but again, it’s in our wheelhouse. Updating people is something we’re not really comfortable with. We haven’t done it.

We’re a pretty young industry. Really, looking at the organizations that have been massively successful, it’s not because they’re showcasing their amazing pipeline. It’s because they’re showcasing something that they did culturally, something they did [that’s] very humanistic that really took them to a different place – organizations that introduced Dojos. Amazon just announced a $700 million investment in upskilling. Those are the organizations that are taking substantive steps to update their people as much as they’re updating their software. I think that’s a very, very big differentiator that most enterprises need to focus on.

At DevOps Institute, we introduced a S-K-I-L or SKIL framework looking at the holistic needs of updating the human. Skills would be certifications, job boards, things that grow your career, things you would put on your CV, opportunities for you to develop, skills assessments, learning paths. Those will absolutely grow your career, but it’s not enough. K is knowledge. Knowledge comes from books.It comes from podcasts like this. It comes from surveys and research case studies that give you passive insight. It doesn’t really tell you how to do something, but it gives you some really good ideas.

If you’re going to have ideas, you need to have opportunities to share those ideas with others, and that’s our ‘I.’ Those are events, and they’re forums, Slack channels, and opportunities to make the community interoperable so that they can share ideas with each other, instead of necessarily reinventing the wheel.

Then finally, the last part of our SKIL framework is L, and that’s continuous learning, bite-sized learning. We just introduced a series called Continuous Learning Minutes by some pretty good influencers, some of whom I’m sure you know and have mentioned already, that are just going to give you two or three minutes of what is something. What is toil, for example? What is release automation? What is cultural resilience?

We’re recruiting a whole bunch of thought leaders to just record these two or three-minute videos that help the market develop a common understanding of what is Kubernetes, CloudNative, or terms you hear in the hallway? That’s part of continuous learning, much of which is not certification worthy, but can be very, very bite-sized. SKIL is really what DevOps Institute is bringing to the market. If you don’t mind one more thing, we are a member community. Membership is free, and it will remain free. At some point, if we have premium offerings, we’ll explore that, but I really do encourage people to just come and join. We’re not going to hit you with an invoice.

Wow, I’m thinking, okay, I’m just going to register. Yeah, keep talking. I’ll just get that – let’s see if I can get it done by the end of the podcast. I’m fascinated. You’re firing off so many synapses here, which I guess is – this is your trick, you’re a training organization. I don’t know if you know the name – but Tony Christensen at RBS – I’ve been following RBS’ progress into more Agile practices for a few years because we’ve done work together at various times. Most recently – in fact, it was at the AWS Summit in London last year – that was the last time I saw Tony. He said, “We’ve decided to focus on continuous learning as our ultimate goal.” I don’t know if he’s been to your courses or if the organization just arrived at that point off their own bat, but there is provenance and proof that other people are doing precisely the same thing.

While I can see it fitting into a cycle, does it also, as Tony intimated – do organizations mature towards these models? If so, where do you see them start? Is skills the lowest level of maturity, or is it more of a cycle thing? Does that make sense?

It does, and it’s a really, really great question. I just want to clarify. DevOps Institute actually doesn’t teach anything. We accredit seven certifications. We have about 200 partners around the world that teach classes that meet the requirements of our certifications, but we do interact with a lot of training companies. We understand what the need is.

The interesting thing about skills is, I would tell you two years ago, skills was probably something that was expected to be organic. It was expected to be something that people did on their off hour, whether you’re going to take an e-learning class. Maybe they would get funding to go to a two to three-day class, but it was something that was budgeted – training budgets always have been very healthy – but wasn’t necessarily part of the key paradigm, particularly if it wasn’t technical training. I will tell you [that] in the ITIL and the agile space, organizations have funded a lot of training.

Again, generally, from a DevOps perspective, which skills, what training, how do you know, I think became really important. What’s fascinating now is there’s a little bit of a flip, probably over the last year to 18 months, where there’s a huge talent gap. If you go out on LinkedIn, I think there’s 60,000 jobs that have the word DevOps in it. There’s this huge skills gap right now.

Organizations that presented events like DevOps Enterprise Summit talk about skill constraints or skills transformation. Skilling has definitely and upskilling has definitely risen. I mentioned the Amazon investment. I think that organizations are now realizing that, first of all, they need to invest in skilling. Going out to the talent market where there’s such a competition for talent on the market means that they have to take some intentional steps to allow individuals to continuously learn. Even in the data from our upskilling report, the predominant thinking was to hire from within and to upskill existing employees.

That’s good news for anyone that works for an enterprise. Your organization is invested in you. I also think it’s much more intentional. I mentioned Dojos. People learn a lot of different ways. A Dojo is a very immersive environment where a company starting with US retailer, Target, and then now other organizations have done it, have hired coaches that immerse you into a new way of working for a period of time, and then send you back out into the wild and bring another team in. Continuous learning is very much a principle of DevOps. It’s one of Gene Kim’s three ways. I think enterprises are realizing it’s upskill or die. You either upskill your staff, or upskill through talent acquisition, or you’re going to get left behind.

We are seeing a lot of organizations that fired a lot of their engineers ten years ago. Now they’re madly trying to recruit them and struggling. That’s part of the reason we’ve got such a skills gap because they can’t get away without them. It does make me laugh because ultimately, I can’t see what a bank is other than a software company. I’ve never been able to understand it. It’s a transaction engine in the sky with branches. The thought that you can do it without engineers always boggled me a little bit.

Question for you, and this cultural idea – I don’t want to dwell on the philosophy of it. I’d like to get into the practicality of it. A lot of times, I speak to a DevOps company or people promoting DevOps, etcetera. They’ll say, “yada, yada, yada, continuous, yada, yada, yada, this, that, and the other, deployment... but you need a culture change.” It’s left as an adjunct to everything else.

It’s almost like they’re always working back from the answer. We’ve worked with lots of organizations that really succeeded because they have a different culture. Therefore, everyone else needs a cultural change. I’m wondering how to advise people that don’t have that culture in place. You can’t just say to them, “What you need is a cultural change. Can you have it by Monday? That would be helpful.” What do you do? Where does one start to actually change culture to make it DevOps friendly?

Thank you for that question because I really have an organic approach to that. First of all, you’re absolutely right. Culture is not surgical. You can’t surgically remove the old culture and surgically re-attach a new one. Sometimes when we use the word culture, there’s an implication that you can. Karen Ferris, a really well-known culturist, wrote an e-book for us on cultural resilience, which is individual, How to be Resilient in a Culture of Constant Change.

Culture doesn’t transform. People transform. Humans transform when they’re inspired to do so. Culture is a rollout from people. In fact, if you look at the definition of culture, it’s the social and psychological behaviors of individuals in an organization. How they socialize and how they psychologically approach their organization really does impact culture. Atlassian announced this week that part of their performance reviews is going to have a very cultural, social aspect of it.

It’s not just being friendly. It really is trying to make sure that there is better collaboration, but that’s intentional.

You have to give people an opportunity to transform. Part of it is upskilling. Part of it are things like hackathons, internal DevOps days, encouraging them to listen to podcasts like this, really providing a supportive and nurturing environment that helps people transform. People don’t transform the same way. I may transform or I may adopt a new approach faster than you. You may adopt it faster than somebody else. If you look at that curve of early adopters to laggards, you’ll see that there are some people you have to bring kicking and screaming along the way or leave them behind.

It has to be something that people feel socially and psychologically that they are a key part of what’s happening in the environment.They’re being encouraged, motivated, inspired by a transformational leader who will give them the confidence for them to try something different, give them the confidence to be able to experiment, and also just give them the support if they fail. DevOps talks a lot about mindful failure. Nobody wants to fail, but the opportunity for failure as an improvement model is embedded in DevOps and embedded in site reliability engineering. It is very people-based. It’s not surgical.

Yeah, the notion of ‘fail fast’ – I can remember, actually, back to when I had a real job, and I had performance reviews. Someone advised me, “Never be honest in your performance review because some bosses would treat honesty as weakness.” If you said, for example, ‘I’m not very good at timekeeping.’ They wouldn’t say, “how can we help you?” They’d say, “okay, won’t give you a pay raise, then.” The culture goes in so many different directions, doesn’t it?

Given what you bring to the party, that whole skills, knowledge, ideas, learning stuff, how can we apply – is upskilling the key that unlocks all of the doors? Start with skills, start with skills, start with skills, and knowledge, ideas, and learning will roll out because of those consequences of that. Do you have to actively deal with the other areas as well and nurture each one in separate – I’m almost imaging a chemistry set with separate bowls of goodness going on?

There’s no perfect formula. Start anywhere. Start with continuous learning minutes and build your vocabulary, get to hear some pretty interesting people describe some pretty interesting topics, and that series will grow. Take a class. Take a DevOps foundation class. We spend – went to 16 conferences last year. My team actively curates a lot of the practices, some of which you’ll never, ever see in a book, that grew up in the wild. Sit in a class. Take a virtual class. Take an e-learn class. Bring training into your organization through one of our partners or read the upskilling report.

I am not arrogant enough to think that everything we have is the only thing. We really do serve as curators. We’re introducing a guru café. Go grab a cup of coffee. Go into our guru café, which is really just off of our website. Read an e-book. Listen to a podcast. Do something on a daily basis that’s upskilling mindfulness, a wellness program.

It doesn’t mean that you start with a skill, or you start with knowledge and then the rest of it follows. Start anywhere. Continuous learning hopefully becomes part of your regimen, and something that you, your boss, your organization support. By the way, if you learn something, share it with one of your colleagues. Be able to cross-pollinate because that’s cultural shift as well.

That’s a huge message I’m getting out of this. There’s a lot of seven habits going on behind the scenes in what we hear – learn then teach, sharpen the sword, those kinds of things. If I’m getting one takeaway from this, as we start to wrap up, it’s: start learning. Just start separating yourself from the problem at hand, and just start to give yourself some space in which you can start to think properly, understand how to do that stuff better. Take a course, listen to a podcast, and then – I’ve written this down as a note to myself. If you’re a boss, if you’re a senior person, start encouraging behavior so other people can do that. Then, as, you say, to share it, to nurture it, to cross-pollinate it.

Yeah, absolutely. Just to wrap up, I think it’s a great day to be in IT. Really, it’s a great day to be in IT. I’ve been in IT a little bit longer than I want to really admit to you. Where else do you get a job where you are now encouraged to learn every single day? You’re encouraged to experiment. You’re encouraged to collaborate – not only encouraged, you’re required to learn. You’re required to think disruptively. That’s amazing.

If I were a young person entering into this space today, yeah, it’s a little bit scary, and it’s a little big. There are a lot of jobs out there that don’t require you to do that. I would absolutely embrace the fact that from an IT perspective, we’re really in a pretty good place. Your talent is needed. Again, I would celebrate that.

I’d love to speak to you much, much, much longer. I really hope we can talk again, but what a great note to finish. Jayne, thank you so much for your time. One last thing I did want to say, and you guys do have great socks.

Yes, we are really well-known for our socks. If you are at any of the events we’re at – I think next one for us will be DevOps World, Jenkins World in San Francisco – come by and score a pair of the coolest socks on the planet.

There you go. Thank you so much, Jayne.

Thank you, Jon.