Bob Stevens, AVP Public Sector at GitLab joins Tech Transforms to talk about the imperative mission of DevOps to combine efficiency, speed and security. With emphasis on empowering teams to fail fast, moving security to the left, and a deep dive into Platform 1, you won't want to miss this episode!
Carolyn: This week Bob Stevens, Area Vice President of Public Sector at GitLab is joining me. Bob is a seasoned veteran in public sector technology with over 25 years of experience. As the AVP at GitLab, he is responsible for helping government organizations become more productive, efficient, and effective.
Bob also has experience on both the industry and the government side of things. Prior to industry he served in the United States Air Force as a computer specialist at the White House Communications Agency. I am excited today to dive in and talk about the ways that we can use DevOps to modernize and secure government IT, and what the outlook for DevOps is. How are you doing, Bob?
Bob: I'm doing great. The weather's getting better in DC, so it's good to see the sun from time to time versus what we've had. But yes, doing fantastic.
Carolyn: Well, good to hear it. So let's just dive in. And let's walk through what DevOps is and why implementing these practices is critical to helping modernize and improve government IT?
Bob: Great. So I guess DevOps is combining efficiency, speed, and security all into one. And creating software at what I like to refer to as the speed of the mission for the government. The business side is a little different. But for the government, it's all about the mission and you being able to accomplish the mission faster and stay ahead of our adversaries. In the case of DoD and on the civilian side, it’s to ensure that all of the citizens that any given agency supports gets the best possible support that they can. If you look at the organizations like the Veterans Administration. You can imagine they've got a lot of applications that they've written.
Bob: To help the vets accomplish what they need to accomplish in a timely manner. So DevOps really will help them to produce the software at speed, more securely, more efficiently, and provide the most or the best service that they possibly can to all of the veterans out there, just as one example.
Carolyn: So, you know Tech Transforms is vendor agnostic. And I would love for you to just take a couple of minutes and talk about how GitLab helps with that. And just what GitLab does. I've read the marketing statements and it's a little nebulous for me. I would love to have you explain what GitLab does and how it's helping agencies achieve this?
Bob: I appreciate that you're letting me do this in a vendor-agnostic community. I mean, there are a lot of tools that are required to produce software. But the way that the industry or the government in particular is heading, and you can see this in some of the articles that DoD has recently released. Is they're looking for one platform that encompasses the entire software development life cycle.
As you can imagine right now, I know agencies that have anywhere from 14 to 20 different tools that they're using. And the issue with that is that there's developers that like the tool that they like. So they bring their own and they develop their portion of the software. Unfortunately, when it all comes together, it doesn't always work because they've used different tools across the development organization.
And so, with the use of a single platform, you can ensure that at the end, everything is going to work. The nice thing is you can continue to bring some of those other tools. Because they integrate with the platform.
Bob: Just as an example, JIRA, the government's using a lot of JIRA. And JIRA integrates with GitLab so that you can use them seamlessly together. So the developers that are using their favorite tools can continue to use some of those. It's just that it's going to be more efficient because in the end you're going to have an application that works out of the box.
Also what GitLab is trying to address is moving security to the left. Developers are a lot of times at odds with security folks because developers are tasked with developing code fast. They want to get it done quickly. And security folks want it to be done secure. So sometimes the two collide.
But when you're building a single platform and you allow, or you have the ability to move security to the left, which means, when I check in a line of code, I'm going to do a security scan to make sure that I didn't somehow introduce a vulnerability. If I did, I could fix it immediately rather than waiting until the end of the process. Then running security scans and realizing, I may have to go back through hundreds of lines or thousands of lines of code to figure out where that vulnerability was introduced and do the repair.
The other thing that I'll tell you is visibility. Not everyone has to be a developer to use the platform or GitLab. You can be in the executive branch and know nothing about how to write code. But you can see the process during the whole time. You can ensure that what's being produced is going to best meet the requirements of the people that it's being produced for. You don't have to wait till the end to produce the app.
Bob: The users start using it. And they're like, "Oh my God, this is not the way that I wanted this to work." Or, "This doesn't work for me." Or, "It would've been nice to do this." It can be integrated during the process so that you can make sure that the application is usable in the end.
Carolyn: What you just said helps me understand what GitLab does a lot more than any reading I was going to do on my own. And it certainly sounds like a smarter way to do things. So you've written many articles and often you talk about the need for DevOps, DevSecOps, a big part of it is just cultural. And so is that starting at the CIO level? And if so, what are CIOs doing right now?
Bob: I mean, first of all, I have empathy for CIOs because they have so much thrown at them right now. It's incredible. I actually don't know how they are able to get as much done as they do. But having said that, I think most CIOs know that they need to move away from the legacy development waterfall to the agile software development world. And I think they're making gains towards that.
Bob: Nothing in the government moves quickly, but moving to agile, it does require a cultural shift. And that's where the CIO or the CISO plays a very important role because they've got to convince the organization that failure is okay.
Because when you fast fail, you actually make more progress than waiting till the end. Which is a cultural shift for any organization. That shift has to start at the CIO level. It can't start at the lower levels.
Bob: The lower levels have got to be empowered to fast fail to experiment in order to produce the best possible software application that they can.
Carolyn: So you talk about this in an article that I just read Modernizing and securing government IT through DevOps. You say that, "Federal CIOs embarking on a DevOps journey should embrace continuous integration, continuous delivery pipelines to reduce toolchain complexity, management, and maintenance." What can CIOs and CISOs do to embrace that statement? Because that's like you said, that's a lot.
Bob: It is, yes. And unfortunately they have many more mandates coming at them from OMB and NIST. Even though NIST doesn't generally put out mandates, more guidance. But they're starting to come forward with a few more mandates. And so I don't know how they're keeping up with it. They're doing the best that they can. But it's the cultural shift that needs to occur for the development life cycle. It's also the building of the platform.
I say this often, it's not really the money. And I think that CIOs can find money to buy tools. I think it is more of the resources and the cultural shift that needs to occur. And that's where the CIO can really have the influence, is to be able to provide the resources, be able to have the backing at that level for experimentation and fast failure. And it's not necessarily because they can get the Technology Modernization Fund. I mean, upgrading your DevOps world is modernization, so they can tap into funds. It's really the other things that need to be considered for the shift to the new DevOps environment.
Carolyn: Do you have any good use cases or stories that you can talk about where you've seen this shift happen and this DevOps, this new process, this agile process be implemented?
Bob: Yes, sure. I'm going to go back to my Air Force roots, which makes me proud. The building of Platform 1 was a huge shift. And as a result, the Air Force is able to produce software so much faster than they were. And when they produced the applications in the end, they're closer to what the user needs in order to do their job. Because who better to inform the developer about what's required than the person that's going to use the application.
As an example, you can imagine there's a lot of software in the F-35, just tons of software. So who's the best person to tell the app developer what they need for flying that jet? It's the pilot. So if they can participate in the DevOps process and they can, in the way that things are designed in Platform One, then it's going to be a more efficient use.
Carolyn: Okay. You just said something about Platform One that made some light bulbs go off. That term gets thrown around a lot. I use it a lot. I didn't understand that the end-user was involved that way.
Bob: Oh yes. I mean, that's the beauty of building a platform or using a tool like GitLab. They have the visibility, they can see the software as it's being developed and can have input.
Carolyn: And they do participate? They'll look at it and say, "No, that's not going to work?"
Bob: Sure. Yes, absolutely. And that's how you can take the use of an application from months or a year down to weeks or days. The modification of a software package could be done in hours versus the way that it was done in the past. So it's just a lot more efficient way to be able to produce a usable application in the end.
Carolyn: Okay. My mind's still spinning on this end-user can say, "No, that's not going to work." So for them to participate, are they actually using the end result somehow? So they use it the way they would really use it in the field, like through a simulator or something so they can test it kind of real life? And then, I mean, how does the pilot test and give feedback?
Bob: Yes. Well, a couple of ways. First of all, they have the visibility, they see the code being written. Although they don't necessarily need to understand what each line is, or how to write it.
Carolyn: Right. Well, because I would think the pilots, that wouldn't mean anything to them.
Bob: Yes. Like you said, they can see the simulation, but they can also see or respond to questions from the developer. They can see what the developer is thinking in regard to what they're producing. So all that's valuable information for them to be able to provide feedback. So again, in the end, the application works as expected and meets the requirement and the mission. It's all about the mission.
Carolyn: But spending time answering questions in a chat room about something developers doing. Is that part of their job description? Like every hour or every day they spend an hour responding to developers? How does that work?
Bob: Probably not, a little short story for you. Several years ago, I was in a meeting where a very high-level person in the Air Force said every airman will be a developer. And I thought they were crazy, absolutely crazy. But by producing a platform that allows them to participate, not necessarily write code, but participate, they can all be developers in a manner of speaking.
So I think that the Air Force has been able to come as close to accomplishing that as you possibly can. Which of course, again makes me proud. That's not to say the other branches aren't doing the same thing, they are. It's just, the Air Force was out in front of the other branches.
Carolyn: Yes. I have a whole new respect for Platform One now. I really did not understand that everybody was participating like that.
Bob: And yes. I have to point out Top Gun is the Navy, not the Air Force.
Carolyn: Thank you. Well, so in the same article that I referenced earlier, back to Air Force, you talk about Master Sergeant James Crocker. I don't know if you want to share his handle?
Bob: He goes by Guideaux.
Carolyn: Yes. His story and some of the stats that you shared with his story were pretty beyond impressive. I mean, they're almost like you say, that a hundred years of program time and software release timelines were reduced. You went from three to eight months for that cycle to just one week.
Bob: Yes. I mean, it's a great story, and he's built a great software factory. And he continues to run it today. He is a strong, strong advocate for a DevOps platform. And he's proven that it'll work. He continues to do that every day.
Bob: And again, he established the bar for speed to mission, and what they've been able to do there. We're going to continue to support him and get him whatever he needs to be able to help produce the applications the way that they have been for a few years now.
Carolyn: I want to revisit what you said about a culture of failing fast. Was he a leader in that? Because to me, that's not something that gets advertised about any of our defense agencies. That you would brag that yes, we fail all the time. That's part of our goal. That's part of our objective. So, if he was one of the first to embrace that, or how does that get embraced? I would imagine it's still resisted a lot to fail.
Bob: Well, I mean, yes. I mean, especially in the U.S., the word failure is bad. But it's how we learn and it's how we move forward rapidly. I'm in sales. I'm chartered with selling to the government.
And I'm always telling the team whenever they're involved in an opportunity is like, fast fail. If it's not really an opportunity, then move on, because you're going to waste your time. And frankly, you're wasting the government's time. So stop wasting their time.
So, it is a big shift. But like I said, Guideaux's definitely one of the people in the military, the Air Force that embraced it. He also had support from executives, which is required across the Air Force. It is a great story and I'm glad it's public so that I can talk about it.
Carolyn: Yes, me too. So what do you think the future of DevOps looks like?
Bob: It gets back to the building of the platform. Where all tools are integrated and there's no more BYOT.
Carolyn: Device. I knew you weren't saying BYOB. Although, maybe we should.
Bob: It's really getting the teams to collaborate. Here's another great example of what the Air Force has done. They've put software factories in downtown, in cities, Austin, Salt Lake, many others, where they can find and retain top talent. This, I think is genius.
And they've given them an environment that they enjoy working in. I mean, honestly, some of the bases they're old, the buildings are old, nobody wants to go to them. But, if you can go to this nice fancy office in downtown Salt Lake City, then you're going to be a much happier person and more likely to show up and be productive. So, I think that's another thing that DoD has embraced is where they're building the factories, and the talent that they're able to attract and retain as a result of that.
Carolyn: Do they allow remote work in these software factories or does it all have to be on-prem?
Bob: No, they do. And that's another great thing to point out. Three years ago, if you said to me that the DoD was going to allow people to work at home, I'd say you were crazy. It's never going to happen. But the pandemic forced the issue. And now DoD has embraced it. I think that what they've found is that folks are perhaps more productive than having to commute and being in an office. A lot of good positive lessons learned as a result of remote work. I think that it's going to continue.
Bob: I don't know if you know this, but GitLab is a hundred percent remote.
Carolyn: How long? Is that just because of the pandemic or has that been a while now?
Bob: No, it's pretty much since inception. We did have an office for a few short months, which was closed. And I think that was about six or seven years ago now. So, we're quite proud of being an all-remote company, and the way that we've made that work.
There's been a lot of papers written on it. There's a lot of great information on our website that can help organizations understand what it takes to be an all-remote company. But one of the strong benefits from it is, if I'm looking for somebody with development skills, they can be anywhere in the world.
Carolyn: Exactly. You open up your talent pool just exponentially. And I've worked remote for 10 years and I've had to jump through the hoops and every year, fill out the paperwork. I've worked in government supporting the government mission for over a decade. It was a battle until the last two years. And now it's, everybody gets it.
But it's interesting because there's this movement right now to get people back into the office. And I'm just wondering what that's going to do to talent retention? If somebody had told me I had to go back into the office, I don't think I would do it, Bob.
Bob: Well, I think there's a negotiation that's occurring now, based on what I'm hearing with the companies that are trying to reestablish the office. There's a lot of pushback from the employees. And it's tough enough to get talent today. You don't want to create any other barriers.