Season 3, Episode 2 - "Does geography matter?" with Sandi Jones, Former AVP, Manulife

Andrew: Hey, it's Andrew and welcome back to season three of Network Disrupted. Where I, along with some very smart guests, help fellow technology leaders, trade notes on navigating disruption in our space. This season, I've set a goal of exploring the issue of enterprise Cloud adoption from as many angles as I can. Today, I'm joined by Sandi Jones, who is both a friend and a former customer as Manulife Financial's, former AVP of Global Network Services. In this episode, we discuss what Sandi learned through the many iterations of Manulife's cloud adoption journey, her approach to federation, and what a business as spread out geographically as Manulife should consider to maintain reliable service delivery. All right, let's get into it. And if you have a moment, please don't forget to leave me a review on Spotify, Apple Podcasts, wherever you like to listen to these. The feedback is always so helpful and you'll be helping more people like you discover the show.

Introduction: Maybe you can give me a sense of the complexity. We love the pilot proofing concept approach. Influences everything, it influences the human experience. There were several failures along the way. We want to be early adopter customers. You are handling sensitive information. Network Disrupted.

Andrew: Sandi. Thank you so much for joining me.

Sandi: Thanks Andrew. For inviting me.

Andrew: We have talked a number of times in the past and certainly we've talked about the sort of iterations that enterprises go through in Cloud journeys. So for a little context, can you tell me a bit about your journey with the Cloud in your career and sort of goals versus iterations.

Sandi: Sure. Well, I like to tell people that my Cloud journey goes back to when we, network folks invented the metaphor of a cloud before what's called the Cloud today came along. And so I was around for the early iterations, like Software- as- a- Service while it was still called other things and seen a lot of change, but the last seven years has been the real big journey for me. I joined Manulife in 2014 and left just last month. And during that time, we really went from a company that was really data center centric with a lot of software that had been developed and deployed in the data centers for years, multiple regions each with their own sets of IT and so on. We really went through that same sort of sequence that you see a lot of companies going through where there's first SaaS adoption, they start plugging into things like Office 365, ServiceNow, Salesforce and so on. Then the next iteration where we started focusing on using Cloud providers and in our case, we focused in on Azure. A lot of my peers that I talked to through the journey were on AWS, Google, some in Asia were on Alibaba. But in general, we all kind of went through the same iteration where first there was a lot of, what we call lift and shift where we just took the same application that was running in the data center on a server or a virtual machine, and plugged it on a virtual machine in a Cloud player infrastructure as a service. So we abstracted that bottom layer, but it was really for the IT teams a lot, like what they were used to-

Andrew: It was back in the... let's virtualize the stuff in the data center.

Sandi: Exactly. Yeah.

Andrew: Same basic process.

Sandi: Yeah. Take the same thing, just virtualize. And a lot of the drivers early on were really... a lot of companies had long time contracts with data center providers. And it was quite frankly, cheaper to run on a VM in a Cloud player than it was in the data center, or so they thought before they saw the fine print and all the hidden costs of not deprovisioning things and so on, but fundamentally-

Andrew: For sure. But I used to be shocked when I would hear a customer of mine would have an option of a virtual appliance or a physical appliance. And they would say it would cost them more in chargebacks per month to run it virtually and physically. Just because of the dated contract with service provider for data center that charged$ 2, 500 a month for a virtual machine or something like that.

