Episode 78: CloudBees CEO Sacha Labourey on Software in the COVID Era

Brian Dawson: Hello. This is Brian Dawson with DevOps Radio. This is a special episode of DevOps Radio. My boss has decided he'll talk to me. So we now have – I'm joking. I'll explain that in a minute – but we have Sacha Labourey, the CEO of CloudBees, who is here to have a discussion with us about the intersection of software, the software development and delivery function, software industry, and Covid-19 and the times that we're living in.

Sacha, hello. Welcome. 

Sacha Labourey: Good to hear you and good to talk to you, Brian. 

Brian Dawson: Sacha, we're currently facing what people are calling unprecedented times or I think we can agree are unprecedented times. I'd like to start by asking you are there current events this time reminds you of, or other times where businesses have faced these kinds of challenges? I.e., is this like anything that we've experienced before? If so, can you make the comparison for us? 

Sacha Labourey: Yeah. I think the closest to this would be events like – at least for the western world, obviously – but things like the dot-com bubble and obviously 2008 was another crisis on the financial market, because it created this situation where essentially there was a lot of anxiety around the safety of jobs, what businesses would still be up the next day, the domino effect of whether a business going down would have an impact on otherwise healthy businesses. So I think there is a bit of that.

Even so, I think if we talk about, quote/unquote, anxiety – I know it's a DevOps Radio episode, but the human being is obviously core to anything we do, and the anxiety here has been pretty unique because it's not just about whether you're going to have a job or not, which is already super-important, but are you going to get sick. Will my parents or family get sick, my friends and so on? So I think a lot of anxiety has been pretty unique in that situation. 

Brian Dawson: Yeah. I don't know if you would agree. I'd say that you're much older than me, so you have much more experience with these – no, just another bad DevOps Radio joke. I think I'm much older. But this to me seems unique compared to the dot-com bust, the great recession due to real estate, in that it's pervasive and that it's practically every person, every industry, every country. I think that that contributes to the feeling of anxiety because there isn't a safe haven, and it's so different and so pervasive that we can't gain comfort in saying, "Well, this is just like x and I know it turned out okay."          

Now kind of taking that in context, what I'd like to ask is how will a recession or economic downturn like this impact the software industry? 

Sacha Labourey: I think it's going to be an accelerator. First, I think we need to split things between the vendors of technology and the users of technology. From a vendor standpoint, I think it's going to accelerate some of the consolidations, especially DevOps where I feel like it's been an amazing era. It's still an amazing era where a lot of innovation takes place. A lot of ideas pop up and so on.

However, in those uncertain times, I'm not necessarily sure that there's going to be business for everybody. That might be sad, right, but there is limited runway. So I wouldn't be surprised to see a lot of those great ideas being brought up as part of bigger organizations. So I do think the consolidation of any market, but it's true of the software as well. We probably accelerate during this, because of this Covid crisis.

From a user standpoint, it's also very interesting. We actually conducted a bunch of interviews from IT users during Covid to hear what was happening and so on. What I was surprised to hear is that the first wave is really basic. It's like we fought to get VPN access. That's as basic as that.

You were expecting to hear big strategy things around impact on software. It's like, "Yeah. We couldn't get VPN access. We had to upgrade our VPN." Okay. What else?

Organizations that were ready for – that were DevOps - essentially were really great at this transition, because their software was automated already. They had a lot of automation. Releasing software was part of their muscle.

For example, in a way, working from home or an office didn't change much. A lot of organizations told us that it was a nonevent, outside of the anxiety and so on.

For others, it was a big deal because they realized how much dependence on, "Oh, we need to go to this machine to do the final push," or, "We need resource people to validate some specific things." They have some magical things they do and, hey, guess what, they were sick or wouldn't work anymore. So it's a test essentially on software. 

Brian Dawson: I was in an interview yesterday actually, and we were having a discussion about this. It came up in the discussion that Covid has kind of been the chaos monkey, the equivalent of the chaos monkey, just coming in, banging on the infrastructure, throwing chaos at it to see what clusters stay up, to test the infrastructure of our industry, of your companies.

I equate, to what you're saying, sort of what I found is companies that had thoroughly or I guess I'd say legitimately sought to implement DevOps practices were better prepared, right. They had repeatable processes. They had shared knowledge, shared IP. They were making proper use of repositories, sharing their binaries in those repositories.

