Paula Thrasher

I'm Paula Thrasher. I am the Director of Digital Services for CSRA. And in case you're wondering what CSRA is, I'm going to explain that in the next slide. So, with that.

Kevin Stanley

I'm Kevin Stanley. I lead an app development team down in our new city, in Bossier City.

Paula Thrasher

We're going to talk about building brilliant teams. And what I really want to tell you is actually the story of the separation and merger that kind of got us here. So instead of so much talking about what we do, we're actually going to tell an internal story and kind of what the last year has been like.

I want to let you know both the separation and merger, how that led us to a cultural moment, and what we've been trying to do to build the talent in the organization.

Here is the story of the separation and merger.

Over a year ago, longer than that actually, many of you know CSC. It was a large systems integrator consulting company. CSC announced a separation between CSC Commercial and CSC Federal. The commercial division was about $8.2 billion, and the federal division was about $4.1 billion, about 14,000 employees at the time.

Those two groups were going to be separated. What this meant was that other than some financial systems that existed for the public sector business because of auditing reasons, and a handful of other things that existed in federal because of the unique characteristics, the entire IT of the organization was centralized.

There was no IT department for this newly going-to-be-splitting company. Everything, corporate software, email, networks, you name it, existed in sort of mother CSC, if you will.

What started off as kind of a little bit of a shadow project, which Kevin was part of, was originally called Secure the Net, which was just a network separation project under the auspices of security. And I will tell you that my first sort of, "Maybe this is more than a security project," was when I learned the budget. And I thought, "Nobody lets security get that kind of budget."

So obviously, a few months later, it came out public that we were going to split the company. The announcement for that was made in April, and the SEC filing date for that split was October. So that's it. Once you file with the SEC, that's your date.

We had to basically build an entire new IT department, and we had about four months and one week to do it.

By the way, because that's not hard enough, we had no corporate functions either. I mean, we had HR, but it was under big HR. We had finance. It was under big finance. We sort of had separate contracts. There were some other things that were separate, but basically, we had no internal anything, right? Everything was part of this big company.

So not only did we have to build IT, we actually had to build a new business.

There was a separate team initially stood up to both do the IT separation, and then there was this team set up to do the business separation.

The other thing that came along and part of this arrangement was we were not going to do what's called a transition services agreement. A lot of times when companies merge and split, the split company leases the IT of the former company so that you can kind of get through that transition period and then move on. The decision was made by the board that that wasn't going to happen. So we had to do all this 100%, absolutely zero reach-back into the legacy company.

How I got involved in this story was right the week it was announced. The team that sat down had built this nice project plan, very waterfall style. Somebody gave it to an engineer and said, "How would you split the company?" And they handed that to John Dancy, who's now our CIO, and he has this 16-page Gantt chart, and he's going, "No, this isn't going to work."

I'll save you the 16 pages of plan, but basically, it was like, buy a bunch of hardware, wait, install it all in August, and then do all the separation stuff between August and October. So obviously, at least I hope to everyone in the room, that seems like a really stupid idea. It was.

John called myself and some others into a room to say, "We know we have to do DevOps to pull this off. Tell us how to do it."

I'm not sure I had all the answers on that, but we did sit in, and the number one thing we realized was, to pull this off, one, we had to break all the rules. So all of this buy hardware, buy data centers is out the door. Basically, we're here to solve IT problems. We're going to automate everything. It's going to be cloud. We're going to do all the things that you have to do to go fast, technology-wise.

But more importantly, we recognized that nowhere in this conversation was how the group that was building the new business was supposed to talk to the group that was building the new IT. They literally hadn't thought about how they were going to talk to each other or collaborate on this build-a-new-company journey.

So we loaned our Agile coaches and all this stuff to them, and we did a big planning workshop. The focus was building minimum viable company.

And we meant it. It meant that if the way to get to minimum viable was pick up Lotus Notes and clone it, that's the answer, even though I assure you everybody wanted the answer to be, "And when we get to the new company, we won't have Lotus Notes," right? That's not quite how it happened.

