Building Business Resilience in the Cloud Era

Podcast Transcript

Sam Massey: If businesses needed a reminder of how critical it is to be able to act quickly amid volatile conditions, the Coronavirus pandemic has certainly provided it. The outbreak, and its subsequent economic impact have upended long established business models, supply chains, and consumption patterns virtually overnight. The need for flexible cloud based computing architecture, and the resilience and responsiveness it can deliver has never been more apparent. 

Welcome to Pragmatism in Practice, a podcast from Thoughtworks, where we share stories of practical approaches to becoming a modern digital business.

I'm Sam Massey, and I'm here with Kief Morris, Principal Consultant at Thoughtworks. Hi, Keith. And thanks for joining us.

Kief Morris: Hi, Sam. Thanks for having me here.

Sam: So today, we're talking about cloud. And you're one of our cloud experts at Thoughtworks. And specifically, we're going to start off by talking about this current climate that we're living in, Coronavirus particularly. So in your opinion, how do these current circumstances support or undermine the case for cloud adoption?

Kief: I think they support it. And I think the situation that we have is that, the pressure that a lot of businesses have been put under in terms of people moving to digital and online. So I'm thinking about retailers to a certain degree, and finance, where you have to do your banking more online potentially. Healthcare definitely. There's a lot more emphasis of people going online to do things that they would have been able to do offline before.

And so that means that organizations need to have their IT ready to cope with scale, and with a high demand, and high pressure. And cloud is the obvious answer for that, right. And I think one of the things that we've seen is that organizations that are already on cloud, who are using the cloud, actually found that they weren't able to cope with the level of demand that they'd had. It's not whether or not we need cloud- Yes, we need cloud. But it's also about- how do we use it? How do we actually get those benefits of being able to scale up and down. I think that's one aspect of it.

Another aspect is just the ability to be able to change quickly. So what happened with a lot of organizations when lockdown started, and everything happened very quickly, and suddenly there was a demand to maybe offer services in a different way, or offer new services. Again, going to the retail, here in the UK, there was a big pressure on the grocery retailer. The majority of whom were set up to do deliveries, and all these kinds of things. But there was this pressure to say, "We're going to have to prioritize, especially because we can't handle everybody jumping on to order toilet paper, or whatever, right. There was the feeling that, oh, we want to offer to deliver to more vulnerable people, people who are older, or what have you, as priority.

And that was just a feature that obviously wasn't in their systems at the time. So how can we roll it out quickly? And quickly is not a few months, right. Quickly was like, "We want to be able to do this next week." And so there again, I think part of the role that cloud plays in a digital organization is making it easier to respond rapidly when you need to change something, or add something, add a new product, or what have you.

So these are all things where the cloud is there to help with these things. And under pressure, I think a lot of organizations found that we weren't really able to get what we needed out of it. And so I think what's happening now that the dust is starting to settle a little bit is, we're thinking about, Okay, so how do we better prepare, whether it's for similar situations, or other situations? We want to be able to respond, and handle pressure, and crisis situations more easily.

Sam: And most of the technology industry probably thinks cloud is a settled area, and it's onto a new and next thing. But adoption still remains, in some respects, it's quite limited, and quite challenging. Why do you think that that is?

Kief: I think there's a few aspects to why adoption maybe isn't where it could be. I mean, part of it is just that there's plenty of old existing systems that are running in data centers. And It hasn't always made business sense to say, "Let's just completely move those into the cloud." Which might require a lot of work to re-platform them, or even to re-architect, redesign, re-implement parts of the systems in order to make it work on the cloud. And the business case wasn't necessarily there to say, "Hey, let's spend money to do that just for the sake of being in the cloud." I think that was one aspect.

I think another aspect is even getting parts of our systems into the cloud, again, you have to think about, how do you get that scale out of it? So one of the promises of the cloud that gets touted is the auto-scaling, right. So the idea that, when you get a whole bunch of extra traffic hitting your system, the cloud will automatically add new resources, more hardware, more memory, whatever, to just automatically scale up.