So in my experience, what I found was they had probably dealt with some remote access or VPN access, not necessarily holistically, but it meant when all of a sudden employees had to move away from their desk and outside of their open workspaces and go work at home, it was much less likely to disrupt the process. Would you agree with that?     

Sacha Labourey: Yeah. It's very clear. I love, by the way, the chaos monkey or the Covid monkey you talked about. It's really cool. 

A little anecdote which I thought was funny, in some ways funny – 

Brian Dawson: In a dark, twisted kind of way funny?

Sacha Labourey: Well, maybe it was not too funny for them when it happened, but I think you can laugh after. 

Brian Dawson: Okay.

Sacha Labourey: So they realized they had to send everybody home and they didn't have enough laptops. So they had to buy something like tens of thousands of laptops in a couple of weeks, and ship them, prepare them and so on. But then in some regions where workers were working from home, where the bandwidth was not great, especially in terms of latency, they realized that some of the tools they were using were not usable because the latency was too high and it was over the server. 

So they had potentially thousands of servers, virtual servers, desktop, a little desktop on the server. So they would work from home with their laptop, go to the server, and actually work from the remote server – because the latency was a cloud-to-cloud issue. It's obvious, but unless you've seen it and tried it, you just don't know those types of issues. 

Brian Dawson: Yeah, that's interesting, yeah, unless you're kind of forced to go through it. It's actually similar to another analogy that someone came up with. When you're agilely or you're thinking about DevOps and delivering software, you will realize that you're trying to minimize the difference between where you're at today and production looks like, but there always will be some testing and production. There will always be something new in production. So yeah, there's things like latency that you're not going to necessarily have thought to or have had the opportunity to test out until you get in this situation. I think that is a great point.  

Another thing though that you brought up, Sacha, that goes back to an earlier statement, you categorized those that use software to deliver their business versus a software company, those that create and sell software. It sounds like as you talk about this latency issue, that somebody that uses software spoke with you about, it also becomes a lesson for a software company. I.e., they could get away with adding chatty software and having it be useable. But in this case, they may have customers who have learned that it's too chatty and they can't use it in a remote environment.

Does the Covid monkey force anyone who is a software company to rethink about how their software may be used? Or are there changes like that that are going to come on the vendor side of things?

Sacha Labourey: Yeah, that's interesting. We've obviously asked these questions to the companies, "What are you missing," and so on. What was interesting is that we didn't get much feedback. It felt like it was okay, but I feel like it's okay, but it's not okay. It's not because you don't see what you could have, that you don't think you could benefit from some help.

For example, we've seen a lot of discussions around productivity, the fear of, "I'm going to have employees working from home. Are they going to be playing with their cat all day long and work 30 minutes?" Okay. So how can we measure – 

Brian Dawson: That's what I've been doing. Don't tell Sacha.

Sacha Labourey: Oh, I know you can work and play with your cat.

Brian Dawson: Okay. Sorry to interrupt.

Sacha Labourey: But it's a big question. So we've seen companies look at the VPN connection, bandwidth being used on the VPN connection. We've seen a – [indiscernible, audio warbles] – but ultimately, it's about trust and at CloudBees, as you know, we're all working pretty much. Each person must be working from home.

So you know you have to give that trust and you focus on the outcome. If people do their job and work less, well, I guess that's fine. They still usually work like crazy.

But it's a different approach. It's a very different approach. So I still feel like there is some uneasiness about how do I make sure people are okay first, their own health, they're being productive, but at the same time I'm not appearing like I'm putting a Web cam into your home to see what you're doing. Finding the right balance is – [inaudible].

Brian Dawson: Yeah. What I am hoping is that you, Sacha, I guess as part of the reason why you're here, but you and CloudBees and this organization that you and your founders have built will act as a model that will help people develop that trust and understand how you work effective remotely. 

I'll share that I worked remote for a number of years. This is one of the first organizations I've come to where you really could give credence to that term, "We're a distributed company," where a major percentage of our communication and work happens with people from their homes, in 17 different countries, but connected and connected continuously, and not because getting on video or having multiple meetings a day or interacting with your team as if you were in person is necessarily a mandate from the company, but it's just the culture of the company. 

So as you have these discussions, as I have these discussions, I would hope we can continue to do some of what we've done, and taking some of our lessons and sharing them with the larger community, to help other companies do better. 