So the net of this is that out of that recognition that we were going to have to engage both sides, we did actually do a very successful SpinCo.

But because we're overachievers, that's not all. In August, just before all this got announced, it was announced that we were going to then merge with SRA, which was a $1.4 billion company in the same sector, to now form a new company, which is CSRA. So while we thought the only challenge was the separation, now all of a sudden we had to merge a whole separate company, and we had, what, three months?

Kevin Stanley

Yeah, three months. Yep.

Paula Thrasher

Yeah. So that was kind of a rough Monday.

Kevin Stanley

Tough.

Paula Thrasher

To hear that news. So it was, to say, a challenge, and really one that we only, I think, successfully achieved because we sort of embraced the insanity of it all and the fact that anything other than DevOps was not success.

I think to some folks that might have seen me speak last year, when I spoke about a crisis being necessary for transformation, this was our crisis. It forced us to transform because there was really no other option. The way we were doing business clearly wasn't going to work.

The main piece was just rethinking everything. I think it was a once-in-a-lifetime chance to kind of blow up your IT and start over. In some cases, that did mean the initial project was pick and lift, and now the projects we have ongoing are full replacement.

We embraced cloud. We embraced automation. Except for that, I would say we didn't automate everything. There were some things we chose not to automate because it was better to kill it, right? It was better to say, "We're not implementing this system," or, "We'll implement it, but we're going to immediately replace it as soon as we can get to it, and not invest in automation."

But for everything else that we knew had a life, we focused on moving ourselves to all the automation that we knew was going to be necessary to be a modern IT organization and to keep the pace we went.

We moved basically almost all of our workload out of our data centers into the cloud. We replicated a number of subscriptions. By the way, every single license agreement with every vendor had to be renegotiated.

And on top of that, there was a lot of shadow IT discovery. This is a great way. It's like the world's largest scream test. I don't know if you all know what a scream test is. It's when you unplug a system, and you wait to see who screams.

So basically, if we didn't re-sign the agreement or remove it, it went away. We basically forced the business to tell us what was important. And if they didn't tell us it was important, it was gone.

I kind of recommend this to any organization. Don't do a merger. Just do this. Just unplug everything, and if nobody raises their hand to say they own it, then I think you've probably got a system that maybe needs to be replaced.

I think Kevin's got some good stories about some of that.

Kevin Stanley

Yeah. So I wasn't as lucky as Paula. I wasn't hired in April. I was hired in July, and they said, "Oh, by the way, you have to stand all this up by October." I said, "Okay, fantastic. I don't think we're going to make it, but we'll try."

So I was part of the team that unplugged a whole lot of things, and people screamed, let me tell you. A lot of people were using Lotus Notes databases.

The first example that we got was there was some lady. She'd been there for 18 years. Every day of her 18-year career, she ran a Lotus Notes database tied to an Excel spreadsheet on her physical desktop.

Paula Thrasher

Oh, wow.

Kevin Stanley

So we couldn't figure out why we couldn't get the application to run. Well, that's why, because it's pointed to her laptop. So the first question I asked her is, "Well, what happens if you're sick?" Her answer was, "Well, nothing happens."

So that wasn't the right way to do things.

We took those applications, and we put them in AWS. We put them in the cloud. Some of them we stood up on Jenkins to make them automated deployment. But our main goal was to get them out of those people's desktops, out of spreadsheets, out of the old ancient technologies, and into more modern technologies. A lot of the way we did those was by using the cloud, by using Jenkins, and by automating a whole bunch of things.

And everything that we learned, like she said, there was no TSA agreement, so we learned the hard way that, "Hey, Bob over here, you've been doing this for 10 years. Can you help us out, please?" Well, silence. They don't have to answer our questions. They don't have to do anything.