Sandi: Absolutely. Yeah. There was a lot of that and colleagues across the industry, it seems to be the same story. We were using different providers in different regions and similar stories but that first iteration was really sort of about moving from data centered to Cloud Platform, but without really changing a lot. And then in the next iterations, you started to see different parts of the business taking advantage of being in the Cloud, doing things like we had one big project that sub and talked about publicly where the software that insurance companies used to figure out how much they should charge you, based on your personal risk. We had dozens of those systems running in all parts of the company, some from legacy M& A activity, others just lines of business. And we were able to feed all of that into a platform in the Cloud that could normalize it and do reporting so that now all those business people were making a risk decision based on a much bigger data pool. And to do something like that in the data center world and ship it all to Toronto or wherever the main data center was and build the systems to do all that. It was really much better suited for the Cloud environment and things that can scale up and down and have hooks into different areas. So you started to see some of those and at the same time Manulife was really aggressive in the Cloud adoption. We focused on Azure and came to multicloud a little later, but there was a strong motivation for the IT teams if they were introducing something new or refreshing, transforming an application. There was a strong push in all the regions to really put that into the Cloud and really do it differently if they could. And we found ourselves often ahead of the curve in that we were pushing the Cloud players for things that they weren't quite ready for because we started a little earlier. And that really hit the network side as well, because we had a very complex network with the eight different Azure regions, four pairs backing one another up and different application stacks in each of those. So it really pushed the vendors. And so along with the whole Cloud adoption from the application side, there's been iterations of what the network looks like and what we can do natively in Cloud versus what we need to do outside.

Andrew: As you were talking, it was occurring to me, so probably the iteration, negative one was some people in the business were just creating subscriptions with Azure or accounts with AWS and trying stuff, right?

Sandi: Absolutely.

Andrew: Because IT was too slow or whatever the case might be. And then now there's some level of standardization. And when you said," And then we went all in an Azure, which isn't unique to Manulife." I mean obviously, the Clouds are competing at different levels. But it occurred to me where sometimes it's frustrating to everybody in IT, decisions are just made. Seemingly at a higher level without context or whatever the case. And with all respect Azure, I've created a lot of success technology in Azure, this isn't in a Cloud provider versus Cloud provider. Microsoft tends to have great relationships with enterprises because of all the value they've driven throughout the years. crosstalk And so I know of... right, more than one case where there's, whatever iteration was going to our data viewers at GCP, or maybe Azure, but then there was just this mandate," Oh no. We're going all in Azure," and those that were creating the technology were like," But we went down this road for a reason." They all of a sudden they had to try to redo and crosstalk try to apply... And that created gaps in capabilities that they pushed Microsoft for. So I'm not suggesting that's what happened at Manulife, but, I seemingly... It's always [ crosstalk 00:07:57] ironic to me that those decisions sort of come top- down sometimes.

Sandi: Yeah. It happens everywhere. And any big decision like that, everybody's not going to be happy about it. What Manulife has done over the years and those iterations is created a really good feedback loop. They have a group that includes the chief architects for all the different lines of business and some of us from infrastructure and so on. So there's a process to go through when those big technical decisions... or ones that aren't quite that big, but those decisions are being made that have implications across the enterprise. But yeah, early on, some of those big bets were made and for whatever reason, I think, as you said, Microsoft was very baked into the enterprise. So you saw at least from where I was sitting, a lot of enterprises went in on Azure, whereas a lot of small and medium businesses went more over to AWS and Google. And of course, as they've grown and thrived, that's put a nice big base of customers there. But it's really something that you can't decide by committee. And at a certain point, I think that those decisions have to be made similar in our security products and things like that, that really everybody has to live with the results. So companies have gotten better and better, I think, at having those discussions and recognizing that just because I'm doing something in the US, doesn't mean that Japan shouldn't have a say in that. They might have a very different situation. And so, I've seen Manulife and other companies I've talked to sort of evolve that internal communication that's really, really important. And those pros and cons that come along.

Andrew: Right. I think some of the capabilities they have are so differentiated that they're the obvious choice for this, this or this. And I think when you look at that sort of broad... we've decided, and yes, at some point it'll be multicloud, but we've decided to go in all in somewhere. Well then the question comes," Okay, so maybe one Cloud provider isn't as good in this area, or doesn't have a long term storage solution or doesn't have... There's something they're lacking." And so well, part of I think what they're really good at is adding those services over time when they're pushed by their customers. But two, so you live without it, you do something else until it exists, or there's a little multicloud in the process. In other words, I'm sure I'm going to piss off somebody, but I think they like to believe they're more differentiated than they are. There's technologists that can craft solutions given the pretty big tool box they all come with in terms of services.

