Rob Merrett on The Azure Cloud

Steve Westgarth: 0:00

My name is Steve Westgarth and this is the engineering leader. Today on the engineering leader, I'm delighted to be joined by Rob Merritt. Rob is managing director equity Euro, a company specialising in supporting clients to build out their cloud infrastructure. In previous roles, Rob has also worked with central government, retail energy and utilities. Well, thank you so much for joining the engineering leader today. Let me tell you a secret, you also write bad code. If you disagree, you may as well switch off. If you're enjoying listening to the engineering leader, please take a moment to share a link to the podcast on LinkedIn or Twitter. bringing together people from a diverse range of backgrounds helps to ensure that we have the knowledge and skills available to solve truly global problems. And so let's start by talking about your role at Cloudera. What's your vision, what you do and what you're trying to achieve.

Rob Merrett: 1:05

So my role at Cloudera is mostly helping our clients get the best out of technology, whether that's helping them recover from nearly ransomware attacks, or implementing new software, I guess the way that we'd like to think about it is that we're their partner in making sure that that happens in the most effective way where they get the most benefit possible. I'd say that that's kind of my my vision in a nutshell of what I try to do in my role. But

Steve Westgarth: 1:31

does that mean you tend to look mainly at IT infrastructure? Or do you get involved with software development or kind of your where, where do you really partner best with clients?

Rob Merrett: 1:39

So we do everything from front end, say app dev, data, and infrastructure. My forte is mostly infrastructure with a bit of AP and occasionally I like to dabble in data. But yeah, as a company, we work across the across the full stack, but my specialism is very much infrastructure.

Steve Westgarth: 2:01

In I guess that's a really interesting thing to kind of dig into, I think in in recent years, and particularly, we start talking around DevOps kind of been, you're really kind of front and centre of mind and bringing operations and Dev much closer together. And by virtue of doing that, that naturally means that developers and engineers get much closer to infrastructure build and understanding kind of, you know, how we're going to make sure that that systems are alive and performance and that we haven't got issues if you're maybe there's a data centre issue, which causes a data centre to be taken offline, that there's appropriate failover strategies and your and all of those sorts of things. And how do you find it in your world companies are kind of embracing that, that DevOps culture? And is that helping you? Do you think?

Rob Merrett: 2:43

So I think if you adopt the multidisciplinary team aspect of what DevOps and agile tries to evangelise, on where a team has got the right combination of skills such that our team is as effective as possible, then yes, I think we're seeing a lot of folks struggle is where they see that they have an Apps DevOps team and an infrastructure DevOps team and never to the to meet until they try and release it into life. And it all goes horribly wrong, because the infrastructure guys didn't have the full appreciation of how the app works. And the app guys didn't have the full appreciation of how the infrastructure works. So I think trying to bridge that gap as much as possible, bringing the two domains of expertise as close to as possible together, then that's where you see organisations really succeeding in bridging that gap, I'd say.

Steve Westgarth: 3:38

So I listened to a really angry podcast a few days ago, and there was a lovely, really, really intelligent guy, actually, who had a lot of views and kind of DevOps and kind of, you know, it was making the point that DevOps isn't a job. It's a way of being a way of thinking. And I guess you're supporting that there by saying, actually, it's about bringing people together in the right way. But it seems to be something that a lot of organisations don't always get, right. And I don't know what your experience is about, and you've worked in a lot of corporate organisations. And we see a lot of DevOps teams kind of appearing all over the place. And I guess that's, that's a problem really, for the industry as a whole.

Rob Merrett: 4:15

I think so. I'm gonna say to a certain extent, I mean, I'd like to think that there is definitely a role in the same way that we have agile coaches, someone that can evangelise on, what's the best way of adopting this way of thinking, making sure that the teams are aligned to that way of thinking and ways of working? And I think there is something around DevOps engineering. So you know, not just the ways of working but also the technical, the technical. How do you do it? How do you become most effective in the organisation you're working in? And that won't be the same for every organisation, the way the Financial Services maybe how to implement DevOps with their heavy regulatory stance is going to be very different to perhaps say a retailer that's perhaps got a bit more risk appetite less so. So I think it, it varies industry by industry and says some organisations just need more help than others.

Steve Westgarth: 5:22

Yeah, and I appreciate that. And I think that, I mean, again, we've worked in similar organisations, we've worked in different organisations. And and I guess you're one of the commonalities that I've found in in pretty much every organisation that I find is that they're looking for people to show them best practice to show to show the organisation how to do it. And one of the challenges with what you've just said is, actually we need to do this on an organisation by organisation basis. So how, how, as an industry, can we advise organisations? How to implement a DevOps culture? If fundamentally, we don't really all agree on what a DevOps culture is?

Rob Merrett: 6:01

Oh, has a has a really interesting question. I think there's, the tenants of DevOps and agile are fairly well defined. I think, like any methodology or framework, it will come down to how how you're going to implement it in a way that's right for your organisation. And there's so many different facets to that, like, what's the what's the skill, maturity of the organisation? Are they all really well want to stay up to date or upskilled? Engineers? Is there a learning path that they've got to go on? And that's what I think varies organisation by organisation, if you just go with the same templated form of this is how I roll out DevOps and don't take into account the distinct differences of that organisation, then you're going to fail at different hurdles. As we said, if you have an organisation that has really mature engineers, but let's say less mature processes, then you're going to hit get hit on a process front rather than a person from it's it's that age old triage right over triage of people process and technology, and how do you align the three parts of that triangle to to implementing DevOps is my is my view, I think,

Steve Westgarth: 7:23

in the neck very much close to the heart of a point you made a couple of seconds ago, but that cross functional team, and bringing people together so that we can actually combine those skills in order to get an outcome. And I think actually, fundamentally, for me, this is your in any organisation about you're getting people to effectively work together in order to deliver an outcome and kind of centralising around what that business goal is and what we're trying to achieve.

Rob Merrett: 7:47

100% Yeah, yeah.

Steve Westgarth: 7:49