But that doesn't come out of the box. And I think in a lot of cases, especially business leaders who had funded, "Let's build things into the cloud, move things onto the cloud" assumed that they were getting all of those promised features just as a byproduct of having moved into the cloud. And actually, turns out there's a lot more you have to do to really get those benefits, and to exploit them properly.

Sam: Let's talk about that. I mean, so what, in terms of engineering capabilities, how should businesses adapt to create a bit more of a winning strategy with it?

Kief: I think part of it is, we have to think about how to use technology to enable change in a way, right. So what I mean by that is, in a traditional world, we would buy some hardware, we would put it into a rack, we would install an operating system onto it, we would install our software onto it. And if we decided we needed to add more capacity, we would go and buy more hardware and put it in the rack. And it was a very manual process.

And so the cloud ... The simplest way to use the cloud is a lift and shift idea, which is, you basically use the cloud to create servers in somebody else's data center, virtual servers in somebody else's data center. But if you don't change the way that you manage the operating systems, and the middleware and the applications, then It doesn't look any different in terms of how you can use it, and the ability to scale.

I think particularly with applications, the way that we've written applications for decades is assuming that you deploy it, and it runs in one place. And so the whole idea of the cloud native software is the idea that we're going to write our software in a way that it assumes that extra instances might be created on the fly in different places, and in some instances might disappear either because something goes wrong, or because they're terminated.

And with cloud native software, you're architecting and implementing your applications in a way that this is the normal thing, that everything is very fluid underneath it. And so it requires really having to look at your software applications, and working out whether, are they going to be able to run in the cloud natively, or do they need work in order to do that?

Sam: It's not a change at the very top, as in, literally within the cloud, it's actually a change within all engineering, is what you're saying.

Kief: Yes.

Sam: Yeah.

Kief: Yeah, absolutely. And I think that points to the idea that it's not just a change in technology, it's not just ... I think, often we want to think that adopting cloud, or adopting some kind of cloud related infrastructure, or any of these things that are emerging now, it's like, "Well, we get this thing, and we install it. Then that's cool. The technology is enough."

And the technology isn't enough. It is, how do we work as an organization down at the level of the teams, how are engineers working with the infrastructure? We talked about infrastructure as code, which is a way of taking advantage of software engineering practices to how we build our infrastructure. It's at those team levels, at the process levels. So how are we thinking about new features? Are we looking at the end to end journey of deciding that a new feature might be useful, and then working out how to test that, and how to get a simple change through to be able to see whether that lands well with the users, and how we have to adjust that.

And so it means that we have to change sometimes how our organizations are structured. That the old siloed ways of looking at everything just aren't going to cut it. They're not going to help us get those benefits.

Sam: What would you say are some of those biggest changes, organizationally, in terms of structure, what sort of changes are businesses having to go on when they change their operating models, and they adopt to using cloud?

Kief: I think one of the big changes we see is the ... There's the phrase, "You build it, you run it." Which I think was coined at Amazon. And it's just the idea of moving away from the divide between the development teams who build software, and operations teams who run software.

And the whole DevOps movement was basically about, how do we bring these together and make them work? And I think that has so many ramifications. In particular, when it comes to things like governance, and often compliance, and things like that, that we need to think about, how do we make sure that the people in those teams have the right skills? That they have the right disciplines? That they have the knowledge about how to adhere to policy, and how do we have governance in place to make sure that, if you've got now 20 different teams all making their own software, and pushing it into production, that that's being done responsibly and safely?

Sam: Question here around highly regulated industries like financial services for example, how they can balance that need for security and compliance versus the pressure for self service, on demand computing. How can these types of enterprises successfully do that?

Kief: I think the way that we tend to advocate, certainly at Thoughtworks, we're big believers in continuous delivery. It's something that we brought into the industry as a way of doing things. And a key element of that is the pipeline. And this is basically about automating the flow of, as a developer, I make a change to some software code, how does that get into production environment? We want to have an automated process for that to happen, to where we do some automated tests happen along the way, and automated compliance checks can happen along the way.

