Episode 60: Upskilling – Live from DevOps World 2019

Announcer: You're listening to DevOps Radio, the podcast series that dives into what it takes to successfully develop, deliver, and deploy software in today’s ever-changing business environment. This show is sponsored by CloudBees, the Enterprise Jenkins company and continuous delivery leader.

Sam Fell: Hey, everybody, welcome to another episode of DevOps Radio. We've got a very special program for you today live from DevOps World | Jenkins World 2019. I'm joined by a few of my favorite people. We just finished a live panel here talking about upskilling, and we're gonna go through some of the things that we talked about. I'm gonna start with Jayne—Jayne, can you introduce yourself to the folks?

Jayne Groll:  Sure. So, I'm Jayne Groll, I'm CEO of The DevOps Institute. We're an open member community, so I hope everyone listening will join at www.DevOpsInstitute.com. We also are the founders of the Upskilling Enterprise DevOps survey and report, the first of which was published this past February, and hopefully, we'll be able to share some of the data from that while we're talking to everybody today.

Sam: Wonderful. Thank you for joining us. To your right is Damon, Damon Edwards—introduce yourself to the folks.

Damon Edwards: Yeah, hi. I'm Damon Edwards, I'm a co-founder of a company called Rundeck. We do runbook automation for incident management. So, make an incident shorter and protecting team capacity, but I know that’s not why I'm here today. [Laughter] I think it’s my previous life experience as running DTO Solutions as the managing partner there. We did a lot of DevOps and IT process improvement for large enterprises. We were the go-to kind of organization for taking the high flying early DevOps ideas, importing them into large enterprises. So, a lot of experience trying to get the human beings figured out.

Sam: Wonderful. Thank you for joining us. Sean Davis?

Sean Davis: Hey, so, I'm Sean Davis, I'm chief transformation evangelist for Equifax. Also, a DevOps Institute instructor in several of our areas, most prominently in DevSecOps. I have some pretty heavy background in working with a lot of Fortune 1000 and 500 companies around business transformations, technical transformations, and digital transformations, moving to the cloud, changing the company’s culture.

Sam: Wonderful. Thank you for being here. And Helen Beal?

Helen Beal: Thank you, I'm Helen Beal. I am a DevOpsologist at Ranger4, where I help my clients in Europe and the Middle East improve their organizational performance using DevOps principles and practices, and I am also a Product Owner at DevOps Institute for Jayne.

Sam: Lovely. Alright. So, I think to get the conversation started, it doesn’t take much more than looking at some of the news that’s been in the media recently about some of the investments that companies are making in upskilling their people. I mean, Jayne, do you wanna talk a little bit about the Amazon investment?

Jayne: Sure. So, recently, Amazon announced a $700 milion investment in upskilling, and they actually named their program Upskilling 2025. Now, that’s really gratifying. Well, first of all, it validates some of the data we saw in the report last year where the predominant hiring was from within. So, organizations would prefer to upskill existing staff, and certainly, Amazon is putting a large investment behind that, but it also demonstrates that one of the reasons upskilling is so important is there’s a huge talent gap right now. There’s a huge need for new talent, cross talent, multitalented people. And so, part of the goal is met by really investing, right, putting your money where your mouth is—investing in helping existing employees really start to groom new skills in order to meet new demands and therefore be able to improve the competitive landscape.

Sam: Yeah, absolutely. There’s been a pretty interesting thread going on on Twitter about internships, whether they should be paid or unpaid. And so, you talk about how do you bring that next generation of folks forward and how do you help them get that knowledge. I think there’s one reason, and I'm glad to hear it, one reason why people wanna train their existing people is, the existing people have a lot of institutional knowledge. They have a lot of ideas around what’s happening and they have the context.

Damon: You know, I make a point about the Amazon thing, it’s interesting, is that I feel like training budgets have never been the problem. A little helpful tip for anybody who wants to be a consultant—package whatever you do as a training and the budget is unlimited because it’s never spent.

Sam: Interesting.

Damon: Okay, unlimited is an exaggeration, but the budget is always there, right? [Laughter] You know—oh, 50 grand here, 100 grand there. They're just sitting there in these training budgets that never get used. So, it was always a great way to get things into organizations. And I think the issue is, that’s great—

