Upskilling DevOps: Results from the Enterprise DevOps Skills Report – Jayne Groll, DevOps Institute

Me personally, as I said, I’ve been in IT a long time. I was a trainer. I’m a Scrum master. I’m an [inaudible 00:01:18] expert. Blah, blah, blah. I’m also the author of the Agile Service Management Guide. What that means is I’ve seen IT grow up pretty much not from its early days, I’m not that old. But pretty much from kind of the middle ages up until now, and it’s really been a fascinating journey watching from the 25 person IT department where everybody knew everybody else, to where we are today. And moving forward with digital transformation.

And hopefully, some of the results I’m going to share with you today resonate with where you are in your journey. And looking around, you’re probably in different stages of your journey, and that’s exciting. Sometimes the journey writes itself.

I’ll tell you a little bit about DevOps Institute. As I told you, we’re an open member based community. We’ve got knowledge reports. We’ve got events. We’ve just started a series called continuous learning minutes, which are what is in context by some key thought leaders. So if you want to know what [inaudible 00:02:15] is, or you want to know what other aspects or terms that you’re hearing in the DevOps space that maybe you’re not familiar with, this is an ongoing series. And we’ve really been very very blessed, with having some pretty well known influencers help us with that.

We have a framework called SKIL. Skills, knowledge, ideas and learning. Again, go up to the website. Learn a lot more about that. Become a member of this community. And I will tell you one thing about the community. So how many of you are based here in the Bay area? How many of you are based east coast? Anybody based east coast? I’m Florida, so I really am east coast. What about central? Anybody outside the country? Awesome, right? So I will tell you something. I get to travel all over the world, which is very exciting for me. But I found out in the DevOps community is regardless of where you are, the journey is the same. And sometimes, the challenges are the same.

And so, when we look at this as a very global community, you are a part of that whether you’re here in the United States, whether you’re international. Really, I’ve been to Asia. I’ve been to Europe. This year, we’re focusing a lot on Latin America. And people are people, right? And that’s going to help, I think, start the story of up skilling.

So has anybody ever read this book the Fifth Discipline? It’s really about becoming a learning organization. So this goes beyond certification. It goes beyond what you put on your resume. It is about becoming a continuous learner. And one of the things in the Fifth Discipline I think is really important is, in IT, sometimes we don’t see holes. We see holes, but we don’t see holes, right? We don’t see the end to end system. We’ve really grown IT up to just kind of focus on our part of it.

So software developers kind of focus on building software, and then they pass it downstream and it goes to ops. And then, once it’s post-production, it goes into a whole bunch of people that you’ve probably never met, and we don’t really look at the end to end system. And part of what we need today, and your first kind of guidance on up skilling is becoming a systems thinker. Really being able to see holes. If you kind of look at IT as a system of systems and how we’ve grown up, we’ve kind of built it like the United States of IT. Where we have different kind of aspects of the value stream or the pipeline or however you want to look at it. The software delivery life cycle. But each of those factions don’t really interact well, don’t even speak the same language as other parts of it.

So how many of you are developers? What about operations? Security? Okay, we don’t have security here, so we can talk about them. No, we really are going to talk about security. But if we start to look at developers and operations in particular, developers have been spending the last however many years focusing on agile software development. Right? Moving away from Waterfall to Agile. Anybody a Scrum master? Few of us, right? And so we kind of learned about, let’s do it iteratively and incrementally, and let’s operate in sprints. And let’s have nine or less, two pizza teams and all of that.

And we developed a set of ways we were practices, tools, vocabulary, that downstream the rest of IT didn’t understand. They saw the agile manifesto and everybody freaked out, because it basically said everything you do on the right hand side doesn’t matter. And of course, that wasn’t the intent of the agile manifesto, but that’s part of the interpretation.

So we have this kind of agile cycle within the development side, with its own vocabulary and its own tools. And then the product or the code that comes out of that, goes downstream, maybe to CICD. Right? I think a lot of organizations are committing the code, and then the code is being tested and built together. And it’s going down into some continuous delivery pipeline, and that’s a whole new set of people with their own tools and their vocabulary and their own processes. Maybe there’s a little [inaudible 00:06:24] in there. Anybody worked in an [inaudible 00:06:26] shop? Couple of you, right? We all love the cab?