That actually transitions me to a question that I did have prepared for you. We've talked about some of the impact, some of the learnings, how the Covid monkey – which I'm going to use for the rest of the session – affected different types of companies. Then this leads me here, Sacha, to ask you what can a software company do to prepare for a recession like this one here? 

Sacha Labourey: First, I think it's been very clear that the most resilient part of a company has been around software. A lot of physical things have stopped working or couldn't be leveraged anymore. So betting on software is the right bet. 

We've seen a lot of companies, we've talked to a lot of companies who get that. They're saying, "We don't know what we don't know, so we need to be careful in terms of investments, but one area where we're going to keep investing is in transformation and doubling down on software, because those were the things that remained up and provided value." So that's very important.

And what we just spoke about is very important as well, which is this building up – not preparing for remote employees, but preparing for _____ cultures, where essentially you're not having remote employees that somehow you need to treat in a bizarre way because you don't know what they're doing and the real benchmark would be the person who sits in an office. But really rethink how you operate, so that it's totally fine to be completely distributed, meaning being remote, quote/unquote, is normal, is the right behavior.

If you're unclear on what that means, there is an easy way to do that. Take your CEO or your C suite and put them home for a month, because a lot of executives I've seen keep working from the office. They send their employees back home because that's, quote/unquote, the right thing to do, but they're going to stay and work from the main office, because there are less people in the office, so I'm going to be fine.

But it's not putting them in the right context. They have to experiment. They have to see what it means to work from home, to distribute the message you're making, work when you can't see equally as well the body language. When decisions take place, how do you know about that? Well, because everything we do is written down somewhere centrally. It has to be explicitly communicated. It's not because you're not in the office that you're not aware of those decisions. They need to be exposed to everybody in the same way and so on.                         

Force them to make big decisions and go through real stuff, not just do the day-to-day work. Does that make sense?

Brian Dawson: Yeah, it makes absolute sense and I want to dig in a little bit more on that and ask for some specifics. Look, as I talk to you right now, I am remote, in an upstairs bedroom, former guest bedroom in my house in San Diego, California, while you're in Switzerland, upstairs, in a room. You talk about send everybody away. It's different. You can't detect body language and things have to be explicitly written down and/or communicated explicitly.

Give me one of two specific examples of what you have done to manifest what you're suggesting in order to run your company successfully. Is there a given practice, a given way that you document or share information that you can share with our listeners? 

Sacha Labourey: First, a lot more written content. For example, let's take the executive team at CloudBees. Every week we have to submit the documents on Friday. It's not homework, right. If you don't have anything to say, don't say, but the goal is for everybody to say what they have to say. Do they need help from somebody? Is there a risk or is it just informational? Don't hide action items with informational content because it's messy if you need something said.  

Everybody does that before our executive meeting. We all have to review this, read it when we can, over the weekend or on Monday morning. That way, we get to spend time on the executive meeting, not going through, "Okay, what's up on your side? What's new," because that's useless. 

You want to spend time on face-to-face time for the right reasons, for debating, for misunderstanding and then understanding, all of those things where written communication gets harder, but if you can replace it by writing communication, well just frickin' write it. That's much easier. That's where you get to read it on your time zone, when you wake up, when it makes sense for you, but don't just have a discussion for the sake of discussing something that could be six bullet items. 

Brian Dawson: Right.

Sacha Labourey: Also, repeating things. People might – we know that when you're in front of computers, the news website is one click away. So you might want to just go, "Oh, this is less interesting. Let's go see the weather forecast for tomorrow." We all do that. 

Brian Dawson: I never do that, never.

Sacha Labourey: Except you, Brian, we all do that. I do it. I'm guilty as charged. And I'm a news junkie, so I can't help myself. So you have to account for that. Don't expect people to be perfect and to say, well, you know, I remember at some point I said it, well, repeat it.

One thing that we also do which I think was useful at some point, when we started being above 120 persons. Below that size, I think we got a lot of things for free in terms of alignment and culture. Above that, it gets harder because you are much more disconnected from the source of things. A lot of  knowledge or information you could get from people who heard that, that disappears. 

It took me a while to understand that, unfortunately, but at some point, I started, for example, the water cooler, right. The idea of the water cooler is that – and why it has this name is because in companies you don't want people to take decisions around the water cooler in many companies, right, because you exclude what a lot of people are doing. But still, the water cooler has this big positive, which is you just discuss stuff and you hear about stuff, and you share thoughts and you vent and so on.