And that creates a shift in that divide, because the classical way of doing governance on this was to say that you had to have somebody; a team, act as a gatekeeper. People or a team acting as a gatekeeper for every change, and every change, they look at it, and examine it, and decide whether or not to go through.

And I think that manual governance and compliance checking has often not worked out necessarily as well as we'd hope, because people are fallible, people take shortcuts, and people often don't have the context, and especially when there's a high pressure situation. We've got to get this release out the door. You have somebody go and do a review of the code, and they may not have time to understand fully all the implications of what it needs to do, and why things are being done the way that they're being done.

And also, you may have, where you discover issues, and the pressure is such that it's like, "Okay, we're going to put that on our list of known issues. Some executive is going to sign off a risk acceptance of that. We're going to push it through to production anyways and clean it up."

So you get this because it's a late check. It happens late in the process. And so we have to pipeline the idea. And with continuous delivery, the idea is that we have ways of checking as we're working on the code, and giving us a report to tell us, "Okay, this code change that you've just made as a developer is violating a security policy. So you go ahead and fix that now rather than waiting three months when we're about to go live to find out that it's not compliant." Because this way, you're building security, and compliance, and quality in as you work.

And then the other thing that this pipeline can do is, it actually gives you automation around the compliance process. So what you can do is to say that, in order for a change to go into production, a certain number of people, or a certain authorized people have to approve that. And you can use your automated systems to capture that somebody has reviewed it and approved it. You can also capture that tests have been carried out, and you can capture the tracing of changes.

What this means is When you have an auditor come in and say, "We want to check how compliant you are." You can give them, for everything that's currently in your production system, you can show them the code, not just for the application, but for the infrastructure, for your security policies, and everything around it that is reflected in what's in production. You can show who made that change, who made each change to the system, when did they make it? What tests were run? Who signed off on it? What were the results of the tests? And so you have a very, very strong and robust audit trail that tends to be much stronger than some of the manual processes.

Sam: What do you think the dangers are of becoming entangled with just one single cloud vendor? How do you ensure there's a portability?

Kief: So portability is an interesting one. There are potentially risks around getting entangled with cloud vendors, and we always worry about vendor lock in. Are we going to be stuck with one vendor, and they're going to raise prices, and it's going to be difficult to move? And I think that is a risk. I think it's a difficult risk to get around in any case, because there's only a handful of cloud vendors in the first place.

And so if you've got two, three, four players, it's unlikely you're going to get a situation where one of them decides to really jack up the prices, and the other ones don't, because then they're going to lose out, right. So I think we have a certain amount of competitive pressure there. And if we don't, it'll be a failure in terms of if you've got an oligopoly, cartel situation,where all the cloud vendors say, "Well, let's all jack up the prices, and not worry about competition." So that's a risk.

And I think overall, when it comes to thinking about portability across cloud, I think what I tend to advise is to focus less on technical solutions in the sense of, is there a product out there that we can buy, or adopt, that's going to let us run across the clouds, the different cloud vendors? Because in that case, you tend to end up with a lock in too on that product, right.

And I think we have ... With Kubernetes we kind of, had the promise, because Kubernetes is now something that runs across all of the clouds. And so we think that's an answer to cloud portability. But in practice, it's actually quite different across the clouds. And there's also a lot more to it than just what Kubernetes does. There's just a lot more pieces to the puzzle that you have to be on top of.

So the real key to Being able to balance the different cloud platforms is just simply your teams, or people having the capabilities to build, and understand what they're building. So in other words, I think there's a certain layer of knowledge that you have where, if you understand one cloud, you're able to apply that to other clouds. And the implementation details can vary across the different vendors, but that's the kind of thing that, if you build the right competence in your organization, you should be able to handle that.

And I think one of the key recommendations I have on that, to people, is always to make sure you are building your own people's competence. So be very wary of bringing in a vendor. And as somebody who works at a vendor, in a consultancy, this is ... Something I recommend to my own clients is, don't bring us in to build and install something for you and then go away. Bring us in, or bring somebody in who is going to help your people build it so that they understand what they're building, and how to carry on building, and changing and adapting it as they go along. And that's your best defense against any kind of vendor lock in, is having your own people understand the stuff that they're building and using.