And I guess you're you've got a lot of a lot of skills and experience in technology change and technology transformation. And I guess, you know, one of the things that I've seen in organisations is that we kind of embark on change programmes or change initiatives. And we haven't always necessarily got a clear goal in terms of what that's going to open up for the organisation and what we're going to try to achieve. I'm just wondering if you've got any thoughts on your what do organisations tend to get wrong in that change space? Yeah, maybe maybe in addition to what I'm talking about there.

Rob Merrett: 8:22

So I think the point that you raised around being clear on what the what the goal is, and importantly, how do you quantify it, and being really clear about how you quantify it as well. And I had a really interesting debate, when there was an objective around moving to cloud. And they said, We need to get 70% of our infrastructure into Cloud payments, or 70%. Of what is it 10? Is that the apps? Have you take into account things like what you're going to devise? So I think it's, it's being as crystal clear as possible about what you're trying to achieve. And then the other piece to it is, when you're doing technology change, it's very easy to get lost in in the technology, elements of that technology change. So I always come back to the people process and technology. So how are your people going to adopt this change? What is the impact actually mean to the business and the processes pieces, if you go to the effort of making a modern app that's very slick and very easy to operate within wrap that in slightly more legacy technology change processes kind of defeat the point of what you're trying to do in the first place, which is make the organisation more agile and more nimble to change. So I think, making sure that again, you've got that three triangle piece of people process and technology nailed in terms of what your programme is trying to deliver is really important.

Steve Westgarth: 9:53

I think that the process element that you talked about is really interesting, but I think, you know, we've both worked in organisations ones that have come from a history of being you're very heavily waterfall. They've they've tried to plan everything upfront, you know, maybe centering around a three year plan, and then try to make sure they know all the requirements, all the unknowns, you know, the start of a programme, and then you'll then go through the development phase and the testing phase. And finally, the implementation phase. And I think, you know, we know those programmes tend to tend to take longer, especially we talk about multi million mount your transformation programmes, it takes a long time to deliver any value. But also when you actually deliver that value, quite often you find that you're the value that actually gets delivered isn't the isn't what is now needed by the organisation because the organization's moved on in some way your your Doesn't your maybe we need something slightly different, or maybe we implement something, and then observe how our customers using it and decide actually, we needed something slightly different to that. But actually changing those organisational processes to operate differently. Is is a huge, huge undertaking. Yeah. Which is, is very, very difficult to do. I mean, I guess you've seen that number of different organisations perhaps.

Rob Merrett: 11:04

Yeah, definitely. I mean, again, for me, it comes down to the context of the organisation and what, what are the guardrails? I guess, of your of your transformation? Like? So if you're working in a financial services organisation? or almost any organisation actually, gaining your responsibility on legal and regulatory requirements is obviously a no, no. So that's got to be baked in, relatively early on. But for example, if you're doing like an MVP, to test that hypothesis, do you need to have all of your NFL hours that you normally have on a production like system? No. But you do need to have a way of governing the system such in such a way and the backlog? That those things do get taken into account as the system matures? And I think that's, that's what I see a few organisations struggling with is, I guess that that continuous architecture and continuous governance perspective of if you're going to start out doing an MVP, what are the things that you can not necessarily put into that MVP? And what the absolute must have an equally who's accountable for making that decision? I think accountability is another thing that sometimes organisations can struggle with is who's the who's the actual person that can say, Yeah, okay, we're not going to do that, because it's not right to do that at this point.

Steve Westgarth: 12:37

And I guess a lot of those decisions, some of those technology decisions you're taking, yes, it might be your because you're going towards an MVP. So maybe you're you're gonna take some shortcuts or do something in a non optimal way, because you want to get in the out to customers, and you want to test and learn kind of your what, what customer is going to think. But actually, some of those decisions will back you into a corner where it's really difficult to come back from those decisions, you have six months down the line, unless you're going to completely re architect the app and kind of and move forward. So you're playing devil's advocate a little bit to what you just said, Are you saying that, if we if we're going to launch an MVP, we should be prepared to write it off and totally start again from scratch, and it's not the right approach?

Rob Merrett: 13:17

So I think this is how you manage technical debt decisions. I think having a good process for identifying technical debt, so where are you taking that shortcut that may trip you up later in later in the program's life, and how that gets governed through the organisation. So if you've spent four weeks writing an MVP, because you want to test it with with a small set of customers, and the technical debt that you put in means that you have to start from scratch, depending on the size of the organisation that may be acceptable equally, it may not be depending on how much money they've invested in, I'd say it's that benefit. cost benefit analysis needs to be really strong. And equally if, if you're taking a let's say, a slightly smaller bite into technical debt, like say, how does that get managed in the backlog because something that you do, as a small thing now, can snowball over the period of the project and suddenly become this horrible thing that's just grown arms and legs. So that's where I say, I think, if you're going to embark on this, see agile development. With an MVP mindset, having that technical debt governance is really important.

Steve Westgarth: 14:49

And then once you've kind of gone through that MVP stage, and maybe you're iterating against a roadmap, you know, you've got a, you've got a product that's out there in the wild, it's actually delivering value for customers. How do you continue to govern decisions in a way to make sure that the organisation is still being strategic about some of those choices that are being made?

Rob Merrett: 15:10

Well, that's a really interesting question. So I think that comes down a lot to organisational design and who's accountable for that product once once it's gone live. So the product owner, I think, plays a really important role in that in defining what the roadmap for their product is, and what the decisions that we're wanting to make. And then alongside that will be the, how the split between new functionality versus maintenance versus resolving technical debts manage. And if you have a product manager that can do that really well and manage those relationships well enough with the business so that they understand well, in this sprint, we're going to take a compromise on new functionality so that we can remediate some of our technical debt, or do some maintenance or do some patching, then I think that becomes that that's, you end up seeing quite a lot of success that I think where you start to see it fail is where so much new functionality gets put on top of this, what was a just envisioned to be an MVP, and they've not had the chance to make it more robust, meet all of the NFS. And because of that, it actually becomes more brittle, more fragile and harder to change. And so you just end up going back down the monolithic route that you were trying to get away from.

Steve Westgarth: 16:38