So now, for about a year now, we have this water cooler session where I try on Wednesday to share [indiscernible] – but thoughts on a theme. Then on Thursday, we have one session for European and Asian, and one session is – another session for the US and – [indiscernible]. If people want to chat about what I talked about, great. If they want to talk amongst themselves, great. If they want to bitch because they don't like a change that was made, great. 

But it gives a way for people to rally around something. If it's done right, and I hope it's done right, I think it helps people also feel a part of the same team. 

I'd love to get your thoughts, Brian, because I'm selling my own thing here. You've experienced that change from nothing to water cooler. What do you think?

Brian Dawson: That's funny. I was just thinking of some thoughts there and I'll tie it back. First, I want to identify that the water cooler is a manifestation of two of the things that you just said are practices you've implemented. Document, document, try to read and digest async so you make meaningful time of the face-to-face time that you have. 

Then you said repeat, repeat, in the way that you've rolled out, we've rolled out, the organization has rolled out the water cooler. As you've said, there's a North America version. There's an EMEA version. The video comes out earlier. The people show up twice, just to make sure, and then it lives there, to try to make sure that people can either consume it live, if that's what they need, or they can consume it asynchronously, if that fits with their schedule. It's important to note we execute this on Slack and the discussions will continue for days after the initial water cooler. 

So I first wanted to call that out, but then, Sacha, thanks for asking me. I want to tie it to a particular thing, when you're dealing with a distributed company, particularly an organization that has been forced to go work at home due to the Covid monkey, due to the acid test that has come about, but they're not used to working in a distributed way. 

What the water cooler has done and what happens is one of the primary human motivations or needs for socialization and connection is significantly disrupted and challenges, when all of a sudden you have to break and go work remote. One of the things that we experienced in a very emotional time, some of the unrest with the disturbing and sad murder of George Floyd, this powerful discussion about Black Lives Matter and racism in the United States and beyond was the time when people kind of needed connection and they needed some understanding. As per our regular motion, but still very special, Sacha, you put together a water cooler.

I participated. We recorded videos of the employees sharing their personal experience, and everybody came together and discussed it. You know what was really powerful about it, what really drove home the benefit of the water cooler is it was a very, I think, emotionally confusing, a raw time for everybody, black, white or other, and the standard motion we've implemented as a distributed company provided a platform for people to have that connection where it was absolutely necessary. 

I promise, Sacha, I'm sharing this for the benefit of our listeners, not to campaign for a pay raise. The wisdom of the water cooler has really shown up at time like that. It's shown up at times when people are working really hard, and we've just got to stop and celebrate something like recognition for an award for a product, recognition of a promotion. So it really is an important way to sustain that connection. 

I will also comment that I was here before the 125 mark and things like this became necessary, even remote. I think we've learned if you have a given culture, and there's a really powerful group of special people here that work at this organization, that would just keep things working. But up to a certain point, you have to – you know, you can get away without implementing practices and processes such as the water cooler. 

So, Sacha, in my standard form, that's my very long way of saying it's pretty cool. 

Sacha Labourey: All right. That's great to hear that. I like the fact that it goes both ways. I get a lot out of it. When we talk about the situation with Black Lives Matter, I'm Swiss, so I feel a bit remote from all of that. On Tuesday, I didn't know we were going to do that that week. On Monday, I was away. On Monday evening, I was worried about, "Should I do something or not?" As a Swiss, I don't want to put my feet in US-specific issues.

Some people actually reached out to me and I think it's because of the water cooler. Thanks to the water cooler, they felt okay to reach out to me and say, "WTF, you don't do anything?" I was like, okay, and I started thinking, stepped back and said, "Why am I not doing anything about it? What does it mean? Yes, it's right. It's a bigger issue. It's racism. It's not a US-centric issue." 

I didn't realize that a lot of black people felt personally really bad because of what was happening. You don't necessarily think about those things. That's a great point. In those two days, I learned so much. So much. And I know a lot of people learned so much. I got a huge kick out of that. It really changed me.

Brian Dawson: So a couple of things I want to hit on. Then I'll want to, just to kind of prepare you, get your predictions for what we'll learn from this and what things will look like in the future.