Sandi: Yeah. They're all well situated to add the features as needed. It's not unique to Cloud players as well. My advice to people choosing technology is look past the current feature set. Because a year from now that could be equal. Look for, what's the real differentiator? What are they able to do that somebody else can't do? But the other thing at the beginning of the Cloud journey, there was a lot of talk that," Well, it's just Cloud. It's all the same so it doesn't matter." Before those companies really got good at telling their particular story. And a lot of the early part of the Cloud journey and still today, companies that are just adopting, they sort of go in thinking," Okay, well, it's in the Cloud so geography doesn't matter anymore. Platform doesn't matter. It's just out there." And I've seen a lot of companies and a lot of IT teams go through that learning curve. I tell a story about one of our early projects where I had just joined the company. I was maybe six months in and met a fellow in the hallway who found out I was network. And he said," Your team is great. You've done all this stuff," and told me all about his big Cloud project. Right. We didn't know him yet, but he said," I just have one question. So when my instance in the US tries to talk to my instance in Hong Kong, why is it coming back over your corporate backbone?" I said," Well, I'll have to check that out but did anybody from your team mention to the network team that those sites talk to one another?"" Well, no, it was just an assumption. They were both in Azure. Don't they just talk?" And so it's been a real learning curve of within infrastructure teams, but also the IT teams understanding the implications of infrastructure. And no matter how complex or simple it is, geography is, it's still pretty much a going concern and handoffs between companies need to be thought through. So we were able to fix that pretty quickly, but it's... I've seen that same conversation happen a lot of places.

Andrew: Yeah. No, I think one of the remarkable benefits to the Cloud is being able to... The barriers of entry are gone. You don't need to build up this massive and set a capital in order to go deploy and test something. You can build something rapidly and then scale it if it's built appropriately. And so I always think lots of decisions are made locally. As if this stuff isn't... be running here and it's always going to be running here and the users won't be here. And so, great. Done. Versus it's part of a broader infrastructure and at some point that new thing that is going to have to refer to something that's still in the data center, or you're going to have local access in different geographies and you need to optimize the traffic between. And I think that those decisions can be made naively. And maybe the good news is they can be reverse engineered just as quickly, but sometimes not. I mean, sometimes you've decided on having... Who cares what the IP space is... The Cloud and it's completely overlapping and all of a sudden, well, that creates problems crosstalk It's-

Sandi: All of a sudden. Yeah, we have to make it work. And that's been really interesting to watch too. There's been a lot of growth in the infrastructure and network and security teams with the implication of Cloud. But the developers and architects have had to come along with us. So early on, it was exactly, as you said, they put something in a Cloud player. Sometimes they would talk about putting something in Salesforce. They would talk about putting something on Azure, but they didn't know at that point to think through," Well the customer's connecting to Salesforce, but then Salesforce is making a call back to our data center, which is calling something that's in the US, Azure and back and forth." And there's still, I think, a long way to go with architects, really understanding the implications of those things. But I've seen a lot of growth with those teams over the years, understanding that," Hey, if we can look at what the services end- to-end and cluster those things. And also over the years, it's gone from really sort of independent views of," We're just going to put something there," to really looking at where the clusters are of capabilities. And if you look at where the network providers always came together, that goes way back to the MeetMes in the 90s. You've now got the big data center providers like Equinix and so on. You've got the Cloud players are right there. And so you've got a really dense set of infrastructure and now we're starting to see the virtualized and network edge service providers show up there. The SD- WAN players who have gateways there in those same spots. The SaaS providers there in those spots. And they're all sort of trying to eat one another's lunch. But it gives an enterprise an ecosystem at those points, geographically, rather than just a Cloud player where we used to have to run traffic all the way to our data center, to get some security, to go over that sort of last mile into Azure. Whereas now Azure can do some of that for itself. We of Cloud players that sit close to Azure. And the other thing we've sort of mentioned, but not really looked at is, where are the users? The users in a big enterprise have always been scattered all over the world. And Cloud starts to give us the ability if we use it to scatter the capabilities closer to the users. But a lot of the early editions were somebody in London would still be coming into a server in New York. Even though they were on a Cloud player that also had servers in London. And so-