But it kind of went downstream to this other kind of state, where they had their own processes and their own skills. And then it got deployed into production, either continuous deployment or continuous delivery, and now you have a whole set of post-production activities. Site reliability engineering, I’m starting to hear maybe a little bit about that. I know the next session after this is about that. That’s a bit of a passion project for me.

The problem is, we didn’t see holes. We saw holes, but we really didn’t see the entire system. And so part of the reason why we are where we are today, is because the system is broken because we are a system of systems. Does that make sense? All right. The system is broken because your part of the system may work really well, but you’re not interoperable with the rest of the system. Okay? So keep that in mind as we start to go further with this.

So if you’re going to be a systems thinker, have you heard of the concept of T-shaping [inaudible 00:07:33]? Anybody hearing about T-shaping? Companies are actively hiring T-shapers. I’m going to tell you really quickly what a T-shaped, or cone shaped professional actually is. So some of you raised your hand when I said who’s a developer or software engineer, and that’s the stem of your T. That’s your core competency. If you’re an operations person, perhaps you’re an automation architect, a build engineer, an infrastructure engineer, post-production, SRE. That’s the stem of your T. That’s your deep knowledge.

It’s probably how you identify yourself, personally, professionally and on your resume. That’s the stem. And we grew IT up based on stems. We grew IT up, and it’s our fault, really. Because we started to hire these clusters of like-skilled people with their own vocabulary and their own ways of working and their own whatever. And we said, “You are a,” and fill in the blank. That’s the stem of your T.

Well today, it’s not enough. Today, you have to become multidimensional. And so you need to think about, what do I fill the top of my T with? So grooming your core competency is still part of your mission, but it’s not your only mission. The T-shaped professional has a broad base of skills. Not expertise. A broad base of skills in a lot of different areas. And so I’ll give you an example that I use frequently. My daughter’s an artist. Anybody an artist here? Okay. So as an artist, what medium do you work in? What would you say your core though, do you have a core area that’s?

Drawing.

Okay, drawing. My daughter’s a painter. But she will tell you she needs to know enough about metal, fabric, right? Clay, in order to bring her art alive. She is a T-shaped artist. She’s still a painter by trade. Well, by hobby probably more than that. But someday by trade. But she still is, the stem of her T, is her ability to do fantastic painting. But she will make it much more multidimensional and interesting by learning a lot about other mediums. But not necessarily expertise. Does that make sense?

So, as we go through this, I want you to think about, what do you need to do to fill the top of your T? Because you probably know what your stem is. Now, if you go a little further, sometimes we talk about cone shape, pie shape, broom shape, which means you have two or more stems. So you develop enough expertise in a second or third discipline to actually consider it deep knowledge. For today, I don’t want you to think about that. The over achievers in the room, don’t do that.

Really start thinking about your stem, your deep competency. And what do you want to do to fill the top of your T? And I’m going to give you some ideas from the report on some of the areas that absolutely emerged as being critical. Some of which you’ll expect, and some of which you may be a little surprised about.

So in 2018, the DevOps Institute fielded a global research. We opened up this survey. About 1600 people across the world filled out a 30 minute survey. So it’s pretty detailed. The new survey is going to launch in August. So if you do see that, I would encourage you to take the time because the data is really really rich. So we had about 1600 people fill it out. Interestingly enough, it’s spread fairly wide across the world. Some regions more than others. United States and Europe were the top regions. We had pretty healthy representation from Australia and India. Not so much in China.

But again, we had enough. The research analyst that was the chief research analyst, Evelyn [Orlick 00:11:22], who used to be with Forrester, said, “The number of the correct sample is at least 39.” I can’t tell you why 39, but 39 is enough of a sample to be able to dig deep into a particular topic. So we found that if you looked at the 1600 individuals, half of them were developers, half of them were operations. Self-identified. So we asked them what they thought their role was. Like I just asked you, and half were developers and half were operation.