And one of the challenges in that space, when you've got a product owner who has, you know, a business case to deliver against or, you know, is trying to deliver value for customers, you're, and you're going up against your maybe you've got some technical debt to intermediate or you've got some security vulnerabilities that kind of come out, or maybe there's a legal or compliance issue that's going to be identified, it's sometimes really difficult to demonstrate the value that some of those technical items have that, you know, don't necessarily go you're towards a growth business case that might be you know, you're driving new new your business into the organisation. So how do we reconcile that? You know, what, what can we do as tech professionals, to help product owners to understand some of those those important technical enablers that that need to be kept on top of an audit to your to look after the house?

Rob Merrett: 17:31

It's a really great question. So I think it's about how you articulate the value. So complying with legal and regulatory requirements. Let's say you're working with personal data. The articulation there is if you're caught under the GDPR act, it's 4%. of global turnover. Yeah, you could view that as if we remediate it. That's, that's a cost that we may not incur, as long as we put the right controls in and, you know, we have the right processes to manage that. Right. So I think when you're dealing with an organisation that's on a growth journey, it's about how do you not just, say increase, say, customers or revenue, but also how do you avoid having to pay out for, let's say breaches or risks. And the same thing applies for for maintenance, right? If you don't maintain your system, you don't patch it, you get hit by a security vulnerability, the cost of remediating that security vulnerability is going to far outweigh what it probably would have cost to remediate it in the first place.

Steve Westgarth: 18:43

And once that's very true, I guess that quantifying that risk is often quite difficult, because, you know, especially if you're in a large organisation, you know, the your turnover many billions of pounds. Yeah, of course, your 4% of global turnover is an astronomical number. But you will, then you'll get a push back from a product owner from the business going, but what's the likelihood of that really being the case? What's the likelihood of that happening? And I guess that it's quite difficult to kind of you, when you talk about numbers, which is so big, it's quite difficult to even rationalise what the numbers are, nevermind what the chances are of that actually being an issue caused by your app or your product that you're putting into production.

Rob Merrett: 19:24

Yeah, and I think you know, when you're talking about an organisation has got many billions of pounds, it becomes a lot easier to quantify because by the very nature, you're a well known brand. That makes you much more of a target. If you're doing something innovative, you're going to want to shout about it. That's going to put you more out on the market even more. People are going to want to have much more of a say bad actors will have much more of a vested interest in potentially finding any exploits with the thing that you release. So I think it's becoming It's easier to quantify it. And I guess that also comes back to my point about accountability is having the person that is going to accept that risk. That's always the really tricky conversation, is, if you're really saying you don't want to remediate this issue that may cause a GDPR breach who's really going to accept that risk? And say, Yeah, I'm signing on the dotted line.

Steve Westgarth: 20:27

Yeah, I think you're right. Yeah. Who is the decision maker? And in that scenario, and you're right, I'm sure there's lots of people saying you that you shouldn't remediate or not. You're don't bother with it because of various reasons. But actually, isn't their neck that are really on the line? When what when there was an issue like that, or a breach that, you know, that that really comes and bites the organisation? And I guess, you know, it's actually really surprising how many how many breaches there there are and how many issues we have with bad actors. And I think it's only really in recent years that the maybe that's been so much in the public eye, but I mean, if you look over the last, even 24 or 36 months, I mean, the amount of times that your that issues are in the news, where your company X has had a data breach, or there's been a technical issue with company why it is actually becoming much more prevalent than it ever was, Do you think that's going to continue to accelerate and become a bigger issue for organisations?

Rob Merrett: 21:21

I think it will be, I think it puts much more of a focus on kind of those NFRs that we were talking about just now, especially from a security perspective, it was a really interesting stat by Microsoft in one of the reports, which were so along the lines of the top 11 simplest things to implement from an information security perspective, would present protect you against 98% of vulnerabilities, or potential exploits. So it's amazing how much the I want to say the the simpler aspects of information security can can protect organisations. But in terms of your question, do I think it's only gonna get worse? I think it will. Because as quickly as we can remediate issues, we're also finding new issues. So I think that's just going to continue.

Steve Westgarth: 22:20

And thinking as an engineer, I mean, how much personal responsibility should individual engineers bear for that? No, the reason I asked the question is that, you know, in my engineering teams, you know, were obviously very dependent upon engineers doing the right thing, and surfacing the right problems. But so much of what an engineer does is written in code, you know, it's behind the scenes, it's not, it's not presented as part of a show and tell your product owners wouldn't necessarily know the quality of the code and kind of what's been built out. And we obviously have your good practices around. Yeah, we we do code reviews, and we make sure we're pair programming, and we've got various things, our pipelines that look for code smells, and look for your security vulnerabilities. But still, it ultimately comes down to what an engineer is doing on the ground, to make sure that organisations are protected from these issues. And that's, that's quite scary when you think an individual is potentially responsible for such big consequences.

Rob Merrett: 23:16

Yeah, it's, it's, it's quite scary, I guess, as an individual that you you can ultimately be, I guess, responsible for for a breach of some kind. Through through your work? I think, and certainly the way that I think about it is how would I feel if it was my data that was compromised, you know, whether that be personal data or otherwise? And I guess that's where you start to think work out? What what are the things that I need to do as an individual that can potentially stop this from happening? Yeah, if it was my company, and I spending my money, what would I want to do to make sure that I protect the reputation of the company, for instance, for example. And I think one of the things that's quite interesting, as well as that, we're starting to see the like, I want to say the responsibility on an engineer change from just doing code to understanding like you say, the more security aspects of how a developer can do secure code and the advent of DEV SEC ops, so that they get that real time feedback on how are they how are they doing? What's the vulnerabilities in their code, or application or building or indeed, their infrastructure as well?

Steve Westgarth: 24:41

Yeah, absolutely agree. It's gonna be really interesting. And in a few weeks time, we've got Dario on colza, who's going to come and talk me on the engineering on the engineering leader, all around dev SEC ops and essentially how you can move some of those decisions, your further to the left. So we actually bring bring security into into our development flow and As part of the courseware everyday development cycle, and I guess that applies not just to dev SEC ops and applies to your to operations that applies to running the app and production, price performance issues, and the further right in the development flow that you can actually see issues, the better it is for everybody. And that's not even necessarily agile practice. I mean, that's that's just got to be good. Common sense. Let's see issue early, right.