Sam: This is a training coffee machine.

Damon: Yeah. [Laughter] more on the consulting side, but it’s an issue of where the budgets are there but it’s always kind of a middle management problem. I mean, it’s a problem with middle managers, I mean, it’s a problem with the pressures in the system that they're dealt with. It’s like—okay, great, now, I'm gonna take my team, I'm gonna send them for training. Training for what? You know, they all wanna go to Kubernetes training. We're not using Kubernetes, that’s weird, right? [Laughter] So, you've got this, “Oh, they're gonna go waste their time,” right? Which is one. Or, “Why am I training my people to go get their job next job?” Right?

Sam: Right.

Damon: And then the other one is—okay, well, they need skills for this particular project. Well, we're not gonna take a project budget and stop and have them go learn these skills. We gotta now bring in external consultants to go, you know, to import the skills and keep my people busy with something else, and maybe they'll learn by magic, you know, osmosis. So, I feel like the problem has never really been the money. The problem has been more of a structural and kind of organizational dynamics and incentives has always been the blocker to organizations training, upskilling, whatever you wanna call it.

Sam: Right. And we had the conversation just a little while ago where we were talking about, you mentioned the sort of investment that people are making and that they're willing to make. And you made yourself a little vulnerable on stage earlier and you talked about a decision that you’d made many years ago—not that many, because you're not that old, but—

Jayne: Thank you. [Laughter] 

Sam: - many years ago that you wish you could have done differently. Tell us a little bit more about that.

Jayne: So—true confession time, I did on this stage, so I'll purge myself even longer. So, when I was an IT director—which, admittedly, is a while ago—it was a time where MCSCs was a very coveted certification, and I ran an Ops team. And so, I couldn’t send them all to class, right? I couldn’t take them off the bench and send them all to class. So, I purchased 20 online licenses for MCSC training—which, by the way, was pretty expensive, right?

Sam: Mm-hmm.

Jayne: And so, I offered it to them as an opportunity. It was my gift to them that, if they were to go through this program, that they would then become MCSCs and presumably be eligible for promotion, grow their careers and whatever. The mistake I made, and I think a lot of organizations even today make is that, while I gifted it to them, I didn't gift them the time. I didn't say, “Hey, everybody, rotate two hours, go lock yourself in a conference room and spend some time doing this.” The assumption was that they would do it on their own time. They would do it at night, they would do it on weekends, because I had already invested this money. I wasn’t going, “Hey, you have work to do during the day. What, do you think you're gonna go sit in a room and learn? No, no, no!”

Sam: [Laughter] 

Jayne: And, you know, reflecting back on that, that was a huge mistake. Because, you know, as I shared on stage, I bought 20, pretty expensive—only one person finished, right? So, I expected them to be excited and passionate and motivated to give up their family life, their personal life, their drinking life, their sleeping life in order to be able to do this accomplishment. And that was pretty naïve, and it was also pretty selfish, because I really didn't give them the time to learn. So, again, a long time ago, lesson learned. But if anyone’s listening to this and you're kinda thinking the same thing, you're thinking wrong.

Sam: Mm-hmm. Interesting.

Helen: That’s an example of cultural debt, isn’t it?

Sean: Absolutely.

Helen: A lot of organizations have a lot in culture and technical debt, and it’s kind of in contention with, I think, the pattern that we're trying to encourage in these new ways of working in terms of organizations being dynamic learning organizations where every individual feels empowered to learn, and that comes from the leadership and it’s all across the organization.

Sean: Oh, absolutely, yeah. You know, cultural debt and technical debt kinda get a bad rap, too, because everyone talks about them like they're the dirty word behind the closed doors and they can’t have any. But it’s healthy to have some cultural debt. Where it becomes unhealthy is when we choose not to pay that back. You know, we can’t go hiring people and say, “Hey, we want guys with the right mindsets, and they're willing to be able to learn stuff, and then we'll train everything else.” And then you know what happens—they get to work, we throw ‘em in the fire. Six months later, they've still not been stopped to actually fill that gap we made the commitment for. They get burnt out, they leave the company, and they tell everyone about this bad experience, and then everyone else in the company sees it and they're like, “Oh, not a big deal. This is just the way it always happens, and this is the way it always happened,” right? And it ends up hurting our culture across the entire organization now, not just in this one specific instance.