Andrew: Right. That goes somewhat to rearchitecting the applications as you said. Because the application was passive, active between North America and the UK. And only one worked at the same time in the data center and that's where we moved up to the Cloud. Then it's still the same way, right?

Sandi: I think Netflix has really taught a lot of people how that works. And they're just one example, but I spent four years or so based in Hong Kong. And I used my same Netflix account, my same machine, my same credentials. But if I happened to be in Hong Kong or Singapore or Japan, Toronto, wherever I would be getting content that's from the area that I was in. And that was always a good sort of way to explain to both the business and the developers, the benefits of having that content close. And CDNs were a big thing, but they were complex and now they've become a bit more nimble I'd say. And then the ability to have some of those other services and that most of the Cloud players, certainly the SaaS players have really upped their game in terms of distributing content and capabilities. Microsoft was ahead of the curve, as you might expect with the Office 365 and introducing front doors where they could detect," Oh, okay. She's in Seattle today. We'll put some of her data there." And that was really great for travelers, but I think it's also been really great as the networks move and shift. And it's one of the reasons why we were able to move all the users to home. I mean, we didn't have much impact on users at all. We were very ready for it. Other companies, maybe not quite so much because it wasn't built into the culture. But it would've been much harder and much longer a curve to adopt that work from everywhere, if we were still operating just on single data centers and not having that kind of flexible infrastructure in between.

Andrew: Yep. Well, one quick thing on Netflix. This American who moved to Canada, Toronto eight years ago, got super annoyed a few years ago when they got really good at detecting VPNs and other mechanisms to avoid their country. So I can no longer see my American Netflix here, but there's mechanisms that do it, but the content got... whatever I don't tr... I'm now Canadian. I don't want to see the American content, anyway. Regardless, the thing you stressed, I mean, in sort of clustering these applications together. And it's something that I believe in with every fiber of my IT being. Which we've discussed a number of times on this podcast is just, I think it's so easy to fall into this," We're going agile. We're going scrum. We're just going to build this thing." And just forgetting about... and not dissing those processes, but dissing certainly a lack of any upfront architecture. You're trying to create scalable and reliable applications that have all sorts of dependencies and so you need to consider the larger picture. And you can't have 30 different application teams around the world, work in different things, just create this go... let's hope they all come up with the right architecture, because it's not going to happen.

Sandi: Well, that's it exactly. There are things that can be done in small pockets and keeping those things agile within that bigger framework is amazing. But it's like anything else, is the answer, the far right of the spectrum, the far left of the spectrum, or somewhere in the middle? It's the same with agile versus planning ahead and-

Andrew: Always, always in the middle crosstalk

Sandi: I think developers have really come a long way in understanding those things. And so you see more solution architects looking at," Okay, here's the big picture. Now team go off and build within that." But you've got a sort of, a direction in mind and some tools decisions and architecture decisions that have been made and guide rails really.

Andrew: Exactly. They don't need to be made every time. Now you're developing a new application and it's for this business unit. It's consumer facing or it's business facing, it's regional or it's global. Go down the Pachinko board and pops out with some guardrails for how we're going to deploy this thing. And you can reduce the number of variants and create scale that way-

Sandi: You can also... I've seen a lot of advantages in, as centers of excellence are developed within companies and those folks have connectivity to one another through using the same sort of poor tools. You get a lot more cross pollination between the finance IT team and the HR IT team who might not have been talking before, but now they're collaborating. And sometimes that goes all the way up to the business where another Manulife example, just because that's where I've been for the last few years. There was a product that was built in Hong Kong and it was built really well. It was a great platform. And then a couple of the other countries wanted to introduce a similar product and they ended up sort of internally white labeling Hong Kong's product. Because you now could see that this IT stack is going to be the same no matter where we are. Well, why duplicate, let's expand on. And once you start to have those things, you start to see the culture change a little bit within the IT teams. And they say," Hey." Instead of," Oh, they're going to make me work with those guys," or" We're stuck with their decision." You've got more of an ecosystem and more collaboration around those decisions in the first place. So they can be reused and a microservice built once and used many times. It's not just Cloud, but Cloud, I think has really driven a lot of that because it's allowed a lot faster change, a lot more agility. That's driven the opportunity to change how they build as well.