Rob Merrett: 25:22

Yeah, absolutely. I mean, it's a great point, I guess, talk about kind of observability and telemetry, like you say, just doing it from the code perspective is one thing, but then having the monitoring Once the application has gone live to look for those kinda scary things where your application is maybe under attack, or someone's trying to do something with the application that they shouldn't be. And that's where it leads into your point about, well, how do we make sure that ops are involved in that as well, I think observability and Telemetry is really key to that.

Steve Westgarth: 25:54

And one of the things where we move into awards with with with my engineering teams is the concept of it, build it, own it mentality. So a lot of organisations have traditionally operated, I guess, with an ITIL model by which you separate development and operations. So developers develop, and then we throw it over the fence, and it goes into some sort of service organisation who run it into production. And I guess that there are a lot of challenges with that. I mean, one, obviously, you're the service folks don't know the application as well, as the people have actually built it, they haven't got the right knowledge, haven't got the right skills to fix it, and to do all of those things. And by moving towards a build and own it, model, it moves the the idea of monitoring and the idea of alerting and looking after the app and production very firmly into the development cycle. And that means, you know, if, if the absent production, and there's an issue in the middle of the night, it's the developers who wrote the app that's going to get woken up to have to go and fix it. And hopefully, that promotes the right behaviours, in terms of making sure that we have you're really fixed it. And then the issue wants to go again, because obviously, no one wants to go walking up. From a risk management point of view, though, you know, people may or may argue, you're, it's more risky to operate in that way. Because you're you're giving developers access to production data, or to your systems that you're maybe in a traditional ITIL model, you wouldn't have given access to what's what's your view on that?

Rob Merrett: 27:17

Oh, that's a really hard one. I think that's gonna depend a lot on I'm going to start with trust. Why can you trust the developers in a production environment? to, I guess, respect the boundaries between a live operational system and a development system, in a development system, Dev, quite rightly, would be able to go into a database file, or table and do a select star on the data to understand is there a data corruption problem? Obviously, a very different story in a live environment where perhaps you've got personally identifiable information. Yeah, is is the developer could go through the right process to make sure there's an audit trail of why they've gone to that table search for that data. I think trust is one part of it. And I guess supporting that, then is also the auditability of that system, that that's kind of my observability survivability element. Yeah. Has the production system got all of the right metrics to know when someone's kind of stepping out of line? And then I would learn lean into the process bit, which is, if someone does step out of line, have you got the way of identifying it, and then doing something about it? But that's probably where I go with that. Because it's, it is a very difficult one. And I would say, I came from an ops background, and the worlds are quite different, I think. And I think there's got to be a mutual respect of both developers and operations, the two very different worlds. And there's gonna be a respect of both skill sets, I think.

Steve Westgarth: 29:18

And I guess that that is fundamentally DevOps, right? I mean, what we're trying to do here is to bring the two skill sets, you're really close together to create that cross functional team. And I think you're right, I mean, that that element about trust and trusting your development teams is really important. But to go with that, you have to make sure that the appropriate controls training support is placed around that. And also, you know, as you say, there are some skill sets within that, that you know, you still need, you still need operations professionals who are going to to monitor and make sure that you're the right alerting is in place and all of those things, I guess it's for me, it's about getting engineers more involved in that conversation. Removing the fence so it might be when you're playing a different out, but let's at least be able to see each other and talk to each other without having to do it through your through some big barrier. So actually bringing the organization's closer together is incredibly important for me. So let's change the conversation a little bit. So you know, I guess you're very focused on cloud and then particularly as your clouds, you're definitely a Microsoft man, I think would be a fair, a fair statement.

Rob Merrett: 30:24

Yeah, I've definitely got my Microsoft badges over the years.

Steve Westgarth: 30:29

So what is it about Microsoft and in particular as your that

Rob Merrett: 30:32

you like? So I guess Microsoft, it was one of those brands that I grew up with from quite a young age. So it's just been, I guess, always the, I started messing about with computers. Probably when I was about 13 years old, and carried on since then, it's always been Microsoft. For me, it's just been a technology that I found quite easy to adopt. But also the community that comes from Microsoft as well, I would say, for me, the community is really strong. But both commercially, but also, it's just just an end user. And then more recently, I guess the innovations that Microsoft have been coming out with, like the submerging of datacenters in oceans, to look at the impact that has on not just how long we can make servers and computers last, but also the effect that that actually has on the marine life, I found that fascinating. See, I guess that's kind of why I aligned to Microsoft, and then subsequently agile. So I guess the the cloud thing for, for me, the cloud thing that sounds terrible. I came from an organisation where it was predominately data centres. And they were just starting to dabble with VMware. And then when I came to Pradera, they were very focused on how do we build capability. And there wasn't really that many folks that were doing as you're at the time. So it also felt like quite a nice fit for me to skill up, and I guess become the, the as your as your guy.

Steve Westgarth: 32:14

So one of the things that I still think people don't really understand about the cloud, you know, whatever we talk about the clouds, you will, you will see people literally pointing up and pointing in the sky, because that's where it is. But in essence, we're still talking about data centres. I mean, you referenced some of the innovations there that Microsoft had done by submerging servers and submerging data centres at the bottom of the ocean, you're ultimately we still have data in data centres. The cloud is just essentially putting our trust into your large organisations, you have the financial backing the capital, the the technical expertise, to manage those data centres, arguably better than individual companies can do on their own. So you're given that I mean, did you agree with that, though, is the cloud actually the right approach? Are we right? Are we right to centralise all of our services into the hands of what is becoming your, I guess, an ever decreasing your number of your significantly large corporations that now control your the vast majority of the world's data?

Rob Merrett: 33:18