Jayne: Yeah. And if you don’t mind, I just wanna add something about the Amazon thing, because I think it was really interesting. Notice the project isn’t Upskilling 2020, right? It’s Upskilling 2025. So, there’s a couple of interesting things to observe about that. First of all, upskilling takes time, right? So, you can send somebody to a two-day class. They will come out with good practices, but they won’t be practiced, right?

Sam: Right.

Sean: Yes.

Jayne: We have to recognize that upskilling is something that requires some time, opportunity to practice, opportunity to fail, opportunities to experiment, opportunities to learn. The other thing is, while we use the term upskilling and our report is The Upskilling Report, it really means right skilling, right? It means that in this broad base of skills, what are the right skills for you, for your personal goals, for your organization and moving forward from that? And I think that when we start to look at these skilling programs and more and more of those are becoming—you know, are being published, at least. I don't know what’s in the scenes, but they're being published—is that hopefully they're looking at it as right skilling for the right skills for the right person. And, of course, that also means that, on an invasion level, if I'm passionate about something, I may want to become comb shaped instead of T-shaped, which means, I have multiple areas of depth.

Sean: Absolutely.

Sam: Do you wanna maybe talk a little bit about what a T-shaped person versus an I shaped person is for the folks who are listening?

Jayne: Sure. I don’t wanna hog the conversation too much, though.

Sam: Well, maybe someone else could talk about it. Helen, you probably could talk about T shaped and I shaped.

Jayne: Do you wanna talk about T shaped?

Helen: Yes, I'll talk IT pi comb, if you like. So, I is, I'm a developer, for example. T is, I'm a developer, and that’s the I. and then you've got a bar that runs across which makes your capital T, and that bar at the top would be a broad generalist, for example. Then you've got pi, which isn’t a thing that you would eat, it’s the Greek letter pi, so imagine a T now with two legs, if you like. That might say, “I'm a dev person and a tester and I've got broad specialist knowledge.” And the comb—so, it’s kinda the comb that you comb your hair with. So, imagine that—loads of teeth, and you might say, “I've got Dev skills, I've got test skills, I've got security skills, sysadmin skills, I've got a bunch of skills,” and linking them all together is broad business knowledge. 

Sam: Is that a full stack engineer?

Damon: Also known as a unicorn.

Jayne: I was gonna say, and a horn, and a tail, right?

Sam: A unicorn, yeah, yeah—do those exist? And that’s another question that we were gonna get into is, does a full stack engineer exist?

Sean: No. [Laughter] 

Damon: Well, it’s interesting, because one of the biggest misconceptions about the T shaped idea is similar to the misconception about the cross functional team idea that everybody must be the expert in everything right?

Sean: Absolutely.

Damon: Or that, “Oh, I can never be a T shape, because”—like, they think of it more like a block, right?

Sean: Right.

Damon: Like, “I know everything about everything.” And I think you see in organizations that there’s still, there’s a high demand for owning a specialty, for saying, “This is what I do. This is my thing that I can hang my hat on.”

Sean: “I can help here.”

Damon: But you need to be able to build that understanding of how the rest of the world works around you because nothing lives in isolation.

Sam: Right.

Damon: So, you need to be at enough to work within those systems and then enough to have the same, you know, kind of impactful conversations with the other specialists in those areas.

Helen: And I think there’s a couple of other considerations, kind of, around this conversation. One is, what are the outcomes we're looking for? And one is, the definition of “done” is not “I did my job,” but “the customer received value.” The other desired outcome really is about not having any kind of friction or delay in our team. So, if one day, there is more tasks that need to happen that are test related, there is an opportunity for a person in that cross functional team perhaps to do a bit of the test automation scripts if they're normally a developer and move around a little bit like that.

Sam: Mm-hmm.

