Most transformations fail because they are (unintentionally) designed to.
They often focus on technical decisions, not realising that technical decisions only magnify the strategy, culture and money flows of your organisation.
Does the movement of money in your organisation enable innovation? Agility? Reliability? Or does it get in the way?
Your Speaker
Jamie Dobson is co-founder and CEO of Container Solutions, a professional services company that specialises in Cloud Native transformation. With clients like Shell, Adidas, and other large enterprises, CS helps organisations navigate not only technology solutions but also adapt their internal culture and set business strategy. A veteran software engineer, he specialises in leadership and organisational strategy, and is a frequent presenter at conferences.
Transcript
(Skip the gossip and jump straight to Jamie's talk).
Introductions
Charles:
So hello everybody and welcome to our webinar. We do have a little bit of housekeeping to go through first, so I'm going to do that straight away. The first thing to say is that we have a code of conduct. I think Tereza will put that link into the chat for you, but the short version of it is that our events are dedicated to providing a harassment-free experience for everybody and that's regardless of gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, religion, or lack thereof.
We don't tolerate harassment with participants in any form. If you violate these rules, you may be sanctioned, you might be expelled from the event at the discretion of the organisers, and if necessary, you may be banned from participating in future CS events. We do take this stuff quite seriously.
The code of conduct is something we enforce. It's also Creative Commons, so if you are an event person and need a code of conduct, steal ours please. It's a good one.
And yeah, you can just take it. We don't mind. Actually we'd be thrilled if you do, so help yourselves. You've probably guessed from the fact that it's called a what the WTFinar, but we do swear a certain amount at Container Solutions. And honestly if that bothers you, I'm sorry, but it's just part of what we do. It's part of the brand at this point.
If it really bothers you, then honestly, particularly since Jamie's presenting today, this is probably not the event for you, sorry, but hopefully you can tolerate a little bit of slightly fruity language. This session is being recorded and it will be posted on the Container Solution's YouTube channel. I think a link to that will go into the chat as well in a moment.
If you are concerned about your name or your face appearing on the video, if you let one of the CS people, either me or Teresa or Carla know, then we can obviously pixelate you out or blank you out before we upload the video. So there's no need to worry about it. We can take care of that for you and it's not a problem.
We do like these sessions to be interactive. As Jamie said, it is a community process. We do like to get questions in. You can drop those into the chat at any time, and when Jamie feels it's appropriate, he can try and answer a few of those towards the end of a session.
And if you want to just grab the microphone, if you're feeling brave and want to actually be on camera and speak, we can do that as well.
This webinar is part of a larger range of content that we produce, which is named collectively as WTF is Cloud Native.
Now, I'm hugely biassed here because I'm chief editor for CS, and one of my jobs is to put this thing together every month. So obviously I think it's absolutely brilliant, but it really is really good. It's a good piece of work. I think we publish about seven blogs a month. Some of these are CS people, some of these are from CS engineers, other people who work for the company, but we also get some external writers involved.
We've had people like Matt Turner of Istio fame, Jennifer Riggins, Joe Fay, Holly Cummings, loads more. We also have a podcast and we get some brilliant people on that, including Adrian Cockcroft, Manuel Pais, Sarah Wells, Randy Shoup, some really, really good people. You can subscribe to the newsletter there.
If you do subscribe to the newsletter, I absolutely promise you you will not get any spam from us. We are not a spammy company at all. So you can just sign up for the newsletter and you will just get the newsletter and that'll be it. You will also hear about upcoming webinars, get notifications about the blogs, the podcasts, and all the rest of it.
Thinking of upcoming webinars, we've got this one as the next one. This is with Pete, Mia and Tori. They will be discussing how product and design thinking helps us identify, understand, and prioritise problems faced by a named set of customers and then build and validate solutions.
This should be really interesting, I think. Again, like this one, free to sign up, the link is there, so sign up and find out more about that. Or sign up to the newsletter and you'll find about not only that one but all the rest.
Thinking of events, our next big conference, WTF is SRE is back for the third year, and it's in person in London in the UK. This will be May the fourth to the fifth of 2023. We've got four tracks, so we're going to be looking in detail at observability, DevSecOps, reliability, and DevEx. Tickets are on sale now. We've got speakers lined up including people like Charity Majors, Crystal Hirschorn, and a whole lot more.
I think I'm speaking as well, so you can hear me in person. But more to the point you can hear people like Charity and other experts from the industry, so do you come along to that.
Our O'Reilly book. So this is a book on cloud native transformations that was written by Michelle Gomez along with co-founders, Penny and Jamie, today's presenter. It is currently available as a free download from the CS website. It's a really, really good book and I'm not just saying that because I work for CS.
It is genuinely a really good book. Lots of hard won practical advice and patterns. You can, as I say, download that for free, help yourself.
The ESO stuff. Jamie, did you want talk a bit about the ESO stuff?
Jamie:
Yeah, well we've only just found out today, but for those people who are new to Container Solutions, we actually, 80 or 90% of everything we do is about building things, whether that's cloud things, re-engineering applications, moving them around, migrating them.
And we basically kicked off, I think at least I think we kicked off or we picked up very early the reigns of a project known as External Secrets Operator. It is now being incubated by the CNCF, at least I think it's been incubated. But importantly we're going to have a booth at KubeCon where we can talk about the External Secrets Operator. So it's a really cool little tool. We're very proud of it. We don't do much open source because we're quite a small company, but we're very proud of the contributions that we are making.
This has been a significant contribution. So I wanted to add it in today's webinar for two reasons really. First of all, to let you know we're going to have a booth at KubeCon, but second of all, to say congratulations to the team at Container Solutions who have made this work. I think this is a very proud moment and it's going to give us something really cool to focus on when KubeCon comes to Amsterdam, I think in about four or five weeks time.
Cheers, Charles.
Charles:
Thank you.
And I think we've just posted a link, but we have a book on that as well, which again is free to download. So if you want to learn more about it, you can. Now we like to experiment at CS, and one of the examples of an experiment is the gossip section. So we did this ages ago as a one off, and then people kept telling us how much they liked it. And so we kept doing it, and it's now a regular feature of the webinars.
I believe Julian is our gossiper today, so I will turn this over to him and he can chat about whatever it is he wants to chat about. Over to you, Julian.
Julian:
Sure. Hi, Hi everyone. Can you all hear me well now?
Charles:
Yes, your sound is great. Thanks.
The Gossip
Julian:
Okay, that's great. So welcome everyone to this webinar. I hope it'll be great. And to start with the gossip, I just wanted to talk about a few topics that are quite interesting and that came out in February of this year.
So the first one is Reac.js documentary by Honeypot. Indeed, those are the people who made already the Kubernetes documentary a few weeks, months ago. It was fantastic. They also have documentary about Prometheus and now the new documentary about React.js came out 12 days ago. It's fantastic. Just go take a look. It's more than an hour long. It has a lot of interviews. It's really interesting and you can really feel the passion from the people actually building tools that are now used by millions. So it's really a very interesting thing.
Another point is the CloudNativeSecurityCon North America, 2023. So it took place in Seattle on February first and second. And fortunately for us, all the videos of the talks are now available on YouTube also. This is absolutely brilliant if you're interested in security and Cloud Native, which I hope you are, because security is great. Go take a look. It's everything. The problem is that you need way too much time to watch them all. That's a good problem to have.
So I would say you can start by watching everything from Andrew Martin who already gave some WTFinars here or Liz Rice who also talked here. Her talk is about eBPF and it's absolutely brilliant. It's called "picture this, solving security problems visually with eBPF". It's fantastic. It's great.
This brings me to the last point I wanted to talk about today, which is eBPF. So if you don't know what it is, it's fine. You can learn pretty fast, especially now that DevOps toolkits just produced a video on it which is called Easy eBPF, the end of Kubernetes sidecar containers. This person is really amazing at explaining complex stuff in a very brilliant way, very simple way. So go take a look.
It's very interesting and I think that if you don't know eBPF yet, you will absolutely love the video. If you already know eBPF, well, I don't think you're going to learn much in this one.
So yeah, the name of the channel is DevOps Toolkit and the person is Victor Farcic. And so if you want to go further into eBPF because it's also fantastic, you have a few books that are available. The first one by Liz Rice, which is a report of about 50 pages here. This is What is eBPF? You have another one called Security Observability with eBPF by Jed Salazar, Natalia Reka Ivanko.
Great read, also fantastic, full of great information. And then you have another one, which is kind of a Bible, it's the size of a bible. It's called BPF Performance Tools by Brendan Gregg. It has a lot of one-liners that are fantastic. And the last one that I don't have here, which is called Linux Observability with BPF by David Calavera and Lorenzo Fontana. And with it, I hope you will have a lot of stuff to check and that you will love the webinar that's coming.
Charles:
That's brilliant. Thank you, Julian. Okay, at that point we will turn it over to Jamie. I guess you need to get your slides up and running so we have the embarrassing awkward pause while we sort that out.
Jamie:
That's right.
Charles:
Because there's always a bit awkward, isn't it.
Jamie’s Talk
Jamie:
So for those people who are you new, so typically I always facilitate these but today I'm speaking. And it's the first time I'm actually speaking, so it's all a little bit strange to be introduced and then having to share my screens. I don't actually know how to do that.
Give us a second. Google Chrome, yes, that's what I'm sharing. Can you see my Google Chrome? Thumbs up will do it, please. And I'll put it into press slideshow, that should go into full screen.
All right. Okay, so welcome everybody. Welcome to this talk. My name's Jamie Dobson. And for those who don't know me, I am the chief executive of Container Solutions where I mainly, I try to spend about 80% of my time with customers and about 20% of my time building the culture and driving strategy here within the company.
I'm middle-aged, I know I don't look it. And because I'm middle-aged, I now wear reading glasses and I'm never quite sure whether to put them back on, take them off again, because I'm not used to wearing glasses. It's a new sensation for me. So that's a bit of a middle-aged update.
Now, Container Solutions itself, about 80% of all of our work is really very technical. So we're really good at migrating applications from one cloud to another or from an on-premise setup to a cloud setup, re-engineering, lots of Terraform, lots of YAML, tons and tons of Kubernetes. It just so happens we're very good at planning work as well, planning, strategy, and helping executives to figure out, Hey, how the hell do I get started with cloud? How do I set up my initial MVPs? And we do that so that people can really have a successful cloud migration.
So our superpower is to be very good at engineering, very friendly, by the way, we're known as the friendly people in cloud with the most stupid name imaginable, Container Solutions. So we're good at what we do, we're friendly, but we're really, our superpower is connecting that massive engineering capability we've got to strategic planning at the front end.
Okay, so what are we going to be talking about today? Well, 70% of all digital transformations fail. Now that's just another way of saying 30% of all digital transformations succeed, and that's what we're going to be learning about today. Why do they fail? And knowing the reasons for their failure, how can we make sure that we succeed with the work we're doing?
Now, how did this talk come about? What was the genesis of this talk? Oh, by the way, just ask questions along the way if you like. Just stick your hand up and Charles or Tereza or Carla will shout out the question if it's relevant.
So last year a little bit of content marketing dropped into my inbox from the Boston Consultancy Group. And obviously as somebody who not only communicates and writes about cloud and transformation, it's kind of my day job. And it was a really nice bit of a marketing and I enjoyed reading the article. And so what I wanted to do today was talk about that and talk about their findings, but also cross-reference it to the work that we've been doing.
And actually our customers were also reading this article, so I wanted to try to make sense of it. So the three takeaways or the three things we're going to get into today: first of all, let me discuss the six success factors, and that's a little bit of a tongue twister. So I don't know how often I'm going to say that today. Six success factors.
I want to present them to you and let you know what they are. However, the second thing we're going to do is a bit of a deep dive on just three of the success factors. The reason is is because there's a very complex interplay between three of the different factors that I'd really like to explain and I'd like us to get into as a group.
And finally, it's all well and good knowing in hindsight how and why your transformation succeeds or how you succeed with the cloud.
But what does that mean for us today? What is our practical first step or our practical next step? So I promise I'm not going to let people leave this webinar without having some sort of idea of what they might be able to do next.
I'm cleaning my glasses now, and so that's what we're going to be discussing.
So without further ado, let me first of all explain the success factors, but then I'm going to explain what I think is a really cool contribution from BCG. So here they are. Now, they're all a little bit of a mouthful. What are they exactly? Well, the first success factor when it comes to transformation is having a strategy.
Now that might seem obvious, and I think one of the criticisms you could levy at the BCG is that, well, you've done this great research, but it's picked up a lot of obvious things.
But you could give the same criticism to my book. We wrote this and it's got about 90 success patterns in, most of it we already knew. What does this mean? Well, the more times we study these things and the more we add to the body of literature, one day, just one day, the penny might drop as to what we need to do when it comes to large scale technical change.
That makes me think of smoking. For years and years, decades, we knew smoking was bad for you. And only recently after decades of public announcements and public campaigns, we finally started to stop smoking or start smoking less.
That's what I think about this type of research. So the first thing is a strategy, that's quite simple. Leadership commitment from the CEO through to middle management. This is important, but the one thing I want people to take away in this regard is you must not forget the finance team.
So the chief financial officer and their team are essential to success with anything that lasts for more than a year. So digital transformation or cloud migration, cloud adoption is a multi-year project and it has to be funded as such. If you don't get the finance bit right you won't succeed. So it's not just about chief executives and CTOs and the middle managers, it's about the finance team as well.
The third thing, they call it deploying high-calibre talent. Really what this actually means if you dig into their research and if you dig into our book, it actually means you just need a really good people function. The fourth one, you need to be agile. Okay, that makes sense.
The fifth thing, you need to monitor the progress towards your defined outcomes. Yep, this one also makes sense, and you need decent technology. This is also quite straightforward, a company like Container Solutions, we use Officevibe, we use Zoom today, we use Salesforce I think, HubSpot definitely. We've got lots of tools, lots of software that we consume that allows us to do our job.
If we need tools and software, then so do large enterprises who are moving to the cloud. Together, these will help you succeed. These are important takeaways, but the most important takeaway of the talk is this slide.
What BCG did was look at how the different success factors interacted, and this I think is the nicest takeaway. If you've got one or two or three of these success factors in place, the probability you'll succeed with your transformation is only about 30, 35, 40%. Nobody would take those odds. Nobody would put tens of millions of pounds or euros or dollars aside and take a bet on a transformation that only had a 40% chance of succeeding.
And so when you get to four or five success factors, you're still only in the domain of 55, 60% probability of success. It's only when you've got all six do you join that elite group of companies where you've got a 70% chance of succeeding.
Why is this important? It's important because we tend to have biases. Some people focus on leadership. They think if we've got the right leaders in place, everything will be fine. Others focus on technology. So the key lesson here is you are fooling yourself if you think a couple of success factors is going to guarantee your success. You're going to have to worry about all six of them.
So this specific slide I think is a brilliant contribution and I think it's something that we should definitely take away from this talk. And in fact, if you've got to run to a meeting now, this is a very nice place for you to stop and think, okay, that was a good point.
There is something, however, slightly the matter with these success factors: some of them are impossible to look at separately. They're not actually distinct. So if you take three of the success factors, integrated strategy, leadership commitment, and an agile mindset, you can't actually separate these things out. They play together.
I would say it's better to call that success factor emergent strategy. And the reason why that's important is because so in the book we cover some case studies, but we also, of course, we wrote the book a few years ago. We've done a lot more work since then. Every single successful cloud adoption program or cloud transformation program, whatever you want to call it, has one success factor in common. They use emergent strategy. And every failure has one thing absent, the use of emergent strategy.
So this is really an absolutely essential building block or success factor when it comes to transformation. This is what we're going to spend some time talking about today. The second thing is strategic execution.
So once you know where you're going, once your strategy has started to emerge, a bunch of those other success factors then reappear in a practice that we call strategic execution. We didn't invent it, a practice that's called strategic execution. So bits of leadership commitment, agile governance, and agile monitoring can be better clubbed together into a separate success factor called strategic execution.
So rather than look at everything today from... Sorry, this is an old slide, I should have deleted that bit in the middle. I'll explain that later why. But I have to delete it there because of my OCD, like that doesn't belong there, I've to quickly delete it.
The two things we're going to talk about today then. So all those success factors and how they play together, these are the two that we're going to unpack.
Right then, so let's start with emergent strategy. This is the complex interplay, and by the way, is my friend Ian on the call? Ian, are you here today?
Ian:
I am Jamie, hello.
Jamie:
Hello, Ian. Ian, for those of you who don't know Ian, Ian is my sidekick apart from when he's speaking and I'm his sidekick. So Ian's going to jump in during some of these slides because he's got some pretty good examples of this stuff. Is that right, Ian?
Ian:
Yep.
Jamie:
Awesome.
Okay, good. So this is really a very interesting thing to discuss. So first of all, is there a paradox here? This bit is very confusing for lots of our customers when they get started thinking about transformation. How can you have on the one hand a strategy which implies that you know something upfront, you know what you're trying to do, and you know where you're trying to go? And be agile?
So it seems those things possibly contradict each other, but what we're going to see in this next few slides is that that contradiction or that paradox is actually quite superficial. This is really how you should view strategy.
So when the BCG paper talks of that success factor, have a strategy, have an integrated strategy, what they're really talking about is having an intended strategy. Now, an intended strategy, it contains the things that you are going to do. It will also be reflective of your vision.
So one of the famous case studies that we helped, also we documented, was Starling Bank. Starling wanted to become an awesome challenger bank with a great digital experience and they did everything on the cloud. So their intended strategy reflected what they wanted to do. But importantly, it also reflects your current reality. What are the current constraints?
Container Solutions very first customer was ING Bank in the Netherlands, we will be forever grateful for winning our first bit of work with them, and we were proud to be part of their journey. ING had a very different set of constraints. They wanted to create awesome digital products for their customers, but they also knew they needed to win the war for talent in the Netherlands. And they also played with a very different set of regulations to a challenger bank that was based in the UK. So for example, they were not moving to the public cloud. That was not part of their objectives eight years ago.
Once your intended strategy makes contact with reality, parts of it will fail. That's just a given. Either your assumptions were wrong, or with the passage of time things changed, new technologies came out, markets changed, regulations changed.
This is important, because the thing that allows you to jettison parts of the intended strategy is agility, the ability to learn on the fly. And it's exactly that agility that then allows you to bring in new ideas, so-called emergent strategies, into the final realised strategy. And this is the crazy thing about strategy. You don't know what the realised strategy is until you've got there. So you can only possibly know that in hindsight.
This is why strategy and agility go together hand in hand. So this is why I said they're not really distinct success factors. So I hope that started to answer a bit of a paradox for you. However, now we're going to dig a little bit deeper.
So we know that good strategy requires agility. And both of those things are required for successful transformation. Why is agility so very, very difficult? And I think the problems with agility, they might not be exactly what you think.
Let's start with a simple definition, not a simple definition, let's start with the definition. Agility is simply learning through your experiences, sometimes through successful ones, but mainly through failure. Failures teach us.
So when we fail and we analyse what's gone wrong, we learn. So in the very beginning, the agile software practices test driven development, you wrote a test that failed, learned something about your system, and then you got the test passing.
Agile project management, originally written about by Jim Highsmith, but of course changed into many different forms. You do some work, you have a retrospective, you look back at what worked in order to see if you can succeed more in the next iterations. Agility is simply learning through experience. That's all it is. And if you're not learning through experience, you're not really agile.
Now, what this means is those companies who have learnt to learn from failure, they have a constant upward trajectory, they get better every year. And they dominate their marketplace, they seize competitive advantage or they grab it, and they keep it. What this means or what we can conclude is that learning from failure is not an autonomous practice. It isn't autonomous. If learning from failure was autonomous, every single writer's next book would be better than the last. Every entrepreneur, and I am an entrepreneur, would be a gazillionaire. Every business venture they had would succeed.
There is nothing autonomous about learning from failure. Now, luckily for us, somebody has really documented and studied this extremely heavily, because if it's not autonomous, what are the things that we have to learn in order to learn from failure? So luckily Professor Amy Edmondson, from she's at Harvard, I think, she documented what it is to be what she calls a fearless organisation, but what is essentially an organisation that learns from failure and she collected her findings into a book.
It's a great book by the way, and it's something that we teach, but it's also something that we've implemented at Container Solutions. We don't always get it right, but we aspire to get it right. What did Edmondson learn?
Firstly, number one, you need a supportive learning environment. So what this means is that people are given a space to reflect and people are given a chance to take risks. Secondly, concrete learning practices, not wishy-washy learning practices, not trying something, and then if it doesn't work, go into the pub to discuss it.
Well, actually that maybe is a learning process, but you need more concrete learning processes than that. We're talking here about experimentation. The design of experiments, and then seeing how those experiments fare in the real world. It's also about retrospectives, it's also about training, gap analysis, skills analysis and stuff like that.
So you have to have concrete learning processes and practices. And then finally, you need leaders who reinforce learning. That is to say they're happy to take risks in public, and should those risks come to nothing or lead to a failure, to share and own those failures in a public setting.
When a leader does that, they're sending a very strong message to their people, it's okay to fail, which is really another way of saying it's okay to learn. So I don't know what you think, but I quite love this point of this talk. Because at this point in the story, we've now got three concrete things that an agile company needs to implement.
And we know that any company that wants to succeed with transformation has to be agile because agility and strategy are key success factors. I think what I'm trying to say is without becoming a learning organisation, you're going to struggle with any type of transformation. Transformation is essentially a learning process.
So why is this so hard? What is it about these practices or these things that Edmondson found out that makes it really difficult for companies to adopt?
Well, actually, let me tell you a little bit of a story. About five or six years ago it would be now, Pini and I, that's the other co-founder of Container Solutions, we were busy setting up a project. And of course that required building lots of things, but in the beginning, doing some strategic planning, what is it we're going to do? What's our intended strategy? What's going to be our cadence? Well, how often will we meet? And what's our MVP?
We got going with this work and three or four months in, we presented to a bunch of stakeholders, executives, their seconds in command, et cetera, et cetera, and they did what executives should do on a transformation project.
They asked us what had been happening, had we achieved our goals? They offered guidance, offered support, but we also got chewed out a bit because some of the things we did were late. We could have scoped them differently. Was it a fair chewing out? Yeah, probably. It wasn't disastrous. So I retreated with my counterpart from our customers and I asked, "What do you think we could have done differently?"
And this was met with bit of a stony silence really. And I said, "Well, I think we could have scoped that differently." And I also said, "I think I personally did something here that I wouldn't have done if I could play that back again." And what I was trying to do was figure out what we'd done wrong so we could then discuss it with our teams and say, "Hey, we've been chewed out, but as the leaders of this work, this is what we've done wrong."
Now this is the third part of Edmondson's building blocks, leaders who take risks and when they fail, they own them. And we've been over this with my counterpart. We've been over this plenty of times. And anyway, in the end when I asked, "What is it that you could have done differently or what did you do wrong?" My colleague actually was quite angry at me, and they asked me, "Are you trying to get me kicked off this program or are you trying to cost me my job?"
And so there is something about large enterprises that make it difficult for you to speak up and own failures, and mainly it's because you're punished for them. So when we talk about digital transformation, what you're really asking is for the people involved in that transformation to change the way they operate. So you're going to ask individual managers, leaders, employees, you've now got to change the way you operate. So a personal transformation has to then occur.
So what this does in terms of becoming more agile in order to succeed, it presents some serious, serious challenges. The first challenge is around safety. Many people have different safety needs. Some of us have greater safety needs than others. If you have greater needs for safety and certainty and security, you are likely to be drawn to an enterprise with strict rules, strict structures, and regular ceremonies.
Unfortunately, the type of people who are drawn to an organisation are exactly the type of people who can react quite violently to potential change. But that's what transformation is, whole scale change. So there's a fatal attraction baked into large organisations. The second thing is around cost control. Most companies, if you don't manage your costs, you die as a company. It's as simple as that. And so most mature and large companies have learned to control their costs really well.
That means they become allergic to what looks like wasteful processes, reflection, and retrospectives. This all feels to hard nosed enterprise people a little bit left wing, a little bit like getting in a circle at Woodstock to talk our problems out.
But ultimately these, I'll do air quotes, these "wasteful processes" are essential for learning. And actually when you've got a plan and it fails, you do pay a price, but that's the price you have to pay to learn something new. And over time, those lessons will build up to give you great competitive advantage.
So cost control is a real issue. And then of course, the other thing is risk taking. Most companies like to be predictable, especially if they're on the stock exchange. Nobody wants to buy stocks or shares in a company that's price goes up and down, up and down. So the people who run large publicly listed companies are rewarded or bonused on hitting their numbers, regularly hitting their numbers.
What this means is from the very top of an organisation, right the way through it all, risk is stripped out in the hope that things will become more predictable. This means that failures or risk-taking, and then risk taking and subsequent but predictable failures means severe punishments, ostracization, loss of status. And because executives are bonused on success and predictability, the genuine loss of money. So if we're to transform, we have to become agile, we need to overcome these three significant challenges.
So in summary for this little section, emergent strategy is the genuine success factor when it comes to transformation, but it relies on an organisation that can learn from failure, which in turn relies on people who are not afraid to take risks. Often the exact opposite of the sort of person that is attracted to a large enterprise.
So this is really section one of this talk. If you can understand the interplay between these three things, you can start to think, well, how do we become more agile?
Well, probably you need some new leaders or you need a new set of leadership behaviours. And you need to start practising practice, practice, practice. Because the more you learn from failure, the more you fail and the more you learn from it, the better you'll get at it.
There's no questions, okay, people just sharing. Oh, thanks for sharing the link, Mandy. That's great. Yeah, so Mandy has shared the link to the fearless organisation in the chat box if people want to follow that.
Okay, so you've figured out your strategy, you've started to become more agile, and you've hired or you've built a leadership team, or you've built leadership capability right up and down your organisation, and now you're moving.
So this comes then to the second serious success factor when it comes to transformation, execution. And with this particular success factor, we can start to think about killing three birds with the very same stone. One of the birds we're going to kill, by the way, I don't really think you should kill birds, it's just an expression, just FYI. I don't think you should throw stones at birds. The three birds that execution can kill are as follows.
Lots of people, lots of literature, lots of books, lots of talks will tell leaders you've got to engage with your people, you've got to support them and fail in public and all of that stuff.
But how do you do that? How does a leader do that? You need a platform to activate your followers. So what strategic execution does is give leaders that platform to cascade messages, to set goals collectively, and importantly to share wins. Because the key to transformation is energy. It's strategy, short strategy, but it's energy. People drive change. So more than anything, it's about keeping momentum up and morale high. Real man or woman or people management.
Second thing is good strategic execution is agile, because basically in the world of the learning organisation, there isn't such thing as a goal. They don't really exist. What you have instead is hypotheses. So when people talk about the sprint goal, it's the wrong terminology. What you've got is a hypothesis. You believe you can do this bit of work. You believe you can migrate this application, you believe you can build this feature.
You then test your hypothesis in the iteration, and if you succeed, your hypothesis was shown to be correct. And if you fail, you learn from it, applying the mistakes you've just made and the lessons you've just learned to the next iteration. So good strategic execution framework allows you to learn on the fly. It allows you to become agile, which of course we just saw was a key thing for all transformations to succeed.
And of course a good execution framework lets you monitor work in progress along the way in order to change direction. So you might be thinking, okay, that sounds cool. Practically what does that mean? Well, actually there's some good frameworks out there for strategic execution. I'm going to pick up a book now. Anybody know this? The hero transformation playbook, it's quite a nice book actually. Section three, transformation delivery. What is in this section?
This is their strategic execution bit. What is in there? There's a couple of well-defined roles. Work stream lead, initiative lead, they talk about values, philosophy, transparency. They've got a Kanban board for moving blockers, and they have a process for escalating blockers. And that's where you see it's super important to have senior leadership support, because without it, who are you escalating the blockers to?
So strategic execution, a good strategic execution framework will have all of that stuff, which, in short, is a bunch of meetings and a bunch of roles that give leaders a chance to monitor and drive a program forward. Essentially it's about breaking a strategy into objectives, getting them organised, and then pushing them right through your enterprise. You might think strategic execution looks like this. This is a very common way of getting work done in large organisations. Install JIRA, chuck up a bunch of stories, and then ask those three questions all the time.
This is one way to get work done, but we wouldn't consider this to be the best strategic execution framework in order to do large scale transformation. Why? It's not a trick question, but if you've been listening, if you've been paying attention, you'll understand the real reason why agile, agile practices are popular in large companies, because they're the type of ceremonies that run regularly.
The type of people who are drawn to large organisations have stronger safety needs than the general population. And people with strong safety needs love ceremonies. So the reason why Agile's popular is it's not because people in big companies like to learn from failure, it's because they like predictability and regularity. This is why "Agile" is so popular right now. It's not about learning from failure, it's about having predictable working rhythms. So by the way, we also have our own strategic execution framework.
We follow trimesters, we have breaks in between our terms. We don't take those terms off. We actually do work there, but we have big reflective breaks within our framework where we learn about what just happened in order to apply it to the future. We've used this model to devastating effect, helping our customers to become cloud native or to move to the cloud.
This was the slide I really wanted to show you. This is a really important takeaway. The beginning of a term, there's a public meeting. Lots of people have Mondays, Mondays when you get together and plan the work. And in between you've got town hall celebrations. At the very end you've got a public meeting. It's these meetings that give leaders a chance to activate their followers. So the BCG paper was correct, you do need leadership support, but what does that look like?
Providing guidance, celebrating wins, and being visibly and physically present. That's what these meetings give you. So it's a superpower. It's a superpower to tell the whole organisation, this is the direction we're travelling, this is the direction of our flight right now.
So now let's start to think about wrapping this up. And obviously if there's any questions, I really look forward to that. So this is the big practical takeaway. If you think you're going to succeed by choosing the two success factors that speak most to you, you are very, very much mistaken. You might as well not continue. You've got to look at this holistically. So go back to that one idea, an integrated strategy, and think about what does that mean?
We need to have a decent people function. We need to have leadership support up and down the stack, including from the finance team. We need to have decent technology so we're not doing manual work so we can focus on the job at hand. You need to be able to monitor your objectives. All of these things need putting in place or need to be developed on the fly if you're to succeed with transformation.
If that's one thing you can take away from this talk, take that away. And tell your bosses before they pull the trigger on a multimillion pound program of work, tell them to take a look at this slide.
These two things are key:
Emergent strategy's the single most important success factor in any transformation. Building a more agile leadership team and workforce is absolutely key to that. That doesn't mean getting rid of everybody and bringing in a whole new bunch of people, but it does mean acknowledging that first of all, people with stronger safety needs are drawn to large organisations There's nothing wrong with that, but it needs to be spoken out loud. Because once we understand that, we can think about different behaviours, we can think about training, and we can think about supporting each other as we learn to learn from failure.
Strategic execution will help you learn to learn from failure because it will force you to do it in every cycle of the execution. Of course, execution allows leaders to remediate plans. That's quite important. But most importantly of all, it gives them a chance to activate their followers. I cannot understate this more. Of all the programs we've looked at, when there's a cadence, a bunch of meetings that connects senior leaders to people driving the work forward, it goes quicker. When that platform's not there, I think success is almost impossible to achieve.
So that is it in terms of the talk. I've never done this talk before, so if I've gone on for too long or for too short, I apologise. I realised I forgot to bring Ian in. I apologise for that as well. So I would appreciate any feedback. And of course I would appreciate any questions.
Before we go today, I've got a question for everybody else. Carla, don't let me forget to ask that question.
Q&A
Carla:
I won't. We're ready whenever you want us to launch that we can.
Jamie:
Exactly, cool. Does anybody have any questions at that point or anything they'd like to share? Any observations they've seen with transformation or large scale tech programs where things worked or didn't work?
Charles:
Well, there is a question in the chat, Jamie, which is what about the people aspect that you removed from your slide?
Jamie:
Yeah, that's a great question that actually. That's a great question.
So Ian actually, he convinced me to take that out so it's his fault.
Ian:
People know better!!!
Jamie:
Let me get my old slide deck up and let's just take a look at that specifically. So first of all, let's pop that to the back. So first of all, the story I really wanted to tell, but I was a bit scared of overloading everybody with too much information. And this is why I might come back to this at a later time.
Originally, this was the story, well, this was the conclusion I wanted to draw. Number one, you need an emergent strategy and for that you need an agile workforce. Number two, you can only build a workforce with a strong HR or people function. And number three, once you've got those two things, you can think about executing that scale.
So the slide I had about people was basically this one. Now, in the olden days we used to call the people team personnel. People thought that was obnoxious. And then we started calling personnel human resource management, and people thought that was even worse. Nowadays we have people ops or just people, but I do think human resource management is probably the right expression here.
What does a HR team, a really good HR team do? They'd have policies and systems. Fine. Now there's feedback. Does our audience really care? Does this section need dropping? Well, apparently somebody in our audience cared, Ian!
So what is transformation? You're going to need new types of roles. Engineers, architects and transformation people. How do you hire into a new role? You have a great job description and job spec and you have a competency model. Who are the experts in building those things? The people team. What else do the people team do? They create awesome hiring processes and then link back to the main program of work through a hiring manager. And they do training and development, and of course they drive organisational change.
There is a difference between HR and strategic HR. So strategic HR literally speaks to the business and says, what do you want? What do you need in 12 months and 18 months? If we know what our strategy is for our transformation and we tell the HR people, they will start to build what's known as a strategic workforce plan.
Now, it's not very sexy, but it's absolutely key to success on large scale digital transformation. So that was the people element that we didn't talk about. Clearly that's going to be a success factor in any type of work including transformation. Does that answer your question? Who was it? Laslow asked it. Does that answer your question, Laslow?
Laslow:
Kind of. Yeah, okay. So here's the thing. What I see happen in practice a lot is there are competing priorities, personalities within an organisation in practice. Without going into too much bashing here, do you have anything you can say on that aspect?
Jamie:
Well, yes, the reason why... So program managers, and if there's one role on the customer side that's similar to my role as the chief executive is the program manager.
Program managers, they need to use influence. They set off work streams running, but they don't project management. They have to trust the people that they've put in place. So that's one thing. You need good program managers. They learn, another thing they have to do with is egos competing, what's the word? Competing in initiatives and all of that. Strong leadership comes from aligning people.
Simply put, the best programs that we've been involved in sees the active removal of people who don't share the values of the transformation. So anybody who's putting their work, their own private agendas ahead of the transformation will be removed.
The reverse of that, good leadership and good HR planning sees people who contribute to the transformation rewarded as part of their appraisals, performance reviews, and chances for promotion. So if this is done properly, those type of people will actually be managed out or trained, and that's how it's done.
Laslow:
Okay, that's my question. Has anyone here seen examples where this was done properly?
Jamie:
Well, I see it every single day because I work with customers who are really succeeding with this.
Ian:
I have an example, quite a vivid one from my experience. So years ago I worked with a company that had to change their base backend platform from a failing one that cost them 25 million to a new one that we were providing. And the CEO was behind the project.
And what he did was he said, "Right, we're moving our base platform from A to B and it's going to take seven months." And everyone had a sharp intake of breath and said, "That can't be done. That's just impossible. You're crazy. The CEO has gone mad, he's out of touch, he's got no idea what he's doing."
But he was very, very smart this guy. And in every single meeting to discuss the changes that need to be made, he had someone he personally knew. So three or four people who reported directly back to him would sit in that meeting, and say to someone who said, "I really need this feature for this to be transferred from the old system and new system," they would ask the question, "Do you really need that for go live?"
And if the answer was yes, they would say, "Do you want to go and explain that to the CEO while you are going to hold up this whole change just for your little particular feature?"
And 99% of the time they said, "Oh actually, you know what? I don't really need it. Let's do the simplest thing that gets the job done."
Jamie:
No, you go on ahead.
Ian:
I was going to say, and if they still insisted, they would then go and meet the CEO and explain. And if the CEO didn't like what he was hearing, there would be consequences.
Jamie:
Yeah, so this is a good question. So when we go back, Laslow, when we go to strategic execution. So when you asked me about the people you didn't actually mean, tell me about that people bit, what you meant was how do we deal with people with a separate agenda?
Well, strategic execution has a way of tracking blockers and a way of escalating them. A blocker would be escalated, so if somebody is pushing their own agenda, I have a bit of a bad cold today, sorry. If somebody's pushing their agenda, that's going to become a blocker. And in a meeting, in a steering committee with the most senior people on board, that person will then explain why. They'll say, "This is the reason we can't move this work forward."
This is why strategic execution and top to bottom leadership support are essential. If you don't have those two things and that type of behaviour will dominate the program and it will fail.
You need strong leaders, really strong leaders. The other thing about workforce planning is that some people are too scared to make layoffs or redundancies. And what that means is it often gets put off to the last moment and then an external person is coming to do it, and then it can be extremely brutal.
And it's a part of transformation nobody ever wants to talk about because it's just not very nice. Gus, my favourite person in the whole world. Gus is the mastermind behind ESO by the way, everybody,
Gustavo:
Just to also compliment on that, Jamie, how both program leadership and project or even lower leadership is important, because this is actually the flow where we can get this kind of different agendas should be actually even be noticed.
So it is important for the people that are on the working ground to have a clear channel, to have a trust relationship, to go to the program themselves and actually relate that these things are happening. And then up to the strong program person leader to actually act on it.
Jamie:
Gus and I have worked together for a long time with some very talented leaders, the leaders we work with don't always look... They're not always the best dressed. They don't always have shirts and ties and are very proper, it's an action sport. They really know how to get stuff done. And good leaders are in there challenging people, confronting people, moving things out the way. That's how you're in a transformation when you see that sort of hands-on behaviour.
It does sometimes mean we shout each other, but we always say sorry afterwards. But that's because what we're doing is high octane.
Any other questions? Let me check in the chat box.
Carla:
There is a question in the chat actually from Lynn.
Jamie:
Yeah. Hey Lynn, welcome. If it's your first time, welcome at least.
Charles:
So yeah, that question is, you can read it yourself I guess Jamie...
Jamie:
I'm reading it now. There are so many success factors, but what would you say is the most fundamental aspect to get it right? And in your experience, what are some of the most common challenges resistance with this element?
Okay, there are many contributing factors. The first one, we did a bit of research. Actually my colleague Anne Currie did some research a few years ago. And she studied the Financial Times. Who else did she study, Charles, the FT?
Charles:
Starling Bank was in there, I should remember the others, sorry,
Jamie:
Also middle-age.
So Starling Bank, maybe ING, maybe some of the financial institutions. If they didn't go to the cloud, they were going to die. So a common thread was an existential threat. Nobody does this transformation stuff unless there's a gun pointed right at your head.
So I'm not sure if that's a success factor, but it's definitely something that appears in lots of these transformations. I think the most important one is emerging strategy, but that's a bit of a cheat because it includes three success factors. But emerging strategy only comes from solid, solid leadership. People whose egos are strong enough that they're comfortable to learn from failure.
So where you see emerging strategy, you'll find good leaders who are agile, who have got a bit of a brain in between their ears. This is probably the most important one.
Yeah, executive commitment for sure. Without executive commitment, forget about it. Cloud is an all-encompassing activity from the board level to the C level. So if you are speaking to someone who says, "Yeah, we're just going to do cloud in technology," forget about it. So you need exec commitment and it's got to include the finance people.
Lynn:
Thank you so much for that. What would you say are some of the most common resistances that you get when you're going through in your speaking to these leaders? Maybe they're not fully on board with Agile or learning and failing fast.
Jamie:
It's probably that actually, it's probably resistance to learning. So people, they get it in their head. So there's reason we say hearts and minds. We don't say minds and hearts, the head follows the heart. People rationally understand failure, but they're just not quite ready.
You can't really blame people. You are asking them to become entrepreneurs, to take risks, to put skin in the game.They haven't been working at a large company for 30 years for that reason. So that's probably the biggest one. That being said, there's lots of very, very good leaders at large enterprises who understand this, and they know how to slowly awaken their organisation, to coach them, cajole them, et cetera, et cetera.
So changing that need for safety and creating that different set of behaviour, that's really important and a very common blocker.
Charles:
We had one or two questions submitted before the session. Some of these we've actually already answered and some of them sound very, very specific. But I can't resist asking you this one, which is, "I work for Dutch government agency and our IT organisation started their Agile transformation 12 years ago. Our business started their Agile transformation by introducing SAFe. Is that disaster waiting to happen?"
Jamie:
Yes, absolutely. Are you crazy? SAFe, please don't hold this against me. Or if any of my friends are watching, please don't hold against me what I'm about to say.
People are drawn to large organisations for their rituals. So by the way, this is funny. People whose safety needs were not fully met when they were children, they grew up with higher safety needs. There's nothing wrong with that.
Some people are drawn to large religion because of its rules and because it explains the universe. And before all of you engineers sat there thinking, oh, those religious people. Well, engineers and scientists are drawn to science and philosophy for the same reason. Because it gives them a coherent explanation of the world.
So if your safety needs were not met as a child but you're not religious, you shouldn't make fun of other people because you might be drawn to philosophy for exactly the same reason.
The routines suppress anxiety. When we know what we're doing on Monday and we know what we're doing on Friday. In the annual general meeting when the chief priest, the CEO gives worship to the market and everybody says, Amen, it's all ritual and ceremony.
Ritual and ceremony designed for one reason only, to reduce group anxiety. So to answer that person's question, is this a fatal mistake you've made? Yes. Because you've chosen a framework called SAFe. Do you think it's a coincidence that the people who use SAFe have got stronger safety needs? I don't think so. It's got nothing to do with progressing work and it's got everything to do with feelings of control and reducing anxiety. It's a sack of shit.
Charles:
We do have a counter example. We do have at least one client.
Jamie:
We have one what?
Charles:
Sorry to put you on the spot. But we do have at least one client that uses SAFe successfully, and I was really surprised. But it does exist so it can be done.
Jamie:
It's a client that probably I'm not working with. First of all, for God's sake don't mention anybody's names on this call
Charles:
No. No, of course not.
Jamie:
And I'm ready to call that customer and retract everything I just said. Maybe they've succeeded in spite of SAFe, or maybe for their context it's dead right. Ian wants to speak.
Ian:
I can comment on this because I worked with that customer recently. So I'd experienced SAFe in various enterprises where it had been an absolute disaster. It was really lipstick on a pig, and it just didn't actually change the fact that it was still waterfall mindset and a risk averse mindset.
And then I was confounded when I found one organisation where it was working very well. The reason it worked very well is because it was an engineering organisation, first and foremost. Everyone there was an engineer. That was the first point.
The second point was that they embraced it properly. They actually studied how it was done and followed the rules of it. And the third reason, which is related to the second one, I think, is that they had budget cycles based on the SAFe cycles.
So every three months they would rebudget, and they would spin up teams and spin down teams and decide what they were going to do. And so because they could actually respond to what happened in each three month period, they were actually agile, albeit on a slower cadence than two week.
Jamie:
Thank you for that, Ian, thank you. There's a small conversation happening in the chat window. I'd like to address that now. So Ben has said ritual and ceremony could be argued to have other values too, that I agree with. So in the olden days where we used to fight wars, and I say we, poor people used to fight rich people's wars, but most soldiers were peasants. They were a rabble, they'd never met before.
And we had to quickly get peasants ready to fight other country's peasants. And so that's where military drills came from. So we did things, we walked in a set where we turned left, and we quickly learned to do drills because we had to quickly organise into a fighting force with people we'd never met. That was a type of ceremony that had value.
But then later when the battle is finished, we start to build an army, we are still doing those drills. And then what do we do? We get dressed up in uniforms and we parade, and we do the military drills in front of the queen or dignitaries. But we were still doing military drills in 1913 and 1920 based on drills that had been designed for peasants 100 years earlier. This is after we've invented tanks and guns.
So one day's drills becomes the next day's ceremonies. That's exactly the same that happened with Agile. We did TDD and retros and all of that stuff because they were really valuable. And then all of a sudden people said, "Well, we want to be agile too."
But they thought they could just copy the practice. So the value adding rituals over there in one day became the next day's ceremonial rituals. And they're different things.
And Gus says the danger you here is having rituals and ceremonies for the sake of rituals and ceremonies. That's correct. So when I talk about rituals and ceremonies for their own sake, to reduce anxiety that's exactly what I'm talking about. Does anybody, and I'm going to tell you the power, the power of rituals right now, is anybody scared of the number 13?
No.
But you are aware that thirteen is scary for some people. It's got a name. Does anybody know why we're scared of the number 13? I hope you don't, because I want to tell the story.
Okay, somebody who's good at maths, there's a few engineers here. What's four times seven? What's 13 times 28? I'll tell you, it's 364. So in the olden days, we used to have 13 months, each month had 28 days in it, and that meant we had an orphaned extra day.
The 365th day. That orphan day was, I believe, I think it was the 24th of December. And it was the day when the sun set lowest in the sky. All of our ancient ancestors, and I'm sure there's people here who know more about this than I do. Our ancient ancestors were really scared of the sun looking like it was going to die.
So on that one day, we sacrificed things, children, people, and then later, because we became more civilised, we just sacrificed animals. The whole 13th month was about preparing for these ritual sacrifices. And Europe is full of pits of bodies that have been sacrificed in the past. So we became in the western part of Europe terrified of the number 13 because of all the things that it indicated.
But none of us knew about this. Most people don't know that that used to happen. And yet, 65% of elevators in the US do not have a 13th floor. They have 12, and then it goes to 14, 65%.
So we are irrationally afraid of 13. That's the power of ceremony. Once upon a time that meant something, and now we just do it without even thinking. True story. Look it up, you'll be surprised.
And then of course, after the sacrifice, this was the worst thing. After the sacrifice, the sun came back up. So everybody said, "You see, the sacrifice has worked. And we better do it again next year."
And that's how these things happen.
On that note, I don't want to bore people. I can see that not many people are dropping off, which usually is a good sign. Before you start to lose concentration I've got one favor to ask. So first of all, if you got any feedback for us about this talk or these webinars? We actually really, really do care what people think. And I, I'm back everybody. I am back in sales and marketing after spending three years trying to lead the company through the COVID pandemic.
So I'd like to adopt my content and I'd like to tell stories that you want to hear. So first of all, if you've got any feedback, please let us have it. Secondly, these are the things that we didn't talk about today. Is there something you'd like to talk me to talk about next? So Carla's going to help with a poll. Would you like me to do my next webinar about the psychology of leadership, which definitely includes ceremonies, safety, risk-taking, incompetent leaders. Would you like me to talk about strategic workforce planning?
And I promise it's the most boring subject on the planet, but I'm going to work really hard to make it extremely interesting. But you're going to also learn how important it is in terms of transformation.
Alternatively, would you like me to talk about platforms and how they drive sensible transformations in large organisations?
And we'll probably in the end talk about all three, but I'll do them in the order that people are interested in. And I can see people are voting now, so thanks for that. Oh, tech platforms, seven votes. Who would've thought that a bunch of people who come to our webinars would want to talk about tech? But I can do that. I can do that.
Carla:
Two more minutes and then we're going to close the poll and reveal the winner.
Jamie:
Okay, in that two minutes. Is there anybody want to jump in or grab the mic? It's not two minutes, but it's 50 seconds left, Carla.
Carla:
That's fine. That's fine.
Speaker 9:
I made a few mental notes during the talk. Because what I noticed few times that it's a big issue or a big obstacle that there are no value streams defined in a company, but it is organised based on silos. And I think those have to be overcome in order to be able to have any type of OKR planning.
Similar a few kind of vicious cycle, because I think there is this efficiency paradox when these type of companies are focusing more on resource efficiency and not on full efficiency. Because they're focusing on resource efficiency there is a high utilisation, which means that the lead time is very high. Which means that they have to work in big batch sizes, which means that the feedback is very slow.
They have to make big decisions, but making big decisions is usually takes more time, which makes this whole cycle even more vicious because the work in progress is just getting bigger and bigger. And I think these are some mental shifts that needs to happen as well, because otherwise it's very hard to make any type of transformation.
Jamie:
So ultimately you can't change it. You need to change all of that stuff to change the wider organisation. So my hero, Andy Grove, he talked about in times of change let chaos reign. You have to relax your organisational structure, and then once the transformation's starting to take hold, you then reign in chaos. So that's a play of words. To let chaos reign means to let chaos rule. And to reign in chaos, it's what you do to a horse, you pull it back, it means to start to control it.
So ultimately you can't change with structures like that. You just can't. And you can't do OKRs with silos, and in fact, OKRs in a siloed system strengthen the silos. Because what you end up doing is making [inaudible 01:09:08] as long as we hit our objectives, it doesn't matter. It literally drives siloed thinking. And OKRs will do that anywhere. If you get a good team that's cross-functional and give them OKRs without guidance, you'll create a siloed company within one year.
So objectives and key results are a very dangerous tool actually. You want to be careful, because often where you find weak leadership you'll find a strong use of OKRs. Because bad leaders think, oh, if we set an objective the team will fix them. That is some bull shit right there. That is really some big bull shit.
Right Charles, should we let people go or should we try to push on for another minute or two?
Charles:
I think there was one more poll you wanted to run, wasn't there? Wasn't there a feedback poll?
Jamie:
Oh yeah. It wasn't a poll, but just to ask for people if they could provide me with some feedback for today's talk. I really appreciate that.
If people don't mind, I'm probably going to reach back out on email to share my notes for today and then figure out what we want to do next. So not a poll, Charles, just a more general request.
Charles:
Okay, then I think we can probably wrap it up, Carla, Tereza.
Carla:
Yes, absolutely.
Charles:
Brilliant. All right, thanks everybody.
Carla:
Thank you all. Have a great rest of the day.
Ian:
Thanks, bye.
Laslow:
Have a great day.
Previous article