Couldn’t have paid them to say that. The other thing is, 61% came from organizations over 500 employees. So that was interesting as well. About 22% came from organizations over 20,000 employees. So we felt like we got a pretty good sample of enterprise in terms of what they considered to be must have, nice to have, not important. The split on the management side was about 22, 24% were VP, director, manager. So hiring people, people that actually do the hiring. About 6% were the C-suite. And then the rest were practitioners.

So again, we felt like we had for a first round, a pretty good sampling of global different layers of perspective, and certainly from the enterprise. And I want you to think about that as we go through this. How many of you work for organizations over 500 people? Okay, so most of you. How many work with an organization over 10,000 people? A few of you. 20,000? Yeah. So you understand, the perspective may be a little bit different, but interestingly enough, it didn’t actually turn out to be remarkably different.

So key takeaways. First of all, we asked the respondents about which skills they would consider must have, nice to have, and not important. Now, not important doesn’t mean that it’s completely dismissed. But it means that in terms of looking for talent, in terms of what they’re really instilling in their employees, it was the least important. On the must have side, this is really fascinating. Nobody is surprised that statistically, automation was a pretty high number. Process skills, being able to have the intelligent processing that sits under automation.

But look at soft skills. By the way, soft skills are hard. Right? So we’re now trying to really coin the term human skills. Yes?

How have you defined soft skills?

Hold that thought, because I’m going to show you a lot more detail about soft skills. So we’re actually now moving more towards the term human skills. Because as I said, soft skills are kind of hard. Automation absolutely makes DevOps a success, but you had to have a process for intelligent automation. So being able to really underpin your tools with a kind of consistent and stable process made a lot of sense as well.

Soft skills and technical skills came out equally important, which is fantastic because many IT practitioners think that you’ll grow your career, specifically on your technical capabilities. And what the report was telling us was your ability to interact with other humans, is also a defining factor. Operations and security came out as key functional skills. I’ll show you the data, a little bit of the granular data in a bit. But really fantastic to see that operations, even though we talk about no ops. No ops. No job, no respect. We’ve got a new term new ops, that we’ve been really floating around.

But that operations and security absolutely are key functional skills for everybody, regardless of your role. Business skills are important to leaders. Vertical skills were a plus. So understanding healthcare or manufacturing or finance was important to the leaders, but not necessarily a critical factor. 37% are actively hiring. If you heard [Shlomi 00:15:17] this morning, he said 50,000 DevOps jobs on LinkedIn. That’s remarkable. And that’s just LinkedIn. Go to Indeed or any of the others.

But here’s the other interesting takeaway. Hiring from within was the most predominant thinking. So while we know there are 50,000 jobs out there, the respondents particularly at the management layer, want to improve the skills of existing staff. So that’s a commitment to all of you, and I think that’s really fantastic.

When you looked at the jobs that were being hired, DevOps engineer, that mythical creature that nobody can really define. Now everybody, the last month, everybody was talking about full stack engineer. Boy, talk about unicorns. But again, the DevOps engineer, whether we like it or not, is a role that’s being hired. Also, DevOps managers, DevOps coaches. People that have experience in successful DevOps are certainly in need. But look at the next few. Software engineer, DevOps consultant, and then number for is test engineer.

Now I want you to think a lot about test engineering. How many of you are, is anybody QA? Okay, how many of you feel you have at least a modicum of testing capabilities? Good. The rest of you need it. Because I would tell you that if I had to pick one skill that you all need to add to the top of your T, basic testing skills. Right? So the day of passing testing downstream is going away. Everything is shifting left, and you don’t have to be a QA engineer, but if you’re a developer. Test driven development, highly in demand. If you’re an operations person, infrastructure’s code has to be tested. Security has to be tested.

So you do need to have a basic level of testing skills. Again, you don’t have to be an expert, unless that’s a passion for you, but you do need to have basic skills. Automation architect, infrastructure, CICD, release engineer and manager. I think that one is fascinating. Anybody a release manager? All right. You’re in a great place because that is a very highly coveted job. Site reliability engineer is showing up. So 10% said they were actively hiring site reliability engineers. I spent a lot of time in that space, and I would tell you that next year we’re going to see a big, big, big leap on that.