So it's a very interesting and difficult problem, I guess, the flip side of it is pre cloud, it was a number of system integrators. So perhaps the pool has got smaller, and you've now predominantly got the big three cloud providers with most of it, but I guess it's just been an evolution of the model that we had before. I think it is the cloud, just another data centre? I don't think so. For me, it's really fundamentally differently. So the owner, say to the PlayStation, if that's the word of the accessibility to that technology, and the ease upon which people can learn and use that technology is what the fundamental mind shift. mindset change has been, you know, you can, I guess before cloud, you could be a specialist in checkpoint firewalls, for example, and maybe pick up other firewalls and but then that would somewhat limit the next organisation that you went to. Ideally, you'd want to go to another organisation that also did checkpoint firewalls. I think now, because all of that has been, I guess, managed to a degree by Microsoft, your your scope of your next role is well, do you use as your and yeah, taking that step further is not gonna say it's easy to transition between the cloud providers is definitely an Up skill that one has to do. But I guess the concept So I remain very similar. So I guess it's, it's, I want to say democratising access to that knowledge or that skill set in a way that we've not been able to before as well.

Steve Westgarth: 35:14

I guess one of the things that that really blows my mind about you know, is, is we're going to move to the cloud. And we've adopted this approach, it is the accessibility of the technology. You know, if you imagine, you know, a few years or even even 10 years ago, you know, somebody creates an app in their bedroom, your student, and you know, started to get downloads of that app on whatever platform is kind of launched it on, it would have been very difficult for him to scale up, and to have actually to support your volume of users. And that would have very quickly become very costly, where suddenly, we're now in a world where your student is working in his bedroom, if he needs to have you know, all of the computing power in the world to support his application, you're suddenly has access to it in a few clicks, you're via a cloud provider of choice. And yes, that costs but actually has costs than proportionately ramp up, provided that's managed correctly, in line with the growth of his app, and what's happening in that space, that access and ability to be able to do that sort of that that sort of project, your traditionally would have been, you're in the gift of your large corporate organisation that had the financial backing, whereas now this is open to everybody who wants to innovate?

Rob Merrett: 36:26

Yeah, 100%, like you say, as long as those costs get managed, very, very carefully, because I think I think as a student, some of the cloud costs that I've seen, they might have been a bit difficult to swallow, if you ramped up too quickly.

Steve Westgarth: 36:38

It is, I think it is very easy, you are right, to get your cost management in the cloud wrong. And I think it would also be fair to say that, you know, within I think all of the cloud providers, you know, it's it's not necessarily, you won't always necessarily support them the best way to make sure it's as cheap as they possibly could be. And maybe that's something that we as an industry need to learn from to make sure that actually where we're doing the ethical thing in that space. Right. Yeah. 100%. But you've, you've mentioned multicloud. And obviously, I know you're, you're very into as you're and Microsoft, is, is multi cloud important to us as we move forward.

Rob Merrett: 37:20

I know I've used this term a lot in the time that we've been speaking, but I'm going to go with my answer, I think it depends entirely on your organisation and what you want to get out of multicloud. Going to come back to financial services, again, we know that from a regulatory perspective, they're being encouraged to not put all their eggs in one basket. And in fact, that could be valid for any number of enterprise customers that don't want to be put into a corner. I think the main thing, when you're considering multi cloud is what exactly you're going to use each cloud for. Because where it gets very expensive, very difficult to manage is where you just want to say striping all of your applications across all of your cloud providers. Because the there's one or two ways of managing that one, which is you in one set independently find the people that know as you're in AWS and build up the capability individually. Or you look at what they called the applications like pivotal and such, which I say orchestrate across multiple cloud providers. And I guess that becomes somewhat difficult in the sense that, in reality, what you end up going with is the lowest common denominator with one of those applications because you won't be able to get the power of AWS or Azure or GCP if you're using something which can only interface in a consistent way across all three.

Steve Westgarth: 38:57

Cool. And I mean, obviously, I mean, multicloud is one of these things, but you know, from a strategic perspective, what organisations will be thinking about when developing their their cloud strategy, what do you think you should be really front front and centre of mind?

Rob Merrett: 39:15

Think it's, again, depending on what the organisation is trying to achieve by adopting cloud, is it agility? Is it cost saving? And making sure that when you're developing your cloud strategy you're delivering on what that objective is, you know, if it's cost saving, as we all know, do it doing a pure lift and shift of 20 year old monolithic applications, that's not going to save you a whole bunch of money, it's probably going to cost you more money in the long run. So if you aren't doing that, making sure that you plan to invest to modernise once once you've done perhaps that tactical lift and shift and there are perfectly valid cases for doing that if you're trying to exit a data set And so it may be that the quickest stopgap is move it all up to cloud very quick and then modernise later, that you've really got to have that modernised later, as a part of your business case, and also really understanding those two, that total cost of ownership. So I think when you're developing your cloud strategy, it's gonna come back to what you're trying to using, what you wanting to use the cloud for, and what benefits are you trying to drive out of it.

Steve Westgarth: 40:28

And I guess that that links us to your to another point, I mean, we, we often talk about the cloud as if it's one technology we refer to as your as if your as your is the cloud. But actually your the cloud is built up of a whole look of technologies that are embedded within it and actually saying somebody is in as your expert doesn't necessarily mean that they've got skills and experience in every technology that you can leverage within the as your cloud. So I mean, let's, let's dig a little bit deeper than just talking about your as your AWS, let's talk about your technologies that we can quickly leverage in the cloud. I mean, you're working in that space every day, what technology you currently most most excited about.

Rob Merrett: 41:10

So for me, I think it's going to be the data capabilities. I mean, Cloud has been on this phenomenal journey of democratising infrastructure and making that easier to work with. That kind of then went into application hosting. And I think now that they're really starting to focus in on data. So if I go back, perhaps five, five years in my career where clients were having to talk about investing a significant amount of money in these Hadoop platforms, so that they could do machine learning and such, that's now almost a thing of the past, because it's, it's all on hand, as long as you can find some way of getting your data into the cloud, so that you can run machine learning models or in case of as your the cognitive services that they have. You can do that almost on demand with vast libraries of this stuff that would normally to or would have previously taken folk hours to code. And I think that's where you, you start, we're starting to see that very similar way to DevOps, that shift about folk having to worry about infrastructure, to folk actually getting value out of the tools and technologies that we're using. So that's where I get quite excited.