But what you just mentioned, we implemented a process prior to Covid to help support us in a distributed company that gave us as a standard process, not an emergency change request, to use an analogy, emergency change request process, and that became a platform or a vehicle that allowed us to at least internally have a response to dual challenges, dual acid test, right, Covid, social or societal shift changes and unrest. 

I think this speaks a lot to what you said earlier. Think ahead. Implement smart processes, smart practices. Don't put yourself in a situation, like if you have a standard waterfall process. What people often do is they implement an emergency change request process, just in case something goes wrong. 

Well, you know what? It's inevitable something is going to go wrong, just like in the software development and delivery process. So just operate in that position, so you're exposed to less risks when the Covid monkey comes along and starts banging on you and your company.

Sacha Labourey: That's great, yeah. I really like it.

Brian Dawson: So before we go all the way into the future, I think you've proven with your work with JBoss, some of the things that we've seen were passed, with our approach to CI/CD here, that CloudBees has been able to kind of understand where the software industry is going and what it needs. So to that end, when we talk about Covid, are there any technologies that you think companies should be looking at to future-proof themselves against recessions like we've experienced with Covid?

Sacha Labourey: I think there are two aspects to this. There is a pure technology angle and then there is what you do with this technology.

Brian Dawson: Okay.

Sacha Labourey: We should start with the last one because that's the most important. What are you going to do? Just before, you said, "Get ready. Plan for those situations to come." Well, you should do the same when you think about what you're going to be doing. You can be the travel industry. You can be in any industry. Some will be more impacted than others, but you have to think right now when you create your product. And you don't create product just for the sake of creating product. You create product because you have a plan, so think about those plans in the context of a Covid type of situation. 

The US is talking about a second wave. Well, we'll see. Maybe it's a single big wave. Who knows? So we need to think about what's going to happen if this lasts much longer, much, much longer. So everything we do needs to incorporate that notion of being resilient to those situations first and foremost. 

From a technology standpoint, I just think it made the cloud so much more obvious. The cloud is a perfect example of what you need to use. Are you going to stack more servers on-prem and try to find people to –? Well, if you need to plan for people not being able to do that, don't think about it in the very first place. Directly go to the cloud. 

When you think about, quote/unquote, remote employees or distributed workers, well, it's crazy to think they need to upgrade their VPN software in the first place. What Covid showed us is that remote was actually the office. Remote was a datacenter. The cloud was the prime location, because that's where people are. When you're working from home, you're part of the cloud. When you're connecting to your datacenter, you're connecting to some strange bubble somewhere with bad Internet access and bad latency because it's just a datacenter, not the Internet. So the cloud is great.     

I think obviously – and I'm preaching because I'm on DevOps Radio, right, but anything around continuous integration helps. You need to get that better app. No discussion about that. We're well past that. 

Then you can have your – I'm not going – [indiscernible] – around Kubernetes and things like that, because in some ways it doesn't really matter. If you get already a resilient way to push software to production and you're leveraging the cloud, I think you're going to be much, much safer and resilient, and whatever the – [inaudible].

Brian Dawson: Thank you for that. That makes a lot of sense. I love the analogy of I'm going to – I'm going to paraphrase it, Sacha, but if you're working remote, you are the cloud. That employee is in the cloud. Your company sort of takes on a cloud formation of its own.

Okay. Sacha, I love the way you highlighted how important we found the cloud was. You also talked about sort of M&A activity, consolidation activity in the software company side of the industry. But there's also going to be changes in the market overall, right, in the businesses that use software to succeed.

I'm assuming you've identified that there's going to be some attrition of organizations, possibly some M&A activity there first. Would you agree with that or what have you found in your conversations or studies?

Sacha Labourey: Absolutely, there's going to be tough situations companies will have to go through. Sometimes they'll be able to go through it. Sometimes they won't. Just look at the unemployment in the US. It's absolutely huge, so that results logically in less consumption, that results in – you know, it's one big assembly line at the end. The domino effect is very real. So yes, some companies will struggle very much.

Brian Dawson: So what do you think? And it's no surprise to you. I've shared some of my ideas, but I'd like to hear yours. What do you think that means in terms of this thing we call DevOps and what we've been pursuing with this? Certain organizations have focused on applying CI/CD and DevOps principles and practices to deliver better software faster. How does that converge with these market disruptions?