Andrew: No, I think that's a really great point and I think it's worth restating or at least making sure I understand it because it's always been this sort of non invented here type situation, Cloud or not. And part of shadow IT was that. Was we're not going to let them invent this here because they're going to take forever whatever the case is, we're going to go build it ourselves. And then they, in this case might be some central applications team, wouldn't accept it back because it's not invented here. You'd give it to them, but they're going to redevelop it the way they want to. And I think it's an amazing point and a really good benefit of providing some of that global architecture and guide rails and in building smaller things like services or microservices, where those can then end up in a repository where people can use them, because that's how you scale, right? I mean, you're using less variance of something. Here's how we're going to do backend authentication of employees against Azure active director, whatever the use case might be. Here's our interface to long- term storage of data that needs to stay resident in country. Whatever the service is, and now deploy it in many places and you get different service owners and other people contribute to it versus I'm always going to rewrite this. And part of that also, Sandi though, it's where IT used to be responsible for sort of vertically delivering everything. Business needs a new application to do this. IT is going to make the build versus buy decision and figure out what the requirements are, buy all the infrastructure, figure out the SLAs and deliver this thing. Versus I think this broader more, again, like you said before, neither all the way on the left or all the way on the right. But what IT needs to be focused on is delivering platforms, guardrails, capabilities so that other people can create value- driven services and applications on top of infrastructure that we know we can manage. We know is going to be secure, we know is going to be reliable.

Sandi: For sure. And there's a bit of an inside sales job in there as well showing them things. If you have an architecture and a vendor and a platform that have already gone through risk from a technology standpoint, risk from a business standpoint. They've got the regulator on side, then you can avoid having to go through all that again and get your job done quicker. And there's finding the benefits to that, as opposed to saying," This is the corporate solution and thou shalt use it." I find makes things go a bit easier and gets everybody a little more easily on board.

Andrew: Yeah. Even I think your role, or maybe Manulife IT changed generally this way, because as I remember it. Please correct me if I'm wrong. You used to be charged sort of soup to nuts with a set of capabilities. And didn't that change over time, in breadth and more soup and less nuts.

Sandi: Yeah. That's a good way to put it. Manulife, when I joined was just in the process of really finishing the creation of the global teams for the various infrastructure towers. So I gathered up network people from all the different business units in all the different countries and we strung together a network team. And I had everything from operations through to strategy. By the time we got to... I think it was 2019, we were really starting to see a lot more difference in how the businesses we're supporting were operating. And Asia being 12 or 13 countries with an extra regional layer in there that was starting to do some of those guardrails and so on. Versus Canada and US, which were both big on their own, not growing as fast as Asia, but each one was substantial. And you had the country, the business unit and the region were all the same. So you had different problems, different opportunities. And so we started shifting to a more regional structure. And what we did at that point was put most of that bread in regional buckets. And I had to make a decision. Would I be regional for Asia, for the build and run operations and engineering piece? Would I do that for North America? Or would I take the thinner but in my view, a bit more interesting chunk which was strategy, transformation and standards and do that globally. And I see the company moving even more and more to that regional model, because even the strategy and transformation, we got to the point where really a lot of our decisions were," You know what, Asia you go ahead and do that and North America, you go ahead and do that." Those don't conflict. They don't have to be the same, but here's the three places that they have to meet. So for instance, our new firewall and intrusion prevention standard said," You can use either of these platforms. This is your default, but here's the situations where you can use the other one." And that let us plan the big shift that's underway right now. Away from IP addresses and ports and things to identity and context and tags and rules that the business can understand. So anywhere we would need, that we wanted everybody on the same platform heading for the same place. But if Asia uses a different firewall in some of those edge cases, because they want diversity and North America would rather have the same one everywhere or vice versa. We really shifted toward that regional kind of bent because that's closer to the businesses. And ultimately we're only there to make the business able to do what they want to do. So I don't know if I've seen that as much in other companies just yet. But the way Manulife is organized to... with still independent IT teams with their own CIOs in each of the countries and some of the business lines sort of lends itself more to that federated model than the central commanding control.