Steve Westgarth: 42:40

And you mentioned the machine learning artificial intelligence. And you're clearly that's where we're at the cutting edge of where businesses are, and what can be done. How are we really ready for that sort of technology? Are businesses really ready to adopt that? Do you think, because many businesses I've worked with, they're still trying to get the fundamentals right, we're trying to understand you how to how to have a performance website and a form and app, you have the table to deliver customer value, your machine learning seems a big distance away from some of those conversations, or maybe not.

Rob Merrett: 43:11

I think that the challenge always is how do you bring that insight, I want to say that you've developed back into the operational processes. So if you've, let's say you develop some process mining to look at, yeah, how effective are the processes that I have in the organisation? It's very, very good to identify where those processes are stored. But if you're not using that, to modernise the processes, make them faster than it's, you're gonna say you've only solved half of the problem. And so I think the real gap that folk are facing is how do you operationalize that insight that you've derived? How do you bring it into the business embedded into the processes? I do think organisations are ready for it.

Steve Westgarth: 44:05

And with that in mind, talk to me a little bit about technology adoption. So if you're thinking about you're working with business, you're thinking about what technology might be suitable to really kind of accelerate them or take them to the next level? What process do you personally go through working out of a technology is fit for purpose and if a business is really ready to embrace it?

Rob Merrett: 44:24

So for me, I start with what are you trying to achieve with? So you want to implement new technology? Why, what what is it that you're trying to do? Because sometimes technology isn't always the right answer. I worked in one project where the cost of integrating into a legacy system was literally going to be millions. And so a question is, what is it better to have humans do that process right? rather than technology if it's going to cost you so much to do it? Or is there a process efficiencies that you can find in doing that process, for example? So I always start with the why. And then if you've got a good reason for using the technology as it's got to start from how do you bet that technology into the business? So what is going to be the people adoption of it? How you're going to skill people to use it? How are you going to bring that technology into your business processes? Should your business processes change as a result of having that technology? That's always a really interesting one, when you're going from a world where perhaps you had a very paper based process to, let's say, case management system, for example, that automates a lot. So there's a big mindset change. And then I guess, once you've got the technology in, because you never really see a tool where you've got all of the benefit of the tool on day one. So it comes for me, it comes to that kind of product owner mindset of how do you continue to leverage the tool or technology to the best of its capability and get the full benefit out of it. And it's that continual process of, we're gonna release this feature, and then that feature aligned with the upscaling of the people that use the tool to take advantage of it. So but that's, I guess, a bit of the way that I think about it.

Steve Westgarth: 46:35

It's, it's interesting, you say that, you know, is technology always the right answer. And I remember a programme that I worked on a few years ago, where you have if you go to an engineering team and engineering team will always say I'll build you something out of your system and make something happen. And we went through this process of kind of understanding your how long it was going to take to implement a particular feature, you're on on the system that we were doing for, for a client. And actually, after we've done that, we costed up what was going to take something like four or five Sprint's to this bit of work, or whatever. But then we we asked him, what turned out to be the best question we've ever asked, you know, we you're talking about, well, how often is this feature going to be used? And somebody said, Well, well, actually, it's going to be used to maybe once every six to eight months, you're by somebody, you have to do this particular process. And when we dug into, like, how long would it take to do the manual process, you're maybe working on 20 minutes and dividuals time. So you're then finding yourself, you're comparing the value of you're implementing this technology feature that's going to yo, yes, make it all automated. So you can press a button, but actually isn't really such a hardship that once every six to eight months, someone's gonna spend 20 minutes doing something manual. So sometimes really looking at that value conversation, and understanding what we're trying to deliver for the business and why we're doing that is really important. And often, often I find, as an engineer, that we can sometimes lose sight of that that bigger picture of what we're trying to unlock and what we're trying to deliver.

Rob Merrett: 48:00

Yeah, absolutely. Like I said earlier, for me, it always comes back to that articulation of value. What what's the value that you're gonna get out of doing this?

Steve Westgarth: 48:12

And you've, you've touched a little bit on legacy systems there. And, you know, I guess this is this is a problem that's faced by a lot of organisations were often hamstrung by legacy systems that have been implemented, and they've been there for many, many years, they're doing a job, you're are we going to take them to the cloud with us? Yo, are we better to actually use leaving on the data centre where they are? Or do we need to modernise them? How do you think organisations should approach that that challenge of of legacy that virtually every organisation has?

Rob Merrett: 48:42

So there's obviously different approaches that you can take. I guess from from a cloud migration perspective, you've got the typical lift and shift. rehoused refactor, re architect reimagined type things right. I think there's obviously different architecture patterns that you can apply to this as well as the likes of strangler fig, where you slowly strangle the capability off of a legacy system on to a new system. So my advice to any organisation would always be well, what is it you're trying to achieve? With the legacy system? Is it that the benefit that it delivers is invaluable to the organisation, but it just needs to be done in a more modern way? Or is it that eventually you need to demise the system altogether? Because that's going to very much affect? How much money are you willing to invest into this? This thing, right? So I'd say have the grown up conversation about what you're trying to do with the system. And what's the vision for this, this system and then apply architecture patterns like either strangler fig to slowly eke off the capability and move it to a new system or apply, let's say, more, I guess basic approaches like lift and shift, if you eventually plan to demise it.

Steve Westgarth: 50:21

And you mentioned there, for example, the strangler pattern. And I think you're in my experience, one of the challenges that you often find within organisations is, when you adopt a strategy like strangulation, it's actually keeping the organisation focused on the agreement that you were strangulated, because in that space, it will typically take a much longer period to strangulate something than it would to just go out and rewrite it again from scratch. Have you have you seen effective results by strangulation systems? Have you ever got to the end of a strangulation that has seen the effective removal of a system?

Rob Merrett: 50:57