Sacha Labourey: It's huge. It's huge, and we were talking a bit about that before. The thing that companies realize is that if there is one thing they need to develop that it's really software delivery, getting that and build that muscle for real, not just for show, right. Everybody has a POC working somewhere, where they do things in a nice way. Now, we're talking about degrading your entire IT to do the freaking right thing, and now is the time. 

I even talked to airline companies. They're saying, "Yeah, we had to let go of some people because our cost structure couldn't handle that, but we're also thinking that it's of huge importance to stand back at focus on the core improvements we can make to the way we deliver software, because now is the time, essentially." 

There's a radar right now where it's coming. So there is limited activity. Now is not the time to look at the ceiling and do nothing. Now is the time to get your ducks in a row and be ready for it. So yeah, we're definitely seeing this and it's the right thing to do.  

Plus, one thing I want to add, sometimes I see a lot of the DevOps and software delivery automation type of discussion being around the, "Oh, we're moving to team A and B," which is a cloud, "It covers us. We're going to do everything – we have some sophisticated stuff." 

Now, you shouldn't stop there and the companies we're seeing don't stop there, because those cool those cool projects, they're one percent, two percent of the total applications they have. So what do you do? You know that you're actually keeping hundreds of people busy just to maintain a release and make sure you get to keep the lights on, on those 98 or 99 percent of the other applications. 

So what we're seeing is at the organization, obviously, they want to make sure the next generation stuff is done right, but they also work hard to make sure that all of the 99 percent are also done right, are automated, because that's a way to actually extract the hundreds of heads you need to actually start innovating better. 

Sacha, this is really a reality that, yes, it's absolutely required that you are making an investment in the future and becoming cloud native, being able to compete on that front, gain the efficiencies of that, and also weather things like economic downturns better. 

But there's the reality. Every major company has a hybrid portfolio. You have mainframe applications that don't naturally come to mind when you say, "Let's do DevOps." But it's important because, look, when you do encounter disruption, you have to apply – you're going to be in a better situation if you applied some level of what we've learned to be modern and best software development and delivery practices.

I know I had the privilege of working with or on the Subversion project or the company that founded the Subversion, and working to port that to things that you wouldn't think about, to support SAP and embed it in the business object solutions, to build a version for AS-400 mainframes, to put together a Jenkins-driven CI/CD process for AS-400. 

These are the types of things where – and I see Sacha looking at me like, "Man, how long is your answer going to be?" 

Sacha Labourey: No. I want to buy it. I'm like, "Wow. That's cool." 

Brian Dawson: Right. Look, we're not saying you're going to be that, look, full get ops framework. We're deploying to production 1,000 times a day. Well, with mainframe and batch processing you can. But look, identify the practices that are working for the modern portions of your portfolio, and see what you can apply across the rest of your portfolio, so that you have resiliency across the board, not just in a single purpose. So that was the question, Sacha. What do you think? Do you agree? 

Sacha Labourey: I disagree. [Laughs]. No, I agree, obviously. But you made a good point with the updates and upgrades. I think sometimes that's a fear for an organization, because they're going to tell you, "Yeah, but Team A is doing blah. Team B is doing extra-blah, plus some of that. Team C is using that bizarre tool," and so on.

Sometimes some of those approaches feel a bit like, "Oh, let me push this magical box and everything is going to be automatically taken care of." But there is so much diversity in an organization. You have so many different viewpoints to take into account.

The question is if you step back, how do you create that massive workflow. That's going to go from source code or an ID to production, and along way it's going to consume a bunch of different tools, extract knowledge and know-how from lots of people who do it manually today. 

Sometimes engineers talk about it as a bus test. Any of your engineers should be able to go under the bus, and you should still be able to really – 

Sacha Labourey: So it's the same thing here, right. Extract this expertise, because if you interview people in the organization, it's amazing to see how siloed they are, especially for very mature software. If you ask them, they'll tell you, "Yeah, we do all of this." They have extreme knowledge about the small areas they work on. Then what do you do after that? Well, we push it into a repository and it's being consumed. By whom? I don't know. 

So extracting all of that, going through interviews and making a real process makes it possible for you to see sometimes how silly things are, how much it can be improved, but not in a way to criticize or make people feel bad. It's because when you're siloed, myopic, you end up making decisions with what you have. So expanding the scope and then being able to automate and extract that expertise makes things a lot more easier.

