Paula Thrasher

I am Paula Thrasher. I work for the Digital Innovation Center. That's actually a new role for me. I started two weeks ago. We recently won a very large piece of work. We're going to do some great DevOps transformation, and I'm really excited to get started on that.

But if you all have not heard of CSRA, a quick recap: that's because we're two years old. In 2015, we were formed through the merger of CSC's federal division and SRA. We are a large federal contractor. We serve exclusively the federal market, and you saw a lot of folks, Northrop and Lockheed, talking this morning with airplanes and bombs and stuff. We don't do any of that. We do nothing but IT. So we're a pure-play provider. We're about $5.5 billion in revenue and about 20,000 employees. A little bit less than that, but close.

And there's my Twitter handle if you want to tweet me, or if you want to make my corporate marketing team happy, you can at them too.

Today, I want to talk about how you scale DevOps talent. I assume if you're in this room, you work for a large enterprise or at least a biggish group, and you're not just ten folks in a startup. You've actually got to deal with scale. And you're probably in a place where you've got a small pocket of DevOps goodness. And if not, you are the first, and now you've got to figure out how to bring this great idea to the large organization.

That's kind of where we found ourselves. As I mentioned, we're close to 20,000 employees. So it's not enough that we've got 200 awesome people. We've got to figure out how to make 20,000 awesome people. And then by extension, our customer is the federal government, and they're even more enormous, in the millions of people, and we're trying to bring that transformation to them as well through that experience.

If you're any organization of any size, in the consultant world, we talk about pyramids and leverage models. But you've got multiple people, multiple players across your organization, all the way from the top, the executives, all the way down to the practitioners. And then, of course, you've got the pipeline of people coming into your organization.

And while you might recruit people in the middle of all these layers, demographic destiny says that we have to hire people from college because, quite frankly, I'm Gen X. We're small, but the millennials and Gen Z behind them are huge. And so, by necessity, we have to build people along their careers in order to have people that are going to work for us for the next 40 years.

If you think about that, you can't just run a single thing that you're going to train everybody on DevOps, because everybody's got different things in the organization that we have to talk about.

So at the top: how to be a change agent. I get to cheat. Steve Mayner just stood up this morning and told you exactly how he did that, so I'm going to skip that part. If you didn't hear his talk at the plenary, go listen to that. That's how we focused at our executives.

So I'm going to talk about the bottom part, which is the middle managers and the practitioners on your teams doing the work every day. How do you help them be the best DevOps team they can be, whether you've moved all the way to that cross-functional team or whether you're still kind of living in a certain amount of specialty-type organizations? And that happens because you're big. Not everybody can be a cross-functional team, to Damon's talk earlier just now.

And then as well, how on that technical side of that team, and even to the management, how you bring that T-shaped skills, if you've heard that term. The idea is you have a specialty. Maybe you're a networks engineer, but you need to learn how to code. You need to learn infrastructure. You need to learn how developers work. You need to learn the business. So you've got to build some skills broadly while still maintaining your specialty.

How do you help people in their career keep their specialty but also grow that horizontal skill set? Again, because you're going to be cross-functional, you're going to be collaborative, and if you want to do DevOps, you've got to have at least some sympathy for the other people.

And then last as well, the technical expertise. And this particularly for us is how we start people on their journey to build that depth. The T-shaped talent assumes you have the expertise in the first place. We just mentioned, I hire a lot of college students. We all know, since we're technologists, that you can't learn this in four years. That's the beginning, and now your apprenticeship starts, and now you've got to learn all the real skills.

So how do we get people that expertise in the first place before they're ready to become that T-shaped person?

The first part is about the teams. One of the things that we did around the teams, we've done this in a couple different contexts, but the one specifically about the team leads is that we have, I'm sure you have this too, computer-based training. We have classes. We have all of those things. I'm sure you already have all those things. They're fabulous. But does your team go to that class and bring that home with them? No.

So how do we get people to actually take the things they were learning in the classes and bring it to their team? Secondly, I don't want every team to do it differently. Ideally, I want teams to share best practices. So how do we get teams to talk to each other about what's working on their team and how they can make each other better?

So that became the cohort. What we did was we formed a group of folks. We did it totally volunteer. We said, "If you're interested in this, please sign up."

We spammed everyone that was a team lead, scrum master, project manager, tech lead. We did limit it to that role. You had to be a lead on the team. We weren't at this point aiming at the practitioners. We were aiming at the leaders. And we said, "Anyone who's interested, sign up."

And we said, "Oh, by the way, you have to commit. If you sign up, you have to commit to do an hour of homework a week and an hour of discussion a week." That's what we ask, and that your team is counting on you, so don't sign up if you're going to flake out on them. Don't be that group project person.

And so we ended up with eight teams. I would say it was about five per team. It actually ranged between five and seven people per team. We organized the team purposely to cross-pollinate because, again, the point was to get them to share ideas. We tried to arrange it so it wasn't all project managers on one team. We tried to have it kind of cross-pollinated.

We had the ops people on the team, the network leads, the system administration leads, people leading those kinds of teams, versus people in development, traditional, that kind of stuff.

And we also paired every team, basically, with a coach. Every team had a coach that was part of their discussion. Not the homework part. The coaches knew the homework but could help in the discussion and sort of encourage and facilitate that conversation, and be available.

And we did have some geographic diversity. We're a large organization. We're all over the country. Actually, we're all over the world. So by having diverse teams, the one thing we said is we set the teams up on the meeting time, because whatever that was, that meant that no matter where you were, you at least agreed to the meeting time.

What we were trying to accomplish in this was asking people to go deeper, deeper than what you learned in the class, deeper than what you learned. We wanted people to really challenge themselves of how it was really working in their organization. And by proxy, we wanted them to understand how they could motivate their teams and be transformation agents at their level as a practitioner.

We have a collaborative group. We call it Chatter. That's our little chat thing in our company. And so we created a Chatter site for our team. What that allowed was that teams could post and have conversations, and I fuzzed it out to be anonymous.

We had teams share what they learned in their discussion. Not only did we have that little seven-person team discussing the topic of the week, and it was the same topic for everybody. For that week, here's your homework. Go read this, go watch this. We had them watch some DevOps talks. We had them read excerpts from articles. We had them read things like that. And then we asked them a series of questions.

And then in some cases, we had multiple things: pick one. Just pick one thing and read it and bring it back. Towards the latter half of the training class, we actually had them do things. One of the things we had them do was take the stuff that you've learned about limiting work in progress and look at your board. Are you limiting work in progress? Why not? And talk about that.

And so teams shared that kind of stuff. They shared that on the collaborative thing. So even though they were geographically dispersed, we represented seven different time zones in this training cohort. The fact that they had the site meant that even if they weren't that team, they could still cross-share ideas.

That was a valuable way to not just keep it to that five people, but actually build a community. What's been really nice about that is, out of that first cohort, they wanted to keep the chat group going. They're still going. So we thought this was just a 12-week program, but they run it themselves, and they take turns providing an article that they find interesting, and now all 75 of them or so talk about that article.

So they've built one little community of 75. We repeat this every quarter, basically, asking for new volunteers. This is our third cohort. What's great about this is that we're building this one community at a time, 75 people. But again, that's 75 people who are now leading teams of other people, and that is encouraging this adoption model.

And I think while we have a community of interest, I'm sure you probably have a community of interest, we have that too, but the engagement model of this is much better, because people really do.

The other thing we do really in that, and I think a big focus of that particular cohort, what did we talk about? A lot of what we talked about was adopting visual management systems, about Lean, about systems thinking, and all that kind of stuff.

If I could have a shameless plug, if there is one thing you could teach your practitioners to do, it's just use a visual management system. So to that initiative, that cohort that I just showed you, their next project is the book club. They're going to read this and talk about that. They are really excited about that.

The other thing we did for the technical teams, these are for the actual hands-on practitioners. That's great for the leadership to go read stuff and watch stuff, but the practitioners don't really want to read stuff and watch stuff. Plus, they want to learn tech things.

Like a lot of companies, we have training programs to learn things: go learn Amazon, go learn Red Hat, go learn Microsoft, go learn Jenkins, go be a Jenkins certified engineer, all of those things. Those are great, but we want you to learn how to be a DevOps team. We don't just want you to learn how to spin up an instance in the cloud, and we don't want you to learn just how to be a CI/CD pipeline or any of those things.

We want you to learn, and then we want you to practice working on a cross-functional team, bringing what you learned to that experience. And so that led to the hackathon.

We set our hackathons up as a training experience that culminates in a hackathon. You signed up, again, volunteered, probably had to kind of get your boss's permission because you'd be gone for two days. There was ten weeks of training beforehand, self-directed. Some people did all of it for all of the things that were getting covered in the hackathon, and other people just picked a track, and some people said they would and then kind of showed up to the hackathon without really doing the training. You can guess how that went.

But the great thing about this was the teams really got to practice. On the day of the hackathon, teams show up. They start. We give them challenges. Challenges like build a server at Amazon, build a server in Azure, log the server, manage the servers, that sort of stuff. You get points for everything you do.

And then there would be a series of security challenges and infrastructure challenges and testing challenges and so on and so forth, designed to let you practice with whatever the tech was associated with that hackathon.

As an example of that, as you completed those things, you got points. And you can see in the small picture there, the little chart, that's an example of the score sheet. That's probably the middle of day two. That's how everyone's doing. So you can see in real time how you're doing against your teams.

And this was a great collaboration. It was done with our Homeland Security group, started it. The CTO group there was the first group that started it. We collaborated with our vendor partners, and then we also worked with our Cyber Institute, which is based in our Defense Group, and they deliver security training focused on cybersecurity. But they extended the platform. That's that little thing that gives you the chart. They extended the platform that they built for cyber events to be used for this hackathon thing.

So having a group of people that knows how to train involved was very helpful in terms of building this.

And then the last thing we did was, in addition to all the things you could get points for during the hackathon, at the very end, we asked everyone, we gave them an hour to put together a presentation, and then tell us at the end, "You have five minutes. Tell us what you learned." And so you could get an extra bonus point at the end if you told us something really insightful, because we wanted to give people a chance that even if you really blew it on the hackathon, you could still get some bonus points for having learned something.

I'm going to actually go back to that real quick. Two great points that I loved out of the hackathons. We've done two. We've got a third one coming up in January. Two of the great comments that I loved out of the hackathon debrief, that little five-minute thing at the end.

The first one was a UX engineer. This was our Amazon-focused one. I'm sorry, it was the Microsoft one. She said, "You know, I'm a UX human factors person. I don't program. I don't build servers. But I learned how to build a SQL Server in Azure, and during this hackathon, I built a SQL Server in ten minutes, and I think that's pretty cool."

I guarantee you she's not going to go back to her day job and build SQL Servers. But it's awesome that she knows how, because she's going to work with a team of people, and they're going to do it. And that was exactly what we wanted to get out of the hackathon.

But the same thing in the second hackathon, we had somebody who is part of a disaster recovery team say, "It was really awesome for me to actually experience working with a team when we were getting hacked and understand what it felt like for everyone else on the team. Now, when I'm thinking about my disaster recovery plans, I'm not just thinking about how the infrastructure is failing over. I'm going to think about how the people do it, too."

So those are exactly the kind of insights we wanted people to get out of the event, which is why we continue to invest in it, because this is the one thing we do that actually does cost us a lot of money. We're taking people out of their jobs. By the way, in consulting, that means billable hours, so you're not billing. That's a double hit. But it's worth it because of those kinds of insights and building that kind of capability in the organization.

The other thing is that, as mentioned, the Cyber Institute that we collaborate with, we do this in the cybersecurity space as well. And we partner with universities, and we do something called Cyber Storm, and it's the same kind of idea as the hackathon. This is a one-day event. It's students, and the object of this is to keep your systems up and take the other systems down. It's a very security-centric one. And it is an active sort of red team, blue team. There is a team going around actively trying to hack you during the event, in addition to participants hacking each other. It's pretty aggressive.

But what's nice about it is that folks that are training in cybersecurity actually get to practice real world, because let's be honest, I don't know if you've ever walked into your SOC, it's kind of a scary place. We're being hacked all the time. And so being able to practice not just building security controls, but practice defending is the talent that we need in the future in the world of security.

So that really gets to the premise of what we're trying to accomplish in building our talent, which is that I'm actually training people before I hire them.

And to talk a little more about that university thing, we have a large center in Louisiana. It's in Bossier City, which is Shreveport-Bossier, North Louisiana. And we have over 600 employees. I actually don't even know the count, but it's quite large there. And we have a partnership with the state of Louisiana where we're partnering with the universities in the area. And so the majority of the people we hire, of course, from that area, come from one of these universities.

And so we've worked with them to actually change their curriculum to build the skills that we need for the next generational workforce. This is a center where we have software developers, systems engineers, help desk people, network engineers, cloud engineers. It's purposely a cross-functional center for us.

And we've done things with Louisiana Tech, Northwestern, Grambling, and Bossier Parish Community College, a diversity of university partners.

When we first started this three years ago, they were teaching in their computer science curriculum transistors. Anyone use transistors? Yeah. It just doesn't come up. Okay. Right. So maybe if you're actually building Internet of Things or embedded systems, but that's not the computer science department, that's the computer engineering department. You probably don't need that in comp sci, right?

And by the same token, Bossier Parish Community College was teaching C++. I learned C++. Anyone still writing C++? All right. Okay. So the ratio there is not the highest-impact skill you can have, right? So by changing what they're teaching, that's helping us get better talent.

I'm really excited that with Bossier Parish Community College, we basically created one of the first DevOps degrees. So they've created a track where we're teaching people skills for DevOps to include systems thinking and some of the other technologies that you use.

I'm also excited that at Louisiana Tech, if you are a junior or senior studying computer science, you use our DevOps pipeline, which is based on open source products. It's got GitLab. It's got Jenkins. It's got Nexus. It's got a whole bunch of other stuff. That's what you use in your class.

So when I hire you, not only do you know source control, huge bonus, you know Git. You know Jenkins. It's not the first time you've seen any of that. Which doesn't sound radical, but it's amazing when I hire a computer science major and they show up on the first day of work and they've never used source control. That has to change. We have to change the universities to make that better.

So the idea is train before we get them, and then we put them in that existing DevOps team, cross-functional, with a really specific type of senior engineer working with those recent college hires. We selected people who are good mentors because, let's be honest, not all engineers are good at coaching other engineers. And so we make sure it's a controlled environment that those college hires go into. Certain teams are the teams they start on, so that we give them good foundations so that when they've built that skill, they're ready to go on and be independent. So that's building the pipeline.

And the other thing we do is we move people around. So my group, the Digital Innovation Center, we could have just staffed one team for this customer and one team for that customer and so on and so forth. But that's how you create silos. So we've created a group that purposely collaborates. We might be working with this customer, but we move people around, so they get chances to learn new skills and do new things.

And this is actually culturally very hard because the tendency in a company is to put you in a job and keep you there for five years. But purposely moving people around and managing their career is good for them, and if you're trying to build a DevOps organization, it's good for you too.

So this isn't going to work here, right? These are all the reasons why you can't do this. It costs money.

So here's the secret. It didn't actually cost us that money, because I can promise you that I do not have a training budget. It's very tiny.

So the hackathons that I talked about and the training we did, we have vendor partners. I guarantee you, if you walk the hallway of the vendors that are here today, they're coin-operated. They want to sell you a product, and they want your teams to know how to use the product. They will probably gladly provide you with training if, in return, you teach your organization how to use their product. So give that a try, because that's the best way to get something for nothing when you don't have a budget.

The other thing that we did spend some money on that was worth it was creating some sandbox. If we wanted people to try Amazon, you need a place to go to Amazon. If we wanted you to try Azure, you needed a way to spin up an Azure instance. So creating that small environment.

We controlled it so that it died after two hours automatically. People knew that ahead of time. We didn't just kill their instances. And you couldn't do large and other things. And we created a controlled environment where they could have a sandbox to not only spin up those cloud things, but spin up anything they wanted. If they wanted to try a tool, there was no "you can't."

And security put, trust me, all sorts of walls around it to make it possible. But we gave them a place where they could actually try technology without the usual bureaucracy. They didn't have to ask anyone's permission. And actually, we've even got it now so that there's a chatbot they can use to spin up a server to get into the sandbox environment, which is pretty cool.

I mentioned the university and community college partners. Look, talk to your HR department. Find out the colleges that you hire the most from. Go talk to them about the skills. I guarantee you they actually want your help. And again, they will help you. Go ahead and reach out to those universities.

And the other is make sure that whatever you do in your training project, make it as close to learning by doing as possible. Really, a lot of times we focus on "send me to a class," and that's just not how you learn to do this.

You learn to be a good DevOps organization by doing actual work. You learn how to respond to incidents by responding to incidents. You learn how to do these things and work collaboratively by collaborating.

The other one is peer teaching peer is a great model for multiple reasons. One is people, when they talk to peers, they share best practices. So you get something that's real because they're doing it. But the second thing you get is kind of peer pressure.

One of the things that happened when we had that collaborative cohort is that one of the team's leads had done this really awesome multiple team-of-teams Kanban. It had all this telemetry around cycle time and lead time and productivity and uptime of the system, and it was amazing. Amazing metrics dashboard. And the second they showed that to five other people, five other people really wanted one of those.

So that was the best way for me to get that practice adopted, because peer pressure. The second you see somebody else performing better than you, you kind of want to do that. So that's the benefit of actually bringing your peer groups together into a peer-to-peer training program, is that you get that network effect of people spreading ideas throughout your company.

The other thing, people talk to executive sponsorship. Larry Prior, our CEO, stands up at the quarterly all-hands meeting and has a slide every single time of all the people that earned certifications and training classes and recognizes teams that did great work and the kinds of technologies and skills we want them to learn. We want people to feel recognized and to know the way to get recognized is to exhibit the behavior we want to see.

It does matter, because the first time he put that up, the list was 14 names. And the next time he put it up, it was like 350 names. So it matters.

And I guess to the point, it really doesn't take a huge budget, right? These are a lot of things you can do for cheap. The main thing is just that you focus on how you can spread this idea around.

Putting that together, I really do think a comprehensive program for how you transform the talent in your organization covers it all levels. The how to be a change agent, again, talking to your leadership team and those people that set the influence about how to be a good team, how to build a good team, how to be a good leader, and how to grow the next generations of leaders. That's the most important part. You got to make sure you've got a great leadership training program.

If you've got that, you need to think about how you're going to build T-shaped skills. How are you going to build a program where your network engineers learn about development, and your development people learn about systems administration, and your business learns about IT? How are you going to let people who are already experts in their field learn about the other fields that they need to learn about to build a system to become a real DevOps organization?

And the people that lead the teams, those neglected middle managers. Dominica DeGrandis calls it the misaligned middle, right? That's where a lot of projects die, right? It's a great idea at the executive. There's a pocket of people over here. But those middle managers are the people that are going to bring this to your organization.

So make sure you spend a lot of time training them how to lead a team, how to be a good DevOps team, how to bring these practices to reality, and not just, "I read a good book. It was awesome. I went to a conference. It was great." Right?

That's a team I think you should spend the most time investing in coaching, because if you get those middle managers on board with training their teams, they become the connective tissue of the organization that's going to propagate that skill.

Then the last is the technical expertise, that you help your new hires and really the career. And I'm very passionate about this. In addition to the university partnerships, I helped our corporate sponsor come up with a sponsorship with Girls Who Code. We're a corporate sponsor of theirs in the Southeast region, trying to reach an area of the country, I'm from Tennessee originally, where there's not a tech industry, but there should be.

So we should be really growing the next generation of computer science talent, and all of us in the room here have a role in that. Even though our jobs are in companies, we hire people, and we are computer scientists, at least I think most of us are. And it's important that we help shape the education because that's shaping the future of all of our companies.

And the thing I guess I have last to conclude is that I think the biggest challenge I feel like I have at this point is, as we continue to grow and scale, even with these models, how do we keep doing it in a way that we're innovating? How do we keep from the groupthink, which is a powerful force in our industry?

I think I came to DevOps by people who were innovating in Agile and innovating in IT, and then discovered we had this problem, and we called it DevOps. I don't know what the next thing is, but how do we keep track of that?

And so I'll certainly say one way I would love to get help is if you're doing something interesting or innovative, I would love to hear about it, because I love the hallway track of the conference for hearing great ideas.

But also, industries that are good at innovation, I'll be honest, the federal contracting market is not one of them. That's something we're challenged with, is how to become a good, innovative company. So if you've got some thoughts on that, I would love to hear it as well.

Thank you.