Yes, I, I have. And I think your point around focus is really valid. If you've got to maintain the focus that the case that you've got is about decommissioning the system, in theory, and realising the benefits of that. And that doesn't mean that you can only do half the job and then walk away from it because you're still going to be left with a legacy system at the end of it. So your your point around focus 100%. Correct. I think the the other point is around where I've seen strangulation not work so well, is that I guess there's two ways that you can think about it one, which is, I'm going to take the application kind of tier by tier, so I'll move the front end, and I'll move the application services and I'll move the data. Or you can think about it in very thin slices, we talked about capability. So it's kind of like top down capability. So user journeys, you move over a user journey from one place to another. And I think where I see the most successes, where people really think about the user journey, because that really helps articulate that I'm going to say the people process and technology angle, but from the application perspective, so how did the users interact with the system, and it will be user journey? Who are all the different stakeholders that are involved? I think you get much better articulation that way, than perhaps if you're trying to play more of a I want to say technical view of how to strangle strangulate, if that makes sense.

Steve Westgarth: 52:34

Yeah, no, it absolutely does. And I think I think you're right in that space. I mean, it's you know, it's, it's making sure that we have a consistent focus on on what the user actually needs and what the user is going to experience. I know. So in my previous role at boots, we were strangling our ecommerce platform. And we found it very challenging to to move to a world by which the user could seamlessly move between monolith and cloud native application. And we had a lot of conversations around, we have some really tactical things around session management and making sure that authentication works seamlessly and making sure that the user got the experience that they wanted that the whole of that process. And I think in hindsight, although it was absolutely the right decision for boots to strangulate, their their monolith, I think that it would have been easier if we've taken an alternative approach and perhaps just yo rebuilt the website from scratch. But your it's very difficult to or your to make the business case to do some of those things, as we found. So you're I guess you're constantly trading off, you know, what your what you're trying to achieve, versus what the business needs, what the customer needs, what the business case is, and that often causes a lot of challenges.

Rob Merrett: 53:49

Yeah, definitely, definitely. And I guess baked into that is a different viewpoints of your stakeholders as well. That's always a very challenging one and being able to balance those different viewpoints.

Steve Westgarth: 54:03

And I guess you know, that that your brings us to your that this idea of vision versus results because actually, in a large corporate organisation, you will have many visions that may be different across different stakeholder groups, and you're constantly trying to come back to the key results, what are we actually trying to achieve as a result of doing that? What What's your perspective on that disconnect?

Rob Merrett: 54:31

I think my perspective is going to be having someone that is ultimately accountable for what you're doing. And when I say ultimately accountable, I don't just mean from like a functionality perspective, but overall accountable to the business. Person that fully appreciates that like conflict of like we were discussing new functionality versus the non function In all aspects of building a system and having that single person that is there can make the decisions and can help remove impediments is really important. And I guess the important thing for that person is to have we talk about vision, but what are the tangible things of that vision? And what are the things that almost if you tick, all these boxes aren't going to be super happy with you? And then how do you track them? Because like you say, when, when you're in the, the depths of delivery, it's very easy to put your head down and get into it. But I think if you've got something to always refer back to where you're asking the question, Is this really getting me towards that, that end goal? But that's really helpful, I think, for for teams, to be able to, I guess, quantify that the work they're doing on a day to day basis is edging them closer towards that goal or meeting that vision?

Steve Westgarth: 56:04

Yeah, no, absolutely agree. And I guess you're one of the one of the things around your vision is your vision shoppers beyond within the organisation? Right? Yeah. So if you're, you're working within the organisation you want an owner that is ultimately responsible, probably has some sort of p&l accountability for what's actually happening in in that space, you've spent a lot of years working within large consultancies. So you know, your organization's will outsource your engineering requirements or your whatever it may be to external parties, how have you found yourself able to to really align to the vision of the organisation? And how, how does that work for you when it consultancy capacity?

Rob Merrett: 56:47

So I think we're it's going really well is having a relationship with that person that is ultimately accountable. So you, almost so that you can hear firsthand, what is it that they're trying to achieve? Because I think and I imagine, developers equally have this frustration sometimes that the more layers you put in between the person that's asking for something, and the person on the ground delivering it, the more chance there is for ambiguity, or even the slightest change in it in the context of a sentence can mean huge, huge differences and interpretations of words, that I always think back to that there was a delivery report on one project, but had a, an end date for a feature of just February 90. And no one had quantified what they mean by February 19. And so that the CEO took it to be the 19th of February, whereas the the the delivery partner took it to be just sometime in February, in the year 2019. So it could have been right at the end of February. But as long as delivered within February, they consider it done. So yeah, that clarity for me is really important.

Steve Westgarth: 58:10

I think you're right on that alignment is hugely important. And one of the things that I found to be really useful and and helpful in terms of driving clarity, is to use OKRs. And you know, if you guys are if you've come across that, but your objective key results, I find is a very, very good framework to help to it to really frame that. And one of the best examples I've seen of that is, it's the Google example to you, you may have come across before, when Google bought YouTube back in 2016, they clarified that actually, their most important goal was watch time. And actually, their key result was to get a billion hours of watch time every week on YouTube. And you know that that clarity of purpose of saying actually everything we do in the organisation, regardless of what it is, is going to be centred around helping us to drive towards more watch time on YouTube. We wanted billion hours of watch time, I think is incredibly powerful. And in particular, if you're working with partners, and actually almost more importantly, if you're working with partners, actually having that clarity around what you're trying to achieve is something it's so important for organisations to really strive for. So we're all kind of pulling in the same direction. It's very easy to kind of end up pulling in in slightly different directions or not not you're all going towards the same organisational objective or goal. Yeah,

Rob Merrett: 59:31

absolutely. And I guess one of the more interesting things is, certainly when you're you're in a position of managing suppliers, you know, both being a supplier and having to had managed suppliers. I think being able to reflect that in the way that you contract as well, is really powerful. Organisations are moving more and more towards agile. What they term is agile contracting so that the way that you're contracting your partner is reflective of the benefit you trying to get out there. I think that's a really important thing for organisations to think about is, how can I make sure that the way that I'm contracting with a partner is reflective of the objective or vision that I'm trying to achieve?

Steve Westgarth: 1:00:14