Helen: And then I think the other thing we talked about earlier on is that—and I know we're talking about skills and culture and people, but actually, there is an opportunity to talk about automation here, because the tools allow us to perform different roles in a way that we haven’t been able to before.

Damon: Yeah, and as I said, I think the tools become the conversation piece. It’s easier to talk about configuration and code than it is to talk about sort of general ideas where you don’t know—

Sam: Squishy.

Damon:  - I can’t see the mental model in your head, you can’t see the mental model in my head, so it becomes—you know, it’s hard to build and understand in that regard. But if I put it down into code—and code could be a YAML file, right? It doesn’t have to be—

Sam: Yeah, complicated.

Damon: - right, it doesn’t have to be—

Sean: Identified in some way.

Damon: - executable code, right, it’s just something that I can kinda treat through a software development life cycle. I can version it, I can have a build process, I guess, that puts it together, I can distribute it to people. But if we can talk about the automation, it does help that conversation. So, there’s a side benefit to—other than just being something that’s automated—but it’s also, now, we can all collaborate on that definition and we know what we're talking about and we can pass it around, and I can know as if that’s part of my T and not part of my stem or I or whatever it is, that I can read that. And if I know how all of that works, now I can have a good conversation with you about that, and you might know all the intricate details of everything that could possibly happen there and have thought out all the different permutations, but we can now have a conversation about, “Okay, how do we evolve this code? How do we get it to do what we need it to do?” And it’s, I think, useful for facilitating these conversations.

Sam: Right, and it gives you something to hang onto, some context for you to be able to have that conversation with because it’s codified, as you mentioned.

Damon: Especially in big distributed organizations now.

Sean: Can we all agree that one of the prerequisites for exceptional efforts of skilling should probably start with having that common language, right?

Helen: Absolutely.

Sean: You made a really good point where you said, “Hey, you don’t see the same in the mental model that I do.” But if we're both speaking the same language, when we say agile, when we so DevOps, what does that mean to us and we're both on the same page about it, it’s much more effective to get value out of the effort than it is when you expected something totally different.

Jayne: So, as everyone sitting here knows, DevOps Institute just recently introduced a series called Continuous Learning Minutes, and I think everybody here has contributed to that. And it’s really like a video glossary with context, right? And it’s just for that purpose that, if you hear a term or a concept or you're having a conversation with somebody, language is the enabler and it’s also the constraint. So, if I—and natural language versus tech language. If I'm talking to you and I say something but you don’t understand what I mean, I'm going to shake my head appropriately, but I'm not necessarily gonna—

Sam: It compiles, but it’s not gonna make it through the test cycle, right. [Laughter] 

Jayne: [Laughter] But you know—but again, I'm going to know, but I'm not going to contribute to the conversation. In fact, I may become intimidated by it, right? And so, it doesn’t encourage a better level of collaboration. So, Continuous Learning Minutes, two to three minutes—in Damon’s case, five minutes, as he confessed—

Damon: I had a lot to say.

Jayne: [Laughter] [Cross talk] Two to three minutes on different topics, really by thought leaders explaining what something is and why it matters, right? So, we had one done here yesterday about Spinnaker, right? Which, a lot of people don’t know what Spinnaker is. I didn't know, really. I knew the term, but I really didn't know anything more about it. We've had Toil, we've had [Cross talk] we've had ChatOps, we've had cultural debt. And so, it spans a really wide range of topics—very benign, very comfortable. So, if you hear something and you're not familiar with it, go listen to a Continuous Learning Minute for a couple of minutes and then go back to the conversation, right, and reach out to that person. So, hopefully, that—and you're right, we have to have a common vocabulary. And so, that’s very, very critical. I also think, and to speak to Helen’s point about the different pi shape, comb shape, or broom shape, they call it—I think what’s really, really important is, when we start to look at value stream mapping, for example, as an exercise, the interesting thing about value stream mapping is not the amount of time it takes to do an activity, it’s the amount of time between an activity.

Sam: Right.