Sam: Yeah. Not a one and done solution, and off they go. It has to be a continuous change, continuous way of doing things. I'm going to talk a bit about, or ask you a little bit about different cloud strategies. For example, public versus private, poly, and multi cloud strategies. How do organizations, or how should they plan their investments among these various options?

Kief: As always, it comes down to the cost, benefits trade offs. I think this is one of those things where you have to take your time a bit to learn. So it's one thing that some organizations do is, they want to go really fast, and go all in on the cloud quite quickly. And I think what's important is to build up your knowledge, and your capabilities as an organization to understand.

So one big topic is cost. So often times, there's a feeling that, if we move our stuff from our data center into the cloud, it's going to be cheaper, because we don't have to own the hardware, and run those data centers, and leverage the vendors, we'll leverage the cost, and have the economies of scale that we can't have as a similar organization.

What tends to happen in practice is that the costs actually can go up quite quickly. And partly that's because of just the opportunities that you have once you move stuff into the cloud. You can very easily do more. And so you want to do more. And that means you tend to use a lot more than you think you might when you're first planning.

The other thing is that the costs are just different, right. So obviously we're talking about going from a CapEx world where you're buying hardware and depreciating it over time, to an OpEx world where you're paying as you use it. And there's a lot of costs that come out in different ways. So you no longer have to worry about, not just the hardware, but the people who are maintaining that hardware. That's a whole area of skills and head count that you may not have to worry about.

But there's more skills and knowledge that you need, because you now have to be able to run things on the cloud itself. There's a lot more that you have to do to use the cloud than you might hope. As in, you need people who really understand how the cloud technology works, and how to manage it, and how to use automation. And so that's a whole new skillset that you have to build up.

And you need to spend some time to get to that level of, okay, we have some stuff running in the cloud initially. It should be stuff that is important to the business, that has enough value that you take it seriously, and that get some real learnings from that. And then you can start to scale that up.

And then I think that's where you start thinking about, "Okay, do we want to use multiple clouds? Do we want to go poly cloud? And I think there again, you can do that on a pragmatic basis. I think you look at the things ... Either the parts of your IT systems which desperately need to be replaced, the old legacy technologies that you're not able to hire. This happens a lot with mainframes, and COBOL based things where it's like, "We have to move off of those because we no longer have people available to maintain those." Or new opportunities where some of the things that we need to do, whether it's because of new consumer technologies, or what have you, like mobile. We have to build new things for that anyways. We can build that on the cloud.

As you're either rebuilding these parts of your system, or building new parts of your system, you may decide to target some of these onto different cloud vendors to harness some of their advantages. So say one cloud vendor may be really good for the meat and potatoes, virtual machines, and compute, and so on. Another vendor might appeal to you for the machine learning and data processing. And so maybe you want to experiment with that, with some new machine learning oriented types of initiatives.

And so I think it makes sense to explore different clouds. I guess part of the whole thing with the multi cloud thing that people want to do is to ... One of the aspirations is to think we're going to make our applications so that they can just run anywhere. You can move them around. I think a really valid way to look at it is more the poly cloud approach of, "Let's build different things on different cloud platforms so that we can build up the competence in each of those platforms so that we have that knowledge in house, even if it's in different groups. And we can get the best things, we can use each vendor for the thing that they're best at in a way."

So I think this is all part of the mix, and it's all going to be an evolving thing. I don't think we can sit right now at the beginning and say, "This is exactly how we're going to use different clouds and different applications." I think it's all about learning, and how can we work our initiatives now, and put them in place, so that we learn as much as possible about how stuff works in this environment, and how the different vendors work.

Sam: If you had a crystal ball, and you look a few years into the future, maybe three or five years, what do you see the biggest changes in terms of the ways that enterprise adopt and deploy cloud?