So one of the main lessons we learned was the business has to talk to you. We had to get input from the business. They had to tell us what was important. We had to figure out, okay, we got this website running, but what does it do? How do you use it? How does it really work? Because we don't know. We're just developers. We just stand up a website.

So we took all that knowledge, and then about a year later, we got a big project for the Centers for Medicare & Medicaid Services. We took those things that we learned, and when we first got the project, it took three days for somebody to come into my computer and type in Linux commands to get me set up to work on the project.

Taking all those things we learned from Jenkins, from source control, from talking to the business partners, we reduced that time to one to two minutes to deploy and have a clean system.

Paula Thrasher

Yeah. And I think that main interaction with the business, if they didn't tell us it was important, if nobody in the business can bother to stand up to say the system is important, that's probably not important.

Kevin Stanley

It's probably not that important.

Paula Thrasher

Right. It's probably not that important.

And so the funniest part of this too, I love John Dancy. He's a hard bargainer. So he turned a lot of systems we didn't migrate right away. "We'll get to you later," because nobody really stood up to say we had to do it.

And then later came, and the system, they said, "Well, are you ever going to migrate X?" And we're like, "You haven't run it for six months. Do you really need it? Are you sure?"

So it was a good opportunity to kind of clear the clutter and also to standardize.

The other thing we tried to do in that renegotiation and other things was, we'd had people, everybody was purchasing. I'm going to take Jira, actually, because that's a system that we sort of own and run. We had our procurement team run, "Can you tell me everybody who bought a Jira license?"

We had 67 different. And some of those, in fairness, were Confluence licenses and Jira licenses or whatever. But we had at least 40-something different teams buying the same thing. Why? Because they didn't know about the other person offering that.

So there it says, now that's something that we need to offer as a corporate solution. And then when somebody goes to buy that, we say, "Nope, we have one. And you can use that." But just that visibility was really important.

I think this brought into the sunshine a lot of things that had been going on at IT for years that weren't necessarily visible.

And so what came out of that is that you had legacy two separate companies. In the interim, there's this shared thing. So the shared box gets bigger. The number of systems we have now that are in fact common is a lot higher.

It's not 100%. We still have separate finance systems. We just finished merging the HR system, so there's still a degree of separation. But our collaboration systems are the same, our emails are the same. We've gotten a lot of things to the same.

And the end state is this completely merged company with all of this integrated IT, which I think we're actually on pace to hit kind of our goal, considering that a lot of other companies that do what we did took 18 months to orchestrate a separation.

The fact that we did it in four months was getting to that minimum viable company. But there's still really maybe 18 months of separation that we're continuing to work.

So the conclusion of that was that it was really a great experience. And I think for me personally, the thing I really appreciated out of it was that DevOps and Agile were a thing that we did for our customers, but it wasn't what we did to ourselves. Sort of a typical IT organization, right?

And this forced it to be something we did ourselves. And most importantly was it forced our business community, which is finance and HR and contracts and all of those groups, to work with us more collaboratively. And they're now part of the journey. They're not sort of separate. I think that was the most effective thing.

Obviously, not everybody's going to get a chance to go through the joy of a merger and a separation. But the more you can bring the business into your DevOps journey, I think that's a huge success point that we've certainly learned from that experience.

So the next point is that now that we've done this, that's great. Well, the CIO organization now knows how to be this, but how are we going to make the rest of the company know how to do this? Because we've learned some really awesome things.

We've done a couple of things. This slide is really our, this is from our CEO. This is the goal of the company we've created, is to create this culture. This is something that we said out of that, what do we want to be? We are a new company. We're kind of like the world's biggest startup, I feel like.

This is our sort of corporate culture that we're aspiring to grow and learn. And this is our mission.

One thing that came out of that separation project was boldness. That was the number one word that we talked about in our sort of planning sessions. That was what was great. We were bold. We did things that were kind of scary and a little bit out of the norm, but it worked. And sometimes it didn't work, but that's okay. We killed it and tried a new thing.