I think something that I've never really seen, but I think you can totally see, we need a model four, is a really effective outcome based contract. Yes. You know, it's something which you know, a lot of a lot of partner organisations are talking about right now. And a lot of people are going to work well, how can we formulate words within a contractual arrangement, that is about delivering outcome. And that sounds very clearly different from a contract that is, yo to deliver a thing, you know, we aren't contracting to your to implement a system or to build a website or to implement a set of features. Instead, you want to contract to increase revenue, or to move the needle in some way, in favour of the organisation. And I still, I still don't think I certainly haven't seen it. And I'd be if anybody's listening who has your an example of a really good outcome based contract, I would be, you're really keen to, to hear about it, and to have a look at it. But I think as an industry, we haven't quite got there yet. But it's something it's enough for me that we need to crack and that's really going to unlock I think, your the next your 1020 30 years of consulting really, and how that needs to work your for for, for the consulting industry to really survive and thrive.

Rob Merrett: 1:01:29

Yeah, I'd agree. I think the move to outcome based contracts is a really interesting one. And when I say also quite quite, quite a difficult one as well, I think I think being able to get a supplier and a client on the same page about what the outcome is, that's, that's going to be the challenge, I think,

Steve Westgarth: 1:01:52

definitely. I mean, just thinking again, about your, your experience of working in a consultancy, I mean, your people might be listening, who are thinking about you maybe wanting to go into into a career within a consultancy, or, or seeing as that as an opportunity, maybe you're for growth, or maybe somebody working in an organisation and thinking, hey, they maybe want to jump ship and actually go and go consulting as opposed to, to working for your for an organisation itself. You're what's what's what's your perspective? What advice could you give to anybody considering consulting as a career choice?

Rob Merrett: 1:02:24

I guess what I'd say is, consulting is, is hugely rewarding, being able to work with so many diverse clients across multiple different industries, I'd say. The, the core thing, I think, to consulting, if you're looking to make a switch is going to be those soft skills. How do you? I guess not well, articulate. I'm not doing a very good job of this evidently. Your point to a client? Yeah. How do you come across well, to a client? How do you articulate a really complex problem in a way that clients can understand it and appreciate the level of depth that you've put into your solution, for example. So for me, the main thing that I've learned across my years of consulting is going to be keeping up with the soft skills as well as those technical skills. So that you can articulate the complexity of your thinking to folks that aren't necessarily going to be on the same technology wavelength as yourself.

Steve Westgarth: 1:03:43

I think there's a there's an awful lot of things in that. I mean, I think that as a, as a tech professional, being able to articulate tech in a way that people understand is incredibly important. And I think there's also something in in demonstrating your own understanding of the technology. Because if you can take a really complex problem and explain it to somebody who doesn't understand the problem, then that you're by virtue of being able to do that demonstrate, you really understand the space. And I think for me, that's, that's the value that the consultancy really can bring. It's about you're putting people into organisations that have a really your in depth and detailed knowledge of a particular a particular sphere or domain, that you know, that they're able to articulate in a clear way, and give the business options in terms of where to drive to, and how to unlock a particular business problem, or area that might be helpful to

Rob Merrett: 1:04:36

them. Yeah, 100% I think a nice way of doing that, for me has always been storytelling. Yeah. How do you take your client or the organisation you're working with on on the journey from being where they are today to where they want to be in the future? And what are the steps that they need to go on to be able to do that?

Steve Westgarth: 1:04:57

Yeah. 100% So So I have tended to end our podcast talks with a bit of crystal ball time. So I love asking you about the crystal ball asking you to get your crystal ball out and talk to me about the future. So we've talked a lot about the cloud. We've talked around engineering practices, we've talked about challenges that organisations face, you know, if you had a crystal ball, and you're looking forward for maybe the next five or 10 years, what technology challenges do you think are going to be most relevant to companies? And what should we start thinking about now, in order to set organisations up for success in the future?

Rob Merrett: 1:05:37

It's a really good question, I think. I think we're gonna see a lot of organisations, probably realising some of the technical debt that they've been carrying for a while. And I think to a certain extent, you're seeing that with with cloud at the moment, yeah. We see some organisations that did the lift and shift kind of five years ago and are coming back outside. And so this is costing an awful lot of money that we didn't necessarily expect in the first place. To which the answer is normally you have to think about modernising it. See some organisations taking the nuclear option or going back on premise. So I think we're going to see quite a lot of that I think, the focus on what I was alluding to earlier with kind of the people and process changes can become more predominant. In the we're going, there's going to be a bigger push, I think, to streamline processes, automate them a lot more as well. So the traditional, I guess, let's say service onboarding that we'd normally see of an Excel spreadsheet, that being more automated in terms of the see ICD pipelines and the checks that they can do. And then I guess, the more looking further down the line, I'd hope to say that I think that multidisciplinary team concept is going to be far more embedded. And I think that's going to mean a lot less friction in delivery. That's what I'd like to think.

Steve Westgarth: 1:07:18

Yeah, I hope you agree with that as well. I mean, I also have a lot of faith in multidisciplinary teams. I think that it certainly for me, I can see the benefits of working that way. I think it opens up a huge amount of opportunities for organisations. So, you know, hopefully, hopefully, your crystal balls right, but I guess we'll wait and see.

Rob Merrett: 1:07:36

I hope so. I hope so.

Steve Westgarth: 1:07:39

Well, it's been an absolute pleasure talking to you tonight. And thank you so much for joining on the engineering leader. I'm sure we'll definitely have you back and want to podcast at some point in the future. Your insights were absolutely brilliant. Thank you very much.

Rob Merrett: 1:07:50

I'd love to thank you for having me.

Steve Westgarth: 1:07:58

My name is Steve Westgarth, and this is the engineering leader. Rob is such an amazing technologist with a brilliant ability to communicate with business stakeholders, using clear non technical language. He is able to articulate complex technical problems and a really accessible way, which is something many engineers often struggle with. I really enjoy chatting to him and exchanging views about cloud adoption. I'd be really interested to hear your views. Perhaps your organisation is adopting a lift and shift approach. Or maybe you are setting up an as your data lake. Drop me a message on Twitter at Steve Westgarth or search Steve Westgarth on LinkedIn to let me know what you're up to. Let me tell you a secret. You also write bad code. If you disagree. You might as well switch off