So here’s some other interesting pieces of the report. So, look at the C-suite versus the management versus the individual contributor. So they were pretty equal in terms of their belief that process, skills and knowledge was important. So statistically, it came out just about the same. Look at automation skills. Now, you can define automation skills, and I’ll drill a little bit into that. 71% of the C-suite said, must have automation skills. 58%, by the way, that’s the hiring layer. Those are the hiring managers. Because the C-suite very rarely hires beyond direct reports. They may approve what’s going to happen, but it’s really that middle layer that’s going to actually do the hiring.

But the management layer and the individual contributor were pretty much in agreement about automation skills. But the C-suite absolutely went a little bit higher. Specific automation tools you can see, important but not high up on the list. Same thing with business skills, C-suite thought it was must have. Individual contributors less so. And then, look at soft. So 69% of the C-suite said absolutely must have good soft skills. Spelled no drama. No drama. The management layer obviously is hiring for human skills, your ability to be a good collaborator a good problem solver. The individual contributor I think, is confused.

Because as this lady said, we don’t know what a soft skills is. So could you be a better friend, a better collaborator? Could you bring me coffee? What is soft skills? How do you groom it? How do you grow it? How do you get better at it? And I think that’s really unclear. And we don’t necessarily train for it.

So let’s look at process skills. So really kind of interesting. Software development lifecycle number one process skill, regardless of your role. So if you’re an operations person, you need to understand basic SDLC, not a specific framework or approach. But you need to understand how software is built and delivered. So that came up number one. Process flow. If you know anything about DevOps, the first way of Gene Kim’s Phoenix project is flow. Remove constraints and improve your flow.

Number two process skill, you have to be able to analyze flow and identify where there are constraints. Could be a value stream. Anybody ever done a value stream map? Fantastic exercise right? It isn’t so much that you’re going to build a flowchart of your activities, you’re going to figure out the time between each activity. So where you look at your flow may not be the activity itself, it may actually be the time between the activities. And that’s really, really interesting.

Then you go into agile testing, there’s testing again. Systems thinking. But I want you to focus on this just a little bit differently. If you look at the upper half of the must have skills, they are not framework specific. How you groom your process flow and analysis, your systems thinking, those are critical skills. And by the way, those are skills that mostly at least today, only humans can do. All right? Understanding the software development lifecycle. Being a good systems thinker.

The lower half, while still important, please don’t misunderstand my message. The lower half really started to map to very, very specific frameworks like ITIL or scrum. Or project management or program management. So I think what the respondents were telling us is, first of all, groom your critical thinking skills. And then use the available guidance. I don’t like the word best practice, but use the available guidance to be able to help you grow that. But don’t be married to the guidance. Sometimes, the guidance becomes a little religious.

I come from the ITIL space. It’s really, you know, you have to sing a hymn before you open the books. So you don’t want to do that. But you do want to groom your critical thinking skills. And some of that’s through mentoring. Some of that is through practicing. Some of that is through education. There’s lots of resources out there for you to become a better systems thinker, or for you to understand the basic concepts of the software development lifecycle.

If we look at soft skills, and that’s the answer your question. Now, some of it’s going to feel like, okay I get that. I have to be a better collaborator. Or I have to have better interpersonal skills. Problem solving. There are some really good techniques for problem solving. A lot of organizations use the scientific method, where you come up with a series of hypotheses, and then little by little you work your way through those hypotheses, until you find the root cause of your problem. Some of it is really, willingness. So, we don’t want you to hold back your knowledge. We want you to be able to share your knowledge.

I mentioned site reliability engineers. Is anybody here an SRE? Okay. So SREs are tasked with really working with and sharing knowledge with members of the team. It is a part of your mantra, correct? So who do you work for?

Pinterest?

Who?

Pinterest.

Okay. So Pinterest. Perfect example. So as an SRE for Pinterest, you’re not kind of carved off to a separate team right?

No we have embedded and core.