Jayne: So, the more that we enable people to do a certain level of something testing, right—so, I'm a developer, I can do a certain amount of testing, I'm not an expert tester, I'm not an overachiever, I'm not necessarily going to become an expert at it, but it may reduce some of the wait time, right? It may give a faster flow because I have now enabled myself to do something that maybe previously I needed somebody else to do for me. So, it is an empowerment of sorts, but with empowerment, it also means that you have to take the first step, right? You know, people upskill. I can’t upskill you, you can’t upskill me—people upskill.

Sam: So, Sean, talk a little bit about the program that you guys put in place at Equifax and how you, the success that you were seeing with people who were offered training and what you did to help increase that level of success.

Sean: Oh, absolutely. So, one of the really interesting experiments that we had that kinda prefaced some of the stuff we talked about in the panel was, when I first came in, we had bought all of these licenses and signed a multi-year contract with a vendor to be able to provide training, because everyone says, “Hey, we want video training, right? That’s how we best learn.” So, we took that feedback, went and found a best in class vendor, made a partnership. Well, four months prior to me arriving, we had been setting up all these programs, worried about cohorts, drawing up a ton of documentation, creating all of this collateral, and we had only gotten about 250 licenses out the door.

Sam: Mm-hmm.

Sean: So, when I came in, I said, “Hey, you know, one of the things I've found that’s been very successful in cultures is, you wanna get it into the hands of the user as quickly as possible.” I mean, that’s really what DevOps, DevSecOps, and a lot of these things we're talking about result in is, how quickly can we get value into the hands of our end users? And I said, “Let’s try an experiment where we just automate anybody being able to get a license, but we wrap some requirements around it to hold some accountability.” So, when you sign up, you know the rules of engagement, you don’t just arbitrarily ask for it, stuff it in a drawer somewhere and then never use it and then value is lost. And Jayne’s example of the certifications. So, the immediate next six weeks—alright, keep in mind, four months, it took us to roll out 256 licenses. We only had—

Sam: Are those 256 people who had finished something or just people who were issued a license?

Sean: No, out of that, only 11 percent actually finished any type of course that they engaged in, and I think we only had three people that were showing certification at the time. Because we were just getting our certification program started. Within the next six weeks, we only had 1,000 licenses—we blew through it in four and a half weeks, and there were no more licenses left. And we had just a ridiculous amount of people coming to us saying, “Hey, we wanted more,” so we ended up buying more. And we felt that, with that rule set of engagement, that we were too worried about the documentation and all of the other things that came around it that, just getting it into the users’ hands, we got much more rapid feedback from them about, “Here’s what we like about the program, here’s what we don’t like.” And now, we know where to target specific content, where the gaps are in the training programs. Whereas, if we would've made sure it’s all in a pretty document, make sure it’s well socialized and everything else—we wouldn’t have figured this out for over a year.

Sam: But you also put some compelling events around the acquisition of that license to use that content.

Sean: Oh, absolutely, yes. So, we had things like, when we send out your license, if you request a license, you have seven days to respond to that. If you don’t, your name goes to the bottom of the request list and everyone else has a slot before you. If, when you engage in a course, once you have your license, you have 14 days to engage in your first course. If you don’t—bottom of the list. If you start a course for certification or a practitioner license or whatever, solutions architect, you have 90 days to be able to complete it and then go test it out on the certification. You don’t have to obtain the certification, but you must finish that education, and it’s like, 7 to 12 hours’ worth of training, not very difficult. Or you lose your license and you get rolled to the bottom of the list. So, it holds accountability for people. And we saw our user stats shoot through the roof. I think it was somewhere in the range of like 87 percent of the people who engaged in the platform completed their courses. It was—you know, you saw the little bar chart, and then all of a sudden, when we allowed people to just have carte blanche access to ask for it, it was like, this difference compared to—it was crazy.

Sam: So, let me put a hypothesis out there. Would it be the reason why people weren’t doing it before is because they had work they had to get done and there was no mandate from anybody in management, no policy that said, “I have to take this training,” it was just the idea of, “I'm gonna sign up for training and I’d like to take it, but I still have all this other work I need to do.”