Kief: So my particular area of interest is around automation, and how we automate to build and run the cloud. And I think there's still a long ways to go in terms of how to do that, because that looks an awful lot like software, like application development. A lot of the things that we're learning now with infrastructure code are things that we learned 10, 20, or more years ago in the application software world. So things like, how do you manage versioning, and refactoring, and a lot of the testing, and all this kind of stuff. How do you manage that with infrastructure?

So I think that's something that will evolve quite a bit. I think the other thing is that it's the shift in how much we have to worry about, right. So the initial idea of cloud, the thing that got all this started was, do we really need to worry about hardware? Do we need to worry about whether we're buying servers from HP, or from Dell, or from Supermicro, or whoever? Or can we let somebody else worry about that?

And certainly at the level of servers, at the level of compute, and the level of storage, and increased networking, there's a lot of that now which has become commoditized to the point where we just don't have to worry about that. And that's been the first layer of it. And then the next layers become this whole cloud native computing thing with containers, and clusters, like Kubernetes, and these kind of things where you say, "Well, now let's move up the ladder and say I actually don't want to have to worry even about virtual servers, I don't have to worry about the details of that. I just want to have ways to deploy applications, and to make them run, and to have that handled for me."

And I think right now, that's not as mature, in spite of what I think a lot of vendors would like us to feel that it is mature to where it is, and also a commodity, you can just buy it off the rack and go. It's still at the point where it's just changing so much that we have to know ... As an organization, we have to understand more about that, and have a little bit more ownership of that than we do necessarily for the hardware levels, and stuff.

So that's what's in progress now. And then if you look forward, you've got the whole serverless thing, which is to say actually, I don't even really care about applications in the sense of, I'm going to write something that's going to be deployed to a server in these instances, those instances, how many instances? I just want to write a bit of code, and push it, and it will get executed. Obviously it's here now as in, there are technologies and platforms where you can do that. But I think it's still even further away in terms of, how do we manage things like testing, and quality management of that kind of code, and versioning, and all the basics?

So I think that's really interesting, and that's something that we'll see a lot more of. But it's all just a shift of, we want to offload more and more of the things that are just really should be commodity, so that we could focus more on what's the closest to our customers, and to our business.

Sam: I want to come back to the first question again, only because, as you were talking there, I was just thinking about the future state, and then current state. And within Thoughtworks, we've heard of things that have been happening with clients, but also other businesses where they've been doing very well throughout this crazy time that we're having at the moment with the lockdown. And how more digital services are just increasing, and probably will still increase, because we know that there's going to be a new norm to working, and living, and accessing anything online.

Where have you heard of the successes, and in some cases, the other end of the spectrum where because businesses have not had their cloud strategy in place- Have you heard of those exceptions where you've heard an example you think, "They had it right, they knew what they were doing, they had their cloud strategy in place"? But then on the other end, they thought they did, but actually, they haven't, throughout this very extreme time that we're living in.

Kief: So, the main example I can think of - Zoom has got the mine share out of all of this. And a big reason they've done that is because they had their cloud strategy in place, and so they knew how to use it. Although, they have a combination. They've got the hybrid approach of, they have some things running in data centers, and some running on the cloud. But they were prepared with, "How do we scale up? How do we use the cloud to scale up quickly if we need to?" And so that's worked out quite well for them.

I think the examples of organizations which have struggled a bit more, it's mostly been in the retail space, and particularly living here in the UK, and using grocery services and all that, I've seen most closely there, where to one of the major companies in that space, Ocado, which is a pure play digital online grocery delivery company, they actually had to shut down for several days in order to retool.

I think it's tricky, because it's very easy, a lot of people in the industry popped up and said, "Well, they should just be able to automatically scale if they're using cloud. It should have been easy, right." And I think that's easy to say, and it's much harder to do. And especially when you have to think about things like, there's obviously the offline as well as the online part of a business like that, where you only have so many drivers to go out and deliver.