Okay. So you have embedded and core. So when you’re embedded, you’re in a very, very active… I’ll show you what I know and you show me what you know, right? Okay. That’s one person in this room. Now I don’t know about the rest of you and how you’re sharing knowledge. But it has to be an intentional act. And if you need something like SRE to tell you you should share your knowledge, that’s okay. But it is starting to evolve into different roles.

Again, flexibility, adaptability, personal value, creativity, all of that’s good. But kind of look at customer experience skills. How many of you think you have a competency in customer experience? Not everybody though, right? How did you get there? How did you groom your, because you’ve been asking so many… how did you groom your customer experience skills?

I started in tech support, and from day one in tech. I took up the phone and heard what people’s problems were, and figure out how to solve those problems. And then you sort of develop a way of talking to people that gets them to give you what you need more quickly. But also is empathetic to what’s going on, so they understand you’re there to help them.

All right. Somebody else said customer experience skills.

I come from a software development background. I moved into escalations team, where we directly work with the customer. And giving remedial patches and fixes. So we used to sit with customer calls for hours together to understand what the issue is, and try to see if we can fix it in a short amount of time.

Yeah, sometimes we have to ask the customers what they want. And that’s scary because they actually might answer. Right? I mentioned SRE. Google now has CRE. Customer reliability engineering. So it is definitely a hot area. I don’t know that there’s a lot of knowledge yet. I know an organization that’s starting to introduce XLAs as opposed to SLAs. Right, customer experience level agreements as opposed to, and that can show up in transaction, completed transaction. There’s lots of way to look at the experience.

But it is important. If you kind of work your way down, I thought diplomacy was an interesting one. 38% said it was must have. And 53% said, yeah nice to have. But again, if you look at this, some of this is there are really good methods, if you want to use the word method, practices for managing conflict, for being a better collaborator. Do you know the difference between communication and collaboration? Somebody tell me the difference. What’s the difference?

One’s interactive.

Sorry?

One is interactive?

One is interactive. How is it interactive though?

Iterative.

One is passive, right? One, communication, I tell you, you tell me. I tell you again, you tell me again. In collaboration, I ask your opinion. So really, really big difference between communication and collaboration. So being comfortable asking somebody, what do you think? I’m a little bit of a know-it-all sometimes. Really, seriously self confession. And sometimes I have to stop and go, “What do you think?” Not what I’m telling you to think. It’s a very big difference.

So really, this is a key area that I think that we have not put enough emphasis on. And we certainly haven’t put enough education on. Moving along on functional skills. Again, remember half were developers, half were operations. Look at the first two functional skills. Remember SDLC was the number one process. IT operations, infrastructure, security came up as the top three functional practices. Which means if you don’t have a basic understanding of operations, infrastructure, and security, that’s an area that you should focus on.

Again, you don’t have to become a deep expert. But if you’re hearing about DevSecOps, DevSecOps means security is everybody. Shlomi said it this morning when he said, “As a developer, you no longer build it. You have to know how to release. You have to know how to secure it.” So again, like testing, everybody has to have a core set of knowledge around security. It is no longer somebody else’s probably. Everybody get that?

Top of your T, security and testing. I think is important. I also think for infrastructure folks, if you don’t know how to code. And again, I come from a long operations. Somebody else coded. Basic coding skills I think is something that everybody has to have at least a core level of understanding about it. Testing is showing up again. Testing and QA. Starting to look at network knowledge. Funny enough, look at that. A few years ago, network knowledge would have been much higher must have. Now it’s a lot lower.

I think the most interesting one is the bottom. Governance, risk and audit. Nice to have. Not a must have. Now, if you come from a regulated environment, that’s probably a little bit of a flip. Right? But interestingly enough, of the people that responded to it, GRC is moving to being able to automate GRC. So we could build it into testing tools. We can get the evidence. That way, there’s some really great case studies around it. But it’s not a must have skill. I would tell you, ten years ago, that would not have been the case.

So that’s also an interesting message. The shelf life of your skills is starting to expire faster than ever before. Now that may be a little bit distressing, but it is hopefully also encouraging. You work in an environment, regardless of who you work for. As an industry, you are required to continually grow your skills. How you did it two years ago, three years ago, probably carry that with you. But you’ll have to build on top of that.