Sean: So, I think it was threefold or twofold. First was the access to how quickly they could get the license, right? Because you have to go through a request process, and that adds cycle time to be able to activate. The second was, was that we felt that users, they like to obtain something and then save it for when it’s convenient for them, because some teams in our organization, they have innovation hours that are budgeted specifically for the team, and some teams have more than others. There are a few teams that are on critical projects that are still kind of moving into the culture that don’t have that luxury yet but we're working with them to get there, but we've gotta get products on the door, right? We still have to generate revenue. And then the final one was, people didn't know what they needed, right? We're saying, “Hey, we're gonna go all in on Google Cloud and we're 100 percent in on this and we're building products today natively in it,” but no one’s ever done anything in Google Cloud, so they don’t know what services are out there, they don’t know what they need to be educated on. And you just can’t throw a catalog of 40 courses at somebody that says, “Here’s Google Cloud.”

Sam: Go figure it out.

Sean: You know? And then they're like, “Oh, well, am I supposed to start with storage? Am I supposed to start with data? Am I supposed to start with compute?” So, we had to wrap some training around that, and we were focused too much on cohorts. Like, how do we group people together to make sure they learn at the same time? But everyone was learning so differently and at different paces. It was, by the time you would get your hands around grouping them, most of these guys had either finished or they had lagged behind or the license wasn’t being used, and it was very difficult to kind of clump them together. So, there were a lot of really important lessons learned from the experience.

Sam: Yeah, very interesting. And there are two topics that I still wanna touch on. One is the comment you made about Kubernetes and whether or not we—like, we're not running Kubernetes, should we be learning about it? And I'll refer back to Sasha’s keynote where he talked about that accelerating pace of change. So, should we be having people learn about things that are not necessarily being used in our enterprise?

Damon: You know, I just had a conversation with somebody in the hallway about this after our last panel thing. And the issue they found is that half the time when they kind of activate people to train, they train for LinkedIn, not for the company that’s paying for the training. So, it’s like, “k8s, Kubernetes is the hot thing. Istio is the hot thing. I'm gonna go out and become the..you know, I'm gonna go out and become this, you know, knowing about Kubernetes and Istio,” right? And the Rally is like, “Uh, we don’t use Kubernetes,” right? [Laughter] So, “Someday, maybe.” Right? So, it’s kinda the idea of challenging people, to give them the space, but challenge them in the context of their current work, which actually makes it a better way to drive responsibility and to drive enthusiasm. Like, you know, I've no doubt that your method of—I'm pointing to Sean, here—the method of giving the licenses and then giving you the SLA that if you don’t do these things, they get taken away, it’s probably—you know, the time constraint is a good one. But probably the fear that, like, “Oh, I'm gonna get found out” is probably another one, right? The social pressure of, “Ooh, I'm gonna go on a list, right, of somebody who didn't do something.” So, they're like, “Eh, that’s not so good. I don’t wanna be”—you know, no one wants to be thought of as unreliable or as flaky in any way, right? But I think, by assigning tasks in terms of what we need to build, I think. And maybe part of that is—okay, we've got some people that are really excited about Kubernetes. Well, let’s carve off a little exploratory project to be like, “What’s the state of the art, right? Give us the ins and outs.”

Sam: Help us, right.

Damon: “And how could it possibly help us in the future?” We'll time box it, go to do that. You can learn something about it so you can scratch that itch, but fundamentally trying to drive these programs towards—you know, we have to accomplish project X. What are the skills that we need to know to do that?

Sean: Absolutely.

Damon: Well, instead of hiring a bunch of consultants, why don’t we try to figure out—and maybe consultants are the answer—but you know, how do we carve out some time in this process to say, “Okay, we're going to give people the time and the resources to learn something,” and then they'll bring it back to the organization and kinda become the mentors in the organization. So, trying to attach it to what the organization needs to do probably gets people more excited and more committed than being like, “One should learn about Google Cloud.”

Sean: Absolutely.

Sam: Right. It’s applied learning.

Damon: And you're like—okay, I'm looking at it like, “Where do I start? What do I do? Am I making progress?” It’s the blank slate problem, right?

Sean: Yes.

Damon: You know, the blinking cursor in the Word doc, like, “What do I do now,” right? [Laughter]