Then it's fine. You're going to have lots of processes that are not automated, where you're still going to get plenty of manual processes. That's fine. Now they're identified and it's on you to decide where you're going to invest the next mile of automation. This app, that app. It becomes a choice.  

Brian Dawson: Okay. I appreciate that and I agree 100 percent. I can probably have another hour answer in response to that, but thank you. I think that's absolutely important.

So now, grabbing your crystal ball, Sacha, based on experience of course, are there any predictions you have about the state of the industry stemming from this current economic landscape? I.e., we come out of this, whenever it is. There's some reactions and shift in the market. Then if we look 6 to 12 to 18 to 24 months out, you choose, what are some predictions about what things will look like? 

Sacha Labourey: I think it might seem obvious, but I know that a lot of people and a lot of listeners actually struggle in their own company to push the DevOps agenda. They struggle to make people realize that software is eating the world and it's very important. 

So good news number one is you just got huge help from the current situation. Every CEO, every CIO who did not realize that software is eating the world and it's a way to get differentiated and survive through those situations, move on.

I'm a bit harsh, right, but that's like the last call. It's a last call. So I think every organization got the big memo loud and clear. You better get ready and do software well. This is a key differentiator for businesses.

I also think it's been a huge push for cloud. Every organization who thought there were big enough to be the cloud, they just have to understand they are remote. When you have thousands of your workers or hundreds, if you're smaller, of your workers working from home, your code is freaking out there. Your code is in thousands of legal houses and apartments across the country, across the world. People have access to your data left and right, maybe not all of it, but they do because they need to test software. 

So how can you come with a straight face and tell me that you need to put things on-premise because it's the right thing to do? It's what they should do.

Brian Dawson: Because it's the only way to secure your code, so it has to be on-prem, right?

Sacha Labourey: It's out there, you know. Every line of code is going to be on the hard drive of thousands of your employees all over the world. The same for the binaries. So if per user is the only reason why you don't want to go to the cloud is because of security concerns, you have read the press release. So I think that's a big push as well.    

And, frankly, I think it's also time where a lot of people who were struggling in those companies now will become the change agents. Great times are coming for a lot of you who are struggling pushing the agenda of more software, better software, higher quality of life and so on. You were ahead of the curve. 

You have been doing this for a long while already and you know what it's about. You are the changing champ and you can explain to the rest of your organization how things work in a remote fashion, because lots of developers have experienced that. But was it the case for the marketing team in lots of organizations? Was it the case for the sales team? Probably not. So I think it's really going to empower the software side of the house quite a bit, and I know a lot of organizations need that. 

Brian Dawson: Thank you. In a classic fashion, you got me thinking about the fact that, similarly, people that have sort of kicked the can down the road or resisted DevOps transformations or people that have had struggles getting that to happen, the same thing, it sounds like, will kind of apply to whether or not companies have tended to culture. There's a significant overlap between DevOps, a culture of trust, collaboration and experimentation, so a big overlap between DevOps and culture.

I'm going to propose and see if you agree or disagree – I'd love to hear – that companies that weren't traditionally working remotely, the same way they'll now see the value in DevOps in terms of process and practices and technologies and _____, this also may be an accelerator, enabler for really forcing people to reconcile their culture, which will help better the organization in the long run, but also has an accelerating impact on DevOps initiatives. Any thoughts on that, agree, disagree? 

Sacha Labourey: I think you're making a very good point. It tends to pretty obvious for distributed organizations because it's so mixed up. But there are very different things in lots of organizations, the way you work, the way you do DevOps as a culture, the key tenets that you care about and that you want to expose as an organization. They all very much need to be aligned.

I think it's also harder in some ways to have a strong top-down culture in a distributed company, because you're going to have to set the horizon. You're going to have to tell everybody, "This is where we're going as a team," and everybody will have to make a ton of decisions every day, micro-decisions as to what gets them closer to that end goal. That culture is only possible if your culture is not some kind of really strong top-down culture. Otherwise, those micro-decisions are not going to happen and that's going to slow down your execution. 

Brian Dawson: Great, yeah. As usual, much better said by you than me. I did not prepare you with this, but one of the things that I tend to do is completely blindside my guests, just to make it fun. No, it's not going to be anything crazy. 

We have a couple of things we ask every guest. One is about DevOoops moments, not DevOps, but D-E-V-O-O-O-P-S, DevOoops. And these are challenges that you faced or, frankly, places where you've screwed up in the industry, but you drew from that a learning that helped you be better. Do you have anything of that ilk that you could share with your audience? 