Sam: And it's a business model which is ... You're going between physical and digital in the business model sense, and with the way that the business runs. But in terms of Zoom, you never think, "Oh, I'm just going to go and deliver my Zoom software by hand to this customer." It's all done online. So therefore, from the inside out, Zoom, you would say, is a technology company inside out. Whereas, some grocers don't consider themselves as technology companies yet. However, they might have to in the future if they're going to start future proofing their digital strategy I suppose. And maybe that's potentially why some have failed, and some have succeeded.

Kief: Yeah, I think that's true. So if you look at some of those companies like an Ocado, they are a digital company as in, they were established in the digital age, and that was the forefront. It wasn't having to deal with the legacy. But there's the other parts of the system that they integrate with. I think integrations are a big part of it. So again, if you think about that grocery delivery, well, you've got to integrate with your inventory systems, right.

So it's one thing to say, "We're going to let 20,000 people jump onto the system and all start adding and removing things to their shopping baskets at the same time." But how do you synchronize that with actually having that awareness of, "Well, what do we actually have sitting in the fulfillment centers? And how do we reconcile that?"

And so you have a lot of those integration points which can turn out to be the bottlenecks. And so that may be where those kind of organizations have to think about the next level. There's probably, there's the next level of, "Okay, are there things we need to do with those other systems we're integrating with? The back end systems which we thought - well, our digital focus is on what's right in front of the users, and the back end systems maybe can come along a bit later. Well, maybe that's going to accelerate now and we have to bring those on a little bit faster."

And then there's also just thinking about, well, how do you deal with this in a way where you know you're going to hit some limits, whether it's because of, again, numbers of drivers, or amounts of things that you have in your warehouses. It's like, "Okay, how can we manage those things more gracefully?" And the things that people have done ... And globally, a number of retailers globally have had the exact same thing of, where you just end up putting a queue, a page, in front of the user saying, "Well, you're number 10,982 waiting for your chance to go and set up your order."

There's probably got to be better ways to do that. But it's hard to come up with those in a crisis. But when I talk to people about becoming a digital business, and what does that mean, and what does that mean when it comes down to the level of what we're actually building, and how we're building it at a technical level, because at heart, I'm a technologist, right.

And I think when it comes down to it, it is about, how do you handle change? And I think part of the pre digital, what I sometimes call the iron age, with cloud infrastructure, the iron age where it was all physical hardware. Now we're in the cloud age where it's all this ephemeral stuff. And I think the big difference is how we handle and view change. In the old world, change was a was a risk, it was something you needed to manage, it was something you needed to control. It was risky to make a change, and it was expensive to make a change. It took a long time. And if you messed it up, then it was going to cost you a lot to undo that, to fix it, to repair it.

And I think the things that we have with cloud now is that the cost of change has dropped to almost nothing. If you create some servers, and it turns out they don't have enough hardware installed in them, you can just edit a file, and click a button, and you're done. And so I think all of the ... Around agile, around devops, lean, digital, this is all about saying, "How can we leverage change and turn it into an advantage to where we can learn rapidly, and then make improvements and really go?"

And so I think at the heart of it, in terms of getting the most out of cloud, I think that's what it's about, is thinking about, how can we really look at the ability to make changes faster? And so this is where a lot of I think what we get into, and we get into specific technical practices that we have at Thoughtworks, and we have our continuous delivery, and infrastructure as code. And even things like test driven development. These are all about, how do you make changes safer, to make them quickly?

Sam: It's interesting that I've talked to a few other technologists about change actually, as a subject matter. And I talked to Ashok about it a couple of months back. And it's really interesting talking to different technologists, and different people not just within Thoughtworks, but outside of the business as well when we've been doing these podcasts, is that that's the big thing that everyone hones back into is the change, and what does it mean?

Quite often, the change that people have to go through, how the infrastructure of the business, how you run your teams, and your strategy. And it's not surprising that you've come back to it, because it seems that that seems to be the most common thread when I've been speaking to people through these podcasts, is that the one constant is change in technology. And you have to be able to adapt quickly, you have to be able to change all the time. It's not a fixed thing.