Sean: We actually learned from that, too, where we had to create learning paths for each. Like, architects have a different path and a practitioner has a different path than a developer because of that feedback where they said, “Hey, that’s really great, but yeah, we're getting anxiety because there’s so much stuff and we know we've gotta do it, but we don’t know where to start.”

Jayne: But you know, I understand what you're saying, like, “Hey, I wanna learn Kubernetes, but we don’t use Kubernetes here.” But if we don’t train somebody about Kubernetes, we may never use Kubernetes here, right?

Sean: Yes.

Jayne: So, it’s a little bit of a vicious cycle. And I love the term innovation hours, right? Innovation hours can have so many different flavors—almost like error budgets. Like, you get an innovation budget, right, that says, you know, you have X number of hours that—and again, innovation happens a lot of different ways. It could be hackathons, it could be simulations, it could be classes, it could be quiet training hours, kinda that silent disco approach. But there is a point where, as a manager, you have to make a decision whether—and I'll use your Kubernetes example—do we train X number of people on Kubernetes, or do we train two people who are then required to come back and say, “Here’s what I learned. Here’s what I think could help us. Should we take this to the next step, right? Should we go any further than that?” Now, those two people may leave because they're not putting Kubernetes on their résumé and on their LinkedIn and out the door they go, and there’s always the risk. That was always the risk, by the way. Organizations have always been very reluctant to invest in training, because I'm gonna train you and you're gonna pick up that training and go somewhere else.

Sam: Well, you've heard that expression right, where two people are talking and—

Sean: The CFO and the CEO.

Sam: - the CFO and the CEO and he says, “Well, what if I pay for this training and the people leave?” And the other person says, “Well, what if you don’t pay for the training and they all stay?” 

Jayne: Right, right.

Sam: Right?

Sean: Who was it that says if you think hiring a qualified candidate is hard, wait until you hire one that’s not, right? Or it’s expensive—yeah, hiring a qualified candidate is expensive. Wait until you hire one that’s not. They're exponentially more expensive.

Sam: Yes.

Jayne: And, you know, in today’s talent market, I think that’s really a risk. Years ago—again, I'm dating myself, but years ago, I worked for an organization where the CIO had you sign a piece of paper that, if they put you through certain programs, you couldn’t leave within two years or they tried to make you pay it back. And by the way, that was more common than you think. You're nodding your head, Sean, but it was more common than you think where they would invest a certain amount of training and you would actually be held accountable for the cost.

Sean: Right.

Damon: I've still seen that happen in degree programs. Like, we'll put you through a nights MBA or your Master’s or whatever and they do it as like a tuition deferment thing. So, it’s basically like—look, you sign up for it, and then we're gonna pay so much of your bill off each time, and then if you don’t, you're on the hook. Basically, it was a loan. You go to school, we'll give you a loan, right? And then we'll take so much out, and then every month you're here, we take so much off of this loan that we gave you.

Sam: Off of the loan, right.

Damon: It’s complicated, but you know—and I think that’s kinda the point of, there’s a difference between general education, which I think often gets, people get mistaken for.

Sean: Yes.

Damon: It’s like—oh, my option for learning on the job is go take a night school course in accounting or something like that, or I'm gonna do some Udemy kind of online things on nights and weekends. I think the people missed the fact that there was these kind of more project based different ways to think about becoming a learning organization—

Sam: Right.

Damon: - that aren’t traditional college curriculum or night school or—

Sean: Or online night school.

Sam: We talked about this just in the panel, right, where the person raised their hand and they said, “Well, how would we bake that into our process?” And the recommendation was, “Well, just add some hours to the sprint.” Like you said, if I wanna play with Istio or with Kubernetes, well, then add some time into the sprint to play with, if I have to use that technology, well, then, you have to learn how to use it, so add more time to that sprint, which is a normal—

Damon: There’s another kind of interesting trick that I've seen that comes out of the lean world. I'm sure you're familiar with the 5 S idea that’s like, clean your work station and these kinds of things. So, I've seen people do 5 S days once a month, maybe, or once every couple weeks—once a sprint, right? And the idea is, everybody gets together in the morning or agrees by email ahead of time, “Here’s a list of things.” And often it’s like, fixing the build, reorganizing the documentation, literally cleaning out my laptop or something like that. Everyone has these kind of ideas of stuff that’s been bugging us that, it’s like cleaning the friction out of our—