Andrew: Yeah. It used to be just this like," Let's centralize... no..." Let's-

Sandi: Now we'll distribute, now we'll centralize-

Andrew: Yeah. And they centralize and go back and forth and back and forth

Sandi: For sure. And let's outsource, no let's pull it in. Now let's outsource it again. crosstalk

Andrew: Right. The difference here is when you decentralize there was this sort of layer of strategy that was global. Because I think what the decentralization always creates are unnecessarily silos and kingdom builders and" No, we do it different here and we're always going to do it different." Here where it's not a discussion about what matters back to the architecture. Architectures meet the requirements. And yes, the requirements are going to be different in different areas. Sometimes it's geographical and sometimes it's like you said, sort of a mixture of geographical, but also very importantly businesses at different size, scale and growth with different opportunities. So therefore the requirements are going to be different. And I think when... in adding architectures doesn't mean force fitting. It means allowing architecture for those different- crosstalk

Sandi: Architecture needs to be flexible and sort of Lego block like. And you've always got, especially in a big enterprise, you've got your regulators and the compliance team and risk management and so on to make sure that where it really matters, things are done, but you're looking more at, this is what you have to achieve. And if each team achieves that in a slightly different way, but within a framework that can all fit. Great. Then you don't have to spend a lot of your time arguing about the one true way to architect something.

Andrew: Right. Completely shifting gears, but a bit on a tangent of what we were just saying. We both had the opportunities in our career, yours certainly. Well, many, many years ago I lived in Taipei for almost a year. But you certainly in Hong Kong for quite some time, but I've had the opportunity to, gloriously, had the opportunity to travel the world many times over by doing business and understanding people, cultures, understanding your customer. I think it's too easy sitting espe... when headquarters is in US Canada and your stakeholders are all over the world, it is too... And therefore headquarters is where the weight of the influence normally is, it is so easy to lose understanding, empathy and really understand what's going on culturally, technically and everything else. crosstalk personal side of it, which I think is amazing of just being able to spend a meaningful amount of time in other countries all around the world.

Sandi: Yeah. I'm looking forward to travel, starting up again and getting out there because, to your point, there's something about the human connection and behind every one of these conversations, you've got people and we've all done an amazing job of working virtually for a year and a half, but nothing really takes the barriers away like looking somebody in the eye, having a cup of tea or a dinner together and... But to your point about the gap between head office and the regions, being Canadians, we've all grown up accustomed to being what they think is the 51st state. And head office doesn't understand it's different in Canada. We multiply that many times over when you're talking about a different continent and multiple countries, Hong Kong and Japan and Singapore have quite a rivalry and you can't put them in the bucket together, but then when you go into places like Thailand, Malaysia, Indonesia, it's a very different environment there as well. And not only do you have the empathy problem on the head office and... I can say, I think, without annoying too many people that it exists a bit on the other side. Head office is a four- letter word and I had to really prove, once I got over there, that I wasn't a spy from headquarters and I wasn't there to inflict what headquarters thought on them. And it really did take some time... we're both living in Toronto and you get used to, we're a really multicultural city, you hear other languages all the time, you just take for granted that you understand global cultures because you have Chinese friends and Iranian friends and wherever, but being dropped somewhere where you're not the default, whether that's in another culture or, hey, it's just not head office. It is a big eye opener and understanding to be able to explain back to head office," Well, here's what happens in this city. Here's what you don't know." And frankly, what nobody can get around to telling you, it's not that the regions aren't interested in conveying what's different but what's different to them is just normal. So how do you know what to convey? And I think companies that do a really good job of cross pollination and moving people around different regions. I always recommend too, if people are traveling overseas, whether it's all the way to Asia, just to London, wherever to go. Don't pop in and do a couple of meetings and then pop out. And the executives that come over and they take a full week in region and they see their stakeholders, but they also see their employees and they really take a breath and enjoy the time and invest in it. It just... go for a whole week, twice a year, instead of two days, four times a year. So the thing is just, it makes a difference because at the end of the day, tech is all run by humans and it's all run for humans. So there's only so much we can do without being there. Yeah.