So where else do you get a job that really, you are now required, you get budget for, you get the opportunity to come to conferences like this. There’s five conferences a week now. Where else do you have that type of encouragement to grow? As opposed to other areas that maybe aren’t as rapid in the acceleration of their skills? So hopefully, you take a little bit of that away as well.

So technical is really interesting. So cloud, cloud, cloud, cloud, cloud. How many of you are operating in the cloud? Hybrid? Right? So again, as we heard today, and AWS said it at Reinvent, hybrid is here to stay. So, a couple years ago it was everything needs to move to the cloud. You will be in the cloud. And everyone thought the cloud was free. And they found out the cloud wasn’t free. Right in fact, the cloud wasn’t necessarily a whole lot less expensive. It offers a different set of capabilities. But on premise is not going away. And so many of the providers are adapting to the hybrid approach, which I think is great.

My husband works for a Native American tribe. He’s not Native American. But because they are a sovereign nation, and they have certain areas of the country that are specifically their reservations, they cannot have their data hosted outside tribal land. Now, some countries feel that way too. That’s a whole different set of problems. So they will be on prem, as long as they can possibly be on prem, because again, they have different restrictions.

So the industry has finally recognized that. So while cloud is important, I think everybody has to have cloud knowledge. How you apply that in a hybrid environment, I think is going to be what we see next year. I think next year, we’re going to see the marriage of on prem and cloud being a very, very key skill. What do you guys think about that? It’s not going to be, O Ye, abandon your data center. I think it’s going to be, we have to look at this evolution a little bit more slowly.

Analytical knowledge rose up as a technical skill. So the ability to do analytics, the ability to look at data very much a technical skill. If you are not comfortable or confident in your analytic skill, I would think that’s an area to add to the top of your T as well. At least basic analytics. I know we’re all moving to machine learning and we’re all excited about that and that’s great, but I do think that the human aspect of being analytical. Being able to really parse data out is important.

UI, web, and middle tier services. I thought this was pretty fascinating too. Because only 27% said that’s a must have. And I would tell you probably five years ago, that would have been much, much higher. Still a pretty healthy nice to have. Not as much as a not important. But maybe we’ve conquered that. Maybe a lot of what we have done is we’ve conquered, maybe not all of it, but more of it.

Specific framework knowledge again, 22% said must have. Again, really healthy nice to have. Same thing with mobility. Look at big data though. So everybody’s talking about big data. Only what? 17% said must have. Again, very healthy nice to have. Next year it’ll be interesting again to see if there’s growth in that area. Same thing with AI. I don’t think there’s enough knowledge or experience with AI for the hiring managers to say this is a must have. Again, as we start to go forward, I think maybe we’ll see a little bit more of that.

UX design, artificial intelligence I just addressed. And the mainframe. The mainframe’s not dead. Anybody operating in a mainframe environment still? They’re out there. There are companies that are actively really interested. Compuware is really still, very heavily invested in mainframe. Broadcom just bought CA. They’re really investing in their mainframe business. So I don’t think the mainframe is dead. Or as Nicole said this morning, you can still do DevOps in a mainframe environment, it’s just a little harder.

Look at the skill though. You can definitely tell there’s a very healthy number of participants that said, not us. We’re not there. So, just to kind of wrap up. A couple of conclusions. Fill the top of your T. Now I can’t tell you individually, what the top of your T will be. And I will be in the speaker discussion on this. Is that right, Vivek? After this, so if you have individual questions, please feel free to meet me there. I can’t tell you how to fill the top of your T because I don’t know what you do on a day to day basis.

But I can tell you that this survey produced a lot of really interesting data. First of all, polish your soft skills. Polish your humans skills. What does that mean? That means on a regular basis, practice intentionally, asking people’s opinions, being a better collaborator. Maybe it’s not your comfort zone. And there are really good techniques. There are some instruments you can actually measure. Because I would tell you, as much as it’s important to know how you communicate, it’s equally important for you to know how your colleagues communicate.