Sam: Right, spring cleaning.

Sean: Yeah, something like that.

Damon: And so, I've seen that 5 S kind of idea, the 5 S day, which feels like you can explain it better to the bosses. Like—look, we're taking a day out of every sprint for everybody, we're just blocking that time out to clean stuff up, to fix up the stuff that’s been bothering us. It’s good for morale, it’s good for friction. We're kinda cleaning up some process technical cultural debt that doesn’t require, you know, a whole other big thing to do. But then I've seen people then put training into that, right, or the research topics, right? Like—oh, well, I'm gonna go research the latest in the Cloud Native ecosystem and everyone goes, “Oh, that’s a good idea,” right? And that becomes their 5 S day project and they can, at the end of the day, they write a four or five-paragraph or a couple page email about what they learned, while somebody else was cleaning out the old builds or refactoring some test automation—

Sean: That’s cool.

Damon: - or, you know, fixing the coffee machine, I don't know, you know? Yeah, the 5 S.

Sam: Right.

Sean: That reminds me of the architect days where you have so many Visio diagrams on your desktop that after so long and you've been with the company for so long, you just create a folder that says New Desktop and then click all of ‘em and drop ‘em there and just wait for the desktop to fill up again.

Jayne: [Laughter] Old stuff—old stuff. I've done that. [Laughter]

Sam: Right. So, this has been a really fantastic conversation. If anybody has any final thoughts? I think, if not, I'll let Jayne—I'm sure Jayne has some final thoughts on the importance of upskilling.

Jayne: Yeah. So, you know, last year, when we launched this project with the support of then Electric Cloud and CloudBees, you know, it was a passion project, right? It still is. But it was a curiosity about what skills, right? So, we tell you you need to upskill—what skills, and how do you know? And so, really proud of the fact that this past year, we had great response to the initial survey. We're working with Eveline Oehrlich, who is a former, long-tenured Forrester analyst, now DevOps Institute’s chief research analyst. And the results were really, really impressive, and I encourage everybody to go and download the report from 2019. I think you'll find that the data is really, really interesting, whether you're CIO, whether you're a practitioner or anywhere in between the two. And on Monday, August 19th, we're gonna do it again, right? So, we're gonna open the survey again for the 2020 report so that we can do a comparison year over year and use 2019 as a benchmark. We're gonna leave the survey open for a long time. So, this last year, we did eight weeks. This year, we're opening it on August 19th, we're closing it on December 20th.

Sam: Oh, wow.

Jayne: So, we've decided that we really want, our goal is between 4,000 and 5,000 respondents. We had about 1,600 last year, so that was great. We had worldwide reach, so we had good samples from all over the world. But this is a service that we are very, very excited to provide to the community. We have amazing support from some pretty impressive organizations that are helping us be able to do this. So, please fill out the survey. It takes—this year’s survey, I did it this morning just as a pilot and it took me about 18 minutes to do. So, we cut it down from last year’s 30 minutes, so—

Sam: Did you get all the answers right? [Laughter]

Jayne: I don't know if I got all the answers right. [Laughter] But the questions are really great questions, and we're also looking at being able to slice and dice the data in a lot of different ways—diversity issues, regional issues, things like that. So, first of all, I wanna thank—

Sam: Fantastic source of knowledge, yeah.

Jayne: - yeah, I wanna thank everybody for their support, but I wanna thank you in advance if you're listening to please go ahead and just take a few minutes, encourage your colleagues to do it. It’s something that hopefully will benefit you as a human and it will also hopefully benefit enterprises all around the world.

Sam: Wonderful. Alright. Thank you, everybody, for joining us, and we'll see you next time on DevOps Radio.

Jayne: Thank you.

Helen: Thank you.

Damon: Thanks.

Sean: Perfect. Thank you.

Announcer: Like what you've heard today? Don’t miss out on our next episode. Subscribe to DevOps Radio on iTunes or visit our website at CloudBees.com. For more updates on DevOps Radio and industry buzz, follow CloudBees on Twitter, Facebook and LinkedIn.