And how businesses deal with it is obviously based on their success, and how they are able to adapt quickly. But knowing that you will be changing all the time. So I'm really glad you came back to it as a subject, because it's common. It seems to be the common thread.

Kief: Yeah. And I think, in terms of what makes different businesses better at coping with change maybe than others, I think a lot of it comes down to the confidence. And I think that comes from capability. So we went from years back where the whole idea in business was, "Well, we need to outsource technology, because it's not our core competence." And so what I think that's led to is, it's reinforced the scariness of IT and technology. It's like, "Oh, IT projects are going to balloon, and fail, and blow lots of money."

And so it becomes more and more something people wanted to get away from, because it was a scary thing. And the more you outsource it, the scarier it becomes, because the less control you have, the more you've handed it over to somebody else.

Whereas, I think the trend now, the whole idea of the tech at core, and bringing technology as an enabler to your business, or however you want to put it, becoming digital really, is that we want to have the knowledge in house to understand our technology, to be comfortable. And all the practices that we talk about, the things like continuous delivery, and test driven development, all that kind of stuff just to make it ... Change is something we should be comfortable with, and confident to do.

And I think on the Coronavirus, and all that's happened, exactly what you said, most of the stuff that's happened isn't new, it's just that it's happened faster. And I read something the other about how those projections of how quickly certain things in the industry, and the industry as a whole, we're going to take hold. And it's been three, four years accelerated. We're now in a place, with regards to some things, where people expected the industry to be in, in four, five years.

And I think the other thing is that it's broadened it to more people. So a lot of us, we're working from home, working remotely, doing Zoom meetings. You and I had Zoom meetings last year and all. But now my mom is doing Zoom meetings, right. So I think it's taken stuff that was already there, and just pushed it out further, and faster.

Sam: And in some sense it's improved the way that we do things, because there's a stronger case for remote working, where before, there may not have been. Or as a business, we've talked a lot about it, we travel a lot. Well, maybe we don't need to travel as much. Maybe that's not such a good thing for the environment.

And I read a survey yesterday which said that around 50% of people no longer want to go back to an office, they want to work remotely. And you can understand why, because There's benefits to it. The working day can be as long, but you don't have to commute, for those who commuted. But you can be with your family as well if you need to.

There's also ways of doing things. And I work in the marketing team. And we've talked long about, how do we scale, for example, the events that we do? And actually, going remote is actually a really good way to scale events, because you can have more people attend something remotely than in person. And it’s simple things. But then obviously there's always a level of change, and risk that comes with every single type of change that you make.

But I think, in some sense, it has improved. You can see that this isn't necessarily end state. We're going through a change. And we all know that working remotely won't typically happen always through a screen. It might happen in other forms of cross reality hopefully in the future. And maybe that will start being accelerated because there's an opportunity there now. But in some senses, there is an improvement that has been made, because we've been forced, and quite firmly, into this dramatic change.

Kief: And I think on the flip side, I think we'll see some of the value of those things that we haven't been able to do. So there is value in meeting face to face, and even having conferences and events face to face. And I think it'll make us more conscious of those. So we might be able to get more of that out of it. So the next time we say, "Hey, let's do some in person conferences." I think we'll probably think long and hard about, "Okay, what are the things that make this more valuable than doing it online, and how do we maximize that? How do we squeeze the most out of that?"

I remember talking to James Lewis. He was talking about the TechRadar, and how this years, or this previous edition, they did it entirely online, whereas, normally, they get together face to face twice a year to do it. And he said that one of the conclusions they had is that, although they're able to create the radar this year, in this fashion, that there's still a lot of value in coming together to do that. And even though it's fairly expensive, they're saying they're going to continue doing that. So I think that's really interesting to see.

And maybe we don't need to go to the office every day just to sit down at a desk and read our emails, and do whatever we do on the laptop. But there are still things that I think we're going to want to come together to do.

Sam: I hope so. I hope we one day come together and do see each other face to face, in person. Thanks, Keith. It's been really great talking to you. It's been a brilliant conversation, and thanks for joining us on the podcast.

Kief: Great. Well, thanks for having me.