And for people that don't know, Sacha not only has spent time as our CEO and a CTO, but he's a developer. He's a practitioner. So, Sacha, just to continue to give you some more time to think about it, answer it from a developer's perspective, or in fact you can look at it from a CTO or a CEO's perspective. But what's a time that Sacha Labourey has screwed up and learned from it, and we can all benefit from that? Or at least we can get a good laugh.

Sacha Labourey: I'll tell you one story, but it's a very old story, so it was well before DevOps, but now that I look back, it makes me understand why we're doing all of this.

It was probably '99 or 2000. I was actually working in a company doing digital TV, not the digital TVs themselves, but everything around the EPG, the electronic program guide and so on, how you encode the signal with – it was the digital and the signal and so on, and you had lots of different getaways from Philips or whatever. Those were really like mini-hubs that had to coordinate a lot of different encoding equipment and so on. So it was pretty significant. Nobody likes to see a TV stream down, right, when you're a TV operator broadcasting by satellite and you've got hundreds of channels not working. That's an issue.

So I was on this project. I was doing C++. I was doing Cobra. I had been installed by a consulting company as a C++ developer, which I had absolutely never done. So I had bought this big book on C++ from the founder of C++, and I was reading at lunchtime, hoping that I would need to do C++ before I was done with the book.

Since I didn't know the language well, I ended up having a bunch of memory allocation issues, this is when you release a proxy. I kept sending files to the consultant that was working for our company and was in Turkey working in a basement, where it was like 16 degrees Celsius and was releasing new upgrades and could roll out. 

He was so nice. He would call me, "Hey, Sacha. Yeah, I fixed the bug that I told you about, but now it runs for about five minutes and then it crashes. So I'm restarting it at this point. It's all good." He was so nice with me, telling me that it was absolutely okay to restart things and so on, but it was a shit show.

The bottom line is that he was so nice. He invited me to come to Istanbul, "Come to Istanbul. That way, you can fix it with me onsite." 

Brian Dawson: You can sit in my basement with me.

Sacha Labourey: Exactly. That's what I ended up doing, going to Istanbul to work on it. I discovered one thing, which is empathy for the field, empathy for the people working in the trenches, in the datacenters doing it, making it happen. It was so easy to be your debugger, your VCR studio debugger, trying things out and saying, "Yep, this one works," and you don't realize what it means for the guy who is actually trying to make it happen, the pressure from management.

So I think it's worthwhile to make sure that developers and engineers in general go on-premise and visit customers and develop this empathy for things, because I've DevOoops'ed quite a bit onsite by producing very shitty software. 

Brian Dawson: That was a great one that hits a lot, right. It's actually breaking down silos with individuals as a representation. It's having awareness of how your software is actually used. It's testing in production to a certain extent. It's analogy of it. And it's something that we talk about, which you and I talked about I want to say a couple of years ago. It's being able to see how your software impacts people. That helps you make better software, but also helps you feel better, I assume. Like you just said, it was awesome to be the debugger. 

So great. Thank you. That was one of our better DevOoops moments.

Any final thoughts for our audience, in particular in regards to the economic situation, Covid, and the power of software delivery?

Sacha Labourey: Just one thing, which is not at all software-related. Take care of yourself. It's easy in the current context to not step back and not look at the big picture, especially if you work in software. I think you're more protected in some ways than others. We tend to be a bunch in software than for other categories of jobs.

So take of yourself. Take care of others. That's how we're all going to go through this. There is no way we're going to go through this in part, just some part of the economy, some part of the jobs. It's the whole thing. We're talking about nationally, of the country. Well, the national becomes the sum of everybody, essentially. 

I know it's a period that is challenging, so people should just rely on themselves to take it easy. Not the message I want to send to employees, but it's important. Take it easy as in take care of yourself first. Because if you're not well, you're not going to work well and so on. So spend the time to make sure you take care of yourself and the people around you, and a lot of things will go better. 

Brian Dawson: Awesome. I agree and appreciate that, Sacha. Thank you for your time and insights. It was a pleasure getting the chance to talk to you this morning. I hope you enjoy the rest of your Friday and the rest of the week.

Sacha Labourey: Thanks a lot, Brian. Great talking to you again.

Brian Dawson: Thank you.