Andrew: Yeah. No, I agree with you completely. And it's for every reason you said, and then it's just time zone, in some cases. On this side, you are used to," That's fine, we'll stay up till 8: 00 PM," or," We'll get up at 6: 00 PM and have a meeting, no issue." And they're staying up till 8: 00 PM or 11:00 PM, or some people here a schedule meeting for them at 2: 00 AM or whatever the case might be. But you're literally never speaking when you're both in the middle of the day for both you. And crosstalk.

Sandi: Exactly. Yeah. By definition, that just doesn't happen.

Andrew: Yeah. By definition, it doesn't happen. And therefore meetings are always, this isn't time to think through something it's crosstalk

Sandi: Let's get through the agenda and now I have to put the kids to bed.

Andrew: You got it. You got it. And no, I couldn't agree with you more. And I'm aware that there's people out there that don't think it is just unbelievably fascinating to go visit different people, different cultures, different countries. I mean, I don't understand why.

Sandi: We're not among them. Well, and there are people too who do understand the value and would love to do it, but they're life circumstance crosstalk just doesn't allow them more or doesn't allow it right now, and that's okay. And there are ways around it, but even to make one solid trip a year and really connect with people rather than... there's nothing worse than the guys on the floor saying like," Yeah, he was here. He was upstairs the whole time. We never saw him. He's gone." Just those little things, like having lunch with the team or bringing donuts and celebrating something with them. But it's I think COVID has really changed the equation to a certain extent. There are a lot of people who really couldn't grasp how things could work across distance and time zone, or my favorite," My application will never work on the internet." Well, it's been working on the internet for the last year and that's changing technology decisions like," Hey, maybe we can run things on the internet," but it's also changing. People are valuing the time we're not in the office. They're really aware that," Oh, it is different. I would like to get back in the office and maybe it's not full time." And Manulife and all the jobs I've really had tend to be dispersed over distance. So going into any one office, I never see my whole team, all my stakeholders but there's definitely a difference between not seeing them every day or not seeing them all together versus just not seeing them. And it's interesting to watch different companies taking different approaches to where is that balance and what's going to work. And really what's great is to see one size doesn't fit all. I'm seeing most companies are saying," Hey, we recognize that roughly 30% of you want to be in the office full time, another 30 never want to be back in the office again and the rest want hybrid," and we're seeing the models come out. And I think it's come at a great time in history because the tech is there to support it. Even things like Sassy, they're in their infancy. We are a little ahead taking our security out of the data centers and out of the offices and putting it out in the cloud and those clusters close to the cloud platforms. But those kind of companies really came to the rescue a year and a half ago because they were needed. And you're suddenly, the users aren't it in the office, the applications aren't in the office or crosstalk applications aren't in the data-

Andrew: So why are we all VPNing to the office?

Sandi: Exactly. crosstalk. And I think it's, well, it's a lot easier to explain Zero Trust now and the idea that being on the network really doesn't mean you're trustworthy, and being off of it doesn't mean you're not. And we need to look past those network level controls, which won't go away. It's good to have a lock on your door at your office, but really shifting that security up to, " Who are you? Are you allowed to come in? What are you allowed to see?" And I think COVID has given us all a little nudge in that direction, too.

Andrew: Let that guide what ports are open for whom. But no, super. Well, it was, as always, wonderful talking to you. I'd love to end on a note of our passion for the world and I think that's a great note to end on. And I very much enjoyed it.

Sandi: Me too. It's always great talking to you, Andrew. Take care.

Andrew: All right, Sandi, take care.