So has anybody ever done a Myers-Briggs? They say Myers-Briggs, if you did it when you were five and when you did it when you were 50, it would come out pretty close. It’s how you’re wired. Some organizations still do Myers-Briggs. Does anybody not know what Myers-Briggs is? It’s a personality assessment. So it basically breaks you down into four different categories of how you’re wired. Your basic personality. So for example, it’ll define whether you’re an introvert or an extrovert. Now, you probably can tell I’m an extrovert. Not because I speak and I’m friendly, it’s because you’re all going to walk out of this room really tired, because I charged my batteries from you. So I charge my batteries around other people.

Introverts go off to a room by themselves, and charge their batteries by themselves. So it has nothing to do with whether you’re friendly, outgoing, all of that. So knowing that I’m an extrovert, means that I have to be around people. But if I know that you’re an introvert, I have to respect that as well. So there are different ways and methods. You can go to YouTube. There’s really nice little short videos about how to be a better collaborator. But it isn’t just, let’s go have a beer together.

There are some intentional ways. So take away that know yourself, but also know who you work with as well. Functional and technical skills are important, they’re not enough. Polish your key soft skills every day. Here’s the interesting thing. Hone your functional knowledge. So if you’re a software engineer, and you only know agile or waterfall or whatever custom proprietary approach your organization uses, spend some time with somebody that is not in your wheelhouse. Understand that your functional skills have to cross the entire system. So you need to know, again, just enough of operations. Just enough of testing. Just enough of security, because not only will you help your organization, you become highly desirable talent.

So full stack doesn’t necessarily just mean, I can do every single technology out there. Full stack means I also understand the entire system. So hone your functional skills on a regular basis. Automation means you have to understand what, when and how, to automate, to add value. So it isn’t automation for automation’s sake. I think that’s important as well. Companies are cultivating their DevOps team from within, so your chance is now. And so, depending on who you work for, if you work for a classic, traditional enterprise, your organization is trying to figure out how to make DevOps work.

And it doesn’t matter what DevOps is. Everybody’s going what is DevOps? Who cares? The reality is, who cares? Is it a movement? Is it a framework? Is it a philosophy? I’m going to tell you my interpretation, it’s new IT. DevOps doesn’t pretend to be better than anything else you’ve done in the past, it’s the glue. It’s new IT. So if you’re in IT, you are part of DevOps, and your organization is trying to figure it out.

So you get an opportunity to contribute to that success. Partially because they’ll help you do it, and partially because you have to do it on your own. And if this report tells you anything. And it’s a very deep report. I’ll show you the link in a little bit. It’s 48 pages. So if you’re bored, you can’t sleep at night, or whatever. Or you want to spend some time with your team, really looking at what skills do we think we have? What skills do we think we’re missing? And what skills do we think we need? That will help you out as well.

At the end of the day, if you come away from today with anything, become T-shaped. If you’re not already. Do a skills assessment, a personal skills inventory. Take a look at some of this data. Talk to your colleagues, talk to your boss. But start a plan to become T-shaped. And once you become T-shaped, if you want to become a pie shape that’s two, you want to become a cone, broom or E. There’s different terms for how many more do you want to add to it, that’s great. But start the journey off by looking at the top of your T, before you decide you want to be experts in six different things.

It is more important that you are cross functional to be able to contribute to your team. So on that, I appreciate your time. You are welcome to download the full report. As I said, it’s 48 pages, so there’s a lot of lot of data in there. We are going to launch the survey again, in August, so please share within your organization. The more people that we get to fill it out, the more data we’ll be able to share next February when we release. This is going to be over a year report.

So Nicole talked about Accelerate. Accelerate really looks at organizations. Up skilling looks more at the humans at DevOps. Okay, and I just want to leave you again. If you’re not a member of DevOps Institute, as I said, it’s free. We’re not going to hit you up for money, I promise you. We’re adding more and more capabilities, to kind of bring people together. Our mission is really to advance the humans at DevOps. So I encourage you to do that.

Okay I thank you very much. I hope you have a great rest of the conference. I’ll be in the speaker area. And please, fill out the session feedback for me.

(silence)