And how do we continue to cultivate that kind of mindset?

A lot of it is in the hiring. And a quick anecdote here: we thought it was going to be a lot about the job title. So we ran this little experiment where we tried different job titles on our posting. We tried software engineer, we tried systems engineer, we tried DevOps engineer.

I'd like to tell you that, although I would not say this is the most scientific experiment, of the postings that we did, it made absolutely zero difference. They actually got the exact same number of candidates, and it had absolutely zero impact on the person we ended up hiring.

So in case you're worried that the problem to hiring is that your job titles don't say DevOps, it doesn't matter. It's not about the job title. It's about the role and the experience and what mission you're offering that person. It's not about what you're going to call them.

One of the cool things we've done is create a partnership with the universities. And our organization, our applications group, is actually part of the CIO. But we do both a little bit of internal projects and external delivery.

So what that means is that Kevin both helps our internal systems, but also now that he's gained that experience, he comes over to the delivery side and delivers that to our customers, which means we're kind of like an incubator for next-gen technology into the customer community.

And then we're sort of replenishing that internal group through partnerships with local universities. And what we're doing with the local universities, we actually gave, with LA Tech and some of the other universities, we gave them a DevOps toolchain. We gave them an open source, you click a button, it runs a bunch of scripts, and it stands up Jenkins, Git, Redmine, a bunch of open source tools.

So that when those computer science majors are learning to program, they're learning source control in Git. They're learning Jenkins. They're learning that as students.

So when we hire them, we don't have to train them how to use source control. We don't have to do those things. They've learned it as part of their curriculum.

I think that's a really cool engagement. We're reaching all the way into people we haven't even hired yet to try to make them DevOps engineers so that when they join us, they've already got the right skill set and mindset.

Anything you want to say to that?

Kevin Stanley

Yeah. I think we're in a unique position with the university. I've lived in Louisiana my whole life. So what everybody does, they go to school, they get a degree, they go to Texas. That's just how you do it. Everybody goes to Texas. Nobody stays in Louisiana.

Paula Thrasher

I did.

Kevin Stanley

You did? All right. See?

So what we're trying to do is we're trying to go into the universities and teach them that there are jobs in Louisiana. We teach them what we want them to know when they get out, so once they get out, they have experience in the things that we do.

Paula Thrasher

Yeah.

And just, I guess, a main point beyond that is the other thing that we try to do by having that leverage is having enough slack time and learning experience that we give people a chance.

And also through partners, I've mentioned this, if your vendor companies want you to learn their product, most of our vendor partners provide us free training, right? You can get a lot of training free from your vendors. They'll help you out with that.

But then you have to give your people time to take it and to learn it. And so, for instance, we gave the whole team an Amazon sandbox. We're going to get an Azure sandbox soon. So that they've got a sandbox to try stuff in, just whenever they want, right? They don't have to ask for somebody's permission to get an Amazon account to practice something.

They have to keep within the budget, but we just use it, right? Making those things available are really important from the growth standpoint.

And I also appreciate that our CEO, Larry Prior, at every meeting, at every all-hands meeting, announces all the people that got Amazon certified, announces all the people that got Azure certified, announces all the people that got Jenkins Engineer certified. We're trying to reward people for learning new things and making public recognition of those people who went on the stretch goals.

The other cool thing that we did that we're going to reboot in January is the Agile cohort. This actually came from an Agile 2015 talk, and we spoke with Renee Troughton. We took people who we thought were good leaders on their teams across the company. We paired them with Agile coaches.

The goal was actually to get that five-person team to train themselves, so we gave them assignments. And we chose geographically diverse people. We were trying to build connections across the company so that it wasn't just people on this one project or that project. We were trying to purposely build connections to somebody that wasn't on your project.

And so just a quick credit, Renee Troughton both presented this at Agile 2015, and then I also want to thank her because she actually spent about two hours talking to us about how to do this.

So we adapted it for ourselves. But I certainly hope I can pay it forward here if anybody else wants to talk about this. It was so generous of Renee to do that for us. I'd be happy to do that for anybody here that wants to talk more about this program.

But this was the agenda. So the first week, because we were virtual, we had little PowerPoints on "How I got to be me." We talked about growth mindset, right? How do you learn? What are different learning formats? And explaining to people that you learn by doing and things.

And then we basically gave them a book, like The Phoenix Project or Extreme Programming, to go read. That was their homework assignment.

And then the next week, they came and met together, just like, "What does Agile mean to me?" Just discuss the topic, sort of facilitated, but it was about the team talking to each other about their experiences on their project.

As we kept going, because again, the homework assignment is read the book, right, and we all have day jobs, we did some training on how to tease out root cause analysis. We had kind of a book report. We had everyone basically all pick different books, so they all told each other what they learned. Like, did you learn something new? Where was the insight? Where was the conversation?

We did some training on effective change management and facilitation. We were trying to coach them on different ways to be that change agent on their project.

There was also the assignment too, was we have a deep-dive list. Nancy runs our Community of Excellence, so we now, on our Center of Excellence site, have this training path. So if you want to study The Phoenix Project or whatever, Lean, you can follow those training paths that we created in this class.

The main point of all this was that throughout this 10, it was actually 12 weeks because we had some holidays in there, but throughout those 10 weeks, the goal was to get that five-person group to build connections with each other, to learn from each other, and to actually do stuff.

So their assignments, in addition to reading books, were build a brown bag, and the other assignment was come up with a visualization for your project.

And from that, we'll be launching the next wave of cohorts, and we'll have as many of them as we have coaches to match up.

The feedback from the team was it was great, do more of it, and maybe have more regionally centered ones so people can kind of meet up in person. So we're going to try that for the next round of cohorts.

But this was a huge thing. And what I love about this is that my cohort graduates are now some of our team leads, and they're now building good teams. I think that was the most important thing, is to solve that middle-manager stuckedness of actually training the people that are at that level how to kind of embrace this cultural mindset.

And the last thing, we're a little out of time, so I won't spend too much on this, although I'll highlight Kevin, our celebrity here, is that we're actually opening a new building next week. We're cutting the ribbon on our new building in Louisiana.

The architects actually spent two days at my project back in DC, where I had 300 folks doing DevOps sitting with us, going through standup meetings. They were on a CERT call. They watched us work. And we purposely designed this building for DevOps. It's kind of cool.

It was built to encourage collaboration. And so what we did, I think the most interesting thing, so the architects call it encounter space, but one of the more interesting design decisions they did when they built the building is that all of the shared space, like the coffee makers, are in the middle.

So we built sort of purpose space for the development teams. You can see here is an example, just standard stuff, right? Open cubed, right? All this is raised floor. It's all flexible, so as the team shrinks and grows, we can change the desks around so that the team space is kind of cohesive.

But the cooler thing is that the ops team on the other side, because the ops team, they got the SOC wall of monitors and all that kind of stuff, but when they go get their coffee, it's in the same space. And there's a shared space with shared meeting rooms and just shared space to talk.

That was a nice, intentional, on-purpose thing that we did because we recognize that we're huge. Our IT organization is large. Our customers we service are large. We can't necessarily make ops people totally developers. We can do a little bit of that, but to a certain point, you need a SOC, you need a NOC, you need an ops room.

And developers don't really like it when they're sitting next to the service desk and the phone's ringing all the time. So we needed separate spaces, but we also needed shared space.

And I think obviously not everybody gets to build a new building, but to the point that you can make sure your environment makes people feel like you're on the same team and that you share space together is really critical.

Whether there's cubes or not, the main point is if you share a coffee maker, I think that's a good sign of how well your DevOps initiative is going.

So we're really excited about that. And I think it's a small thing, but I do think it's both the people and the space they work in makes a big impact.

Cool.