Mirco Hering

My talk is What Got You Here Won't Get You There: A Story of Transformation. And what I'm going to do over the next half an hour is really share a little bit about my experiences with helping organizations make progress in DevOps. Not achieve DevOps, because that's kind of an elusive goal, but how to progress.

No one is doing an introduction, so let me just quickly go through this. I'm working for Accenture. Accenture does a lot of stuff. You can see that on the left-hand side. We do complex things with lots of clients. But this is not necessarily about what Accenture does, but more what I do in my job, and who am I?

My name is Mirco Hering. I've traveled from Australia, so I'm perhaps the second furthest-traveled person after the IT Skeptic from New Zealand. I've been here for a week already, so I'm not too jet-lagged, so it should be okay.

I'm leading our DevOps and Agile practice in Australia, in APAC, but really we just call it Good Delivery. At the end of the day, Agile and DevOps is a means to an outcome, and that's really that we are delivering solutions better. Good Delivery doesn't sell terribly well, so Agile and DevOps sells a lot better. That's why the practice is called that.

At work, I run a passionate team of transformation agents. We are about 60-odd people in Australia. And what we do is we work with our clients to help them deliver better solutions in a faster and more reliable way.

I do blog at Not a Factory Anymore, and I now can call myself an author, so I can tick that one on the bucket list. My book is called DevOps for the Modern Enterprise. Some of the stuff that I'm going to talk about here now is obviously in the book. If you've listened to the talk, you might not have to buy the book, but it would be still appreciated if you do.

And there's a signing of the book later on at this Pearson type, so you can actually get a free copy, which is not great for the author, but it's okay for now. So you can come by and see me there.

All right, so let's get into the actual talk.

But it's only fair to mention What Got You Here Won't Get You There, a book. Has anyone read this book? No? Oh, a couple. It's a fantastic book, especially if you're like me, a technologist or an engineer at heart. As you're getting into management, there's a lot of things that stood you well when you were younger, more junior in your career, that start holding you back, and that's what this book is about.

Very similar, there's this kind of change of mindset in DevOps transformation that we need to get through, which is the inspiration for this talk.

All right. I've been in this for quite a while, and I think about a year or two ago I wrote an article for DevOps.com called "Why are we still fighting with the same problems in DevOps as we did 15 years ago?" And I found this really puzzling.

And the first part of this talk, I really want to take you on this kind of discovery journey that I went through. Because when I went into IT 15 years ago, I was doing mainframe code. Has anyone here done COBOL? Yeah. So you will hear a couple of stories that you might appreciate, and no one else in the room will understand what I'm talking about.

But I came from uni. I'd done Java. I'd actually studied in Edinburgh for a degree in artificial intelligence. And then my very first job... Well, I did manual testing first, and then I did COBOL programming. How cool, with an AI degree? Nowadays, with an AI degree, I believe you become CEO of a startup, and I did mainframe COBOL.

But what we did is we had some really terrible automation scripts that automated our build process, our deployment process, and that was just the way that we did things. And then I went on and did a couple of projects, and then 10 years or 15 years later, I wake up and I go to organizations, and we still have the same problems, right?

We still don't have reliable build processes. We still don't have 100% automation of our deployment process. So what happened? We've got all these cool tools. I did automation with Control-M. Yeah. And now we have Jenkins and all the commercial products. So why are we still struggling with that?

And I will try to give you a little bit of an explanation, but one part of it is that I think we have the wrong mental mindset. And it was appropriate at some stage, hence the what got you here, but it's not appropriate anymore. So let's have a look at that a little bit further.

I found this little diagram on a website called BetterCodex.org, and I find it quite interesting because it describes a lot of what happened. And this is called the Taylor Bathtub, if you've never heard of that. And the idea here is really that in the very olden days, we had this age of craft manufacturing, right?

We created a table or a cart or a house, and it was all very artisan. It was all very much about the people that you hire to do the job, and you had to trust them, and everything was around that.

And then we went into the Taylor moment, where everything became machine-based, and people were just a means to an end: the assembly line, the cog in the machine.

And now we're getting out of that again into the age of global markets, where it's really important to be very quick and be creative.

And I think that has done us a disservice because in the Taylor trough, we kind of got into the maturity of our IT organizations. And that meant we took what we've learned in manufacturing and applied it to IT. And while that worked many years ago, it is not working for us anymore.

And so when I started working in IT 15 years ago, we didn't really have offshoring. We had some level of outsourcing. But to really have productivity gains in any shape, way, or form, we had to automate. We had to go the hard miles.

And then we started finding shortcuts, right? There were commercial products, there was offshoring, and all that allowed managers to just take something, move it somewhere else, or install a new product, and you got savings. And that was much easier than doing the hard yards of doing the hard engineering and actually solving the problems.

And so we're coming out of this now, and we are still struggling with that kind of mindset.

Add to this that we had this kind of transformation life cycle. I'm not talking about your organization. If you find yourself in any of these pictures, that's not my fault. But this was kind of common, right?

We had a business problem, and then we went on a transformation: a three- to five-year transformation, an implementation of an ERP system, of a CRM system. Well, you could say a DevOps or Agile transformation, for that matter.

And then we got to the end, and it was hard yards at the end. We got it over the line. We achieved the end state. Any architects here in the room that have talked about end states? Right. So we got to the end state, and then we started thinking about cost reduction because now we've achieved it, right? We've supported, we have achieved the end state. We only need to support it.

And we start accruing this tech debt until we get to the point where we can't change anymore. It becomes too expensive, or the CIO has changed and now we're going with a different solution. The next product vendor has been playing golf really well and sells you the next product. Right? And then you start the cycle again.

Now, that's a fantastic business model for vendors, consultancies, and all those kind of people, including myself, but it's not really rewarding at the end. And what is worse, this is really a three- to five-year cycle. Now, 1990s, three- to five-year cycles are not a problem. Nowadays, in a three- to five-year cycle, your organization might have been disrupted by someone else and you're gone. So you can't really afford this.

So what you really need to get to is to this world, where you get into this, well, hopefully your last transformation that you ever do, into a better way of working. And then you want to continuously improve afterwards, and you need to figure out how to have this kind of ongoing stimulus.

Now, I'm a very simple person. I like simple analogies. To me, this is a bit like diet. What you see here is we do the 5:2 diet, and then we do the CSIRO diet, and then we do something else. Right? And once you've achieved your target weight, then all of a sudden that one extra muffin is okay. Right? And you know how that is.

And what we are now telling organizations is, well, rather than doing the next diet, you really have to eat less and do more sports. That's not really a good method. It doesn't sell as easily as the old transformation did. But that's really the equivalent of what we need to get into.

And the key thing here is to find when you kind of start dipping, and what are you going to do to create that stimulus forward.

So let's have a look at the idea of the mental model that I mentioned earlier. Mental model is really, we all live in the same reality. I mean, you might doubt that sometimes when you talk to other people. But we have our own interpretation of it, and that's our mental model.

Our mental model lets us make decisions based on the perception of reality. It's a really abstract thing. And what I'm arguing is that management still has this kind of manufacturing mindset, but really, we are living in the world of creativity and creative IT.

So let's use an analogy or an example. What you see on this slide is a vase, and this vase has an image on it. And your mental model decides what you can see on this vase. Now, I'm not going to ask anyone here because some people have weird mental models.

But what you see is hopefully nine dolphins. Everyone here seen nine dolphins? Right. If you show this to an elementary school child, they will see nine dolphins. Now, you can imagine, if you've seen anything else, what your mental mindset is, what your experience in life is.

But you can see here how reality is exactly the same, right? The picture is a picture. But based on your experiences, you have an interpretation of it, and now you make decisions based on that. Hopefully not on the basis of the vase, but...

Here's a great quote that I like from Gary Hamel. It says, "Right now your company has 21st century internet-enabled business processes, mid-20th century management processes, all built on top of 19th century management principles." And that is really the challenge that we are struggling with.

And that's why your DevOps transformation, no matter what tools you've installed, what latest fancy methodology you've adopted, you're still struggling with it because the things in between are not working out.

Five years ago, I would have gone to organizations and would say, "Hey, you really need a continuous delivery pipe." Everyone said, "Yes, that sounds cool. Let's buy one of those. Can you give me one?" And then we said, "Of course," and we built it. And then we're still not getting the business results.

And to me, this is really the reality behind that: it's all the small decisions that we are making that are holding us back. So let's have a bit of a look into this.

If we use the engineering manufacturing analogy, it used to be appropriate, but it's not appropriate anymore. Let's check whether I'm right, and my blog post is called Not a Factory Anymore for exactly that reason.

So predictable production process allowing you to measure productivity and define output. Anyone here in IT has ever been asked to measure productivity? Yeah, a few of us. Have any of you succeeded? Thank you. You can't.

It's easy to do when you're in manufacturing. You build a car, and then you build the same car again and again and again and again. And it's easy to measure how much material went into it, how many man-hours went into it.

But in IT, you never do the same project twice, or you shouldn't. A couple of times I have, but you can ask me over beers. But we have this belief that we can measure productivity in IT: function points and story points and, I don't know, whatever, lines of code if you're really bad.

But we can't do that. We also can't just create a new process, and the process will solve the problem, because there's so much interpretation in it. Otherwise, we would have all picked up Jez Humble's Continuous Delivery book, and we would all live in continuous delivery world. We don't.

And that's really because we can't just make the process so predictable that the humans don't play a role anymore. So really, this one doesn't work.

Let's go to the next one. It's based on functional specialization of labor. Yeah. This is very much that Taylor trough, right, where we believe that we can have FTEs. Has anyone here heard about a 1.5 FTE that you're kind of moving around? I am not an FTE, and I'm certainly not a 0.5 FTE, no matter what my boss says. Right?

And there's a really good podcast that I listened to a few years ago from, I can't remember his name, but the guy who was running estimation for Infosys. And he got asked, "What are the main things that you need to know to estimate your project?" And he said, "There's really only two things I need to know. I need to know the scope, and I need to know the team that's going to deliver it."

Right? And we tend to forget that second part, because depending on who your team is, what experience you have, will make a huge difference for your estimation. And that means you can't just replace someone. You just can't place a resource where it's just an eight-resource project. No, it depends on who you have.

So really that functional specialization of labor is not really appropriate.

Let's go to the next one, importance of upfront planning. 1990s, so the first couple of projects that I did were very much like manufacturing. You had to order a server, they come on a truck, they drive them into your data center, you connect it, you cable it, you have CDs that you install. Right?

That's all upfront planning, because if you have to do this again and again and again, that's kind of painful. Well, nowadays, you put your credit card down, you get an environment in AWS, and off you go. So the level of upfront planning that is required is not the same anymore.

There's still some level, so I'm not fully subscribing to emerging architecture, but there is certainly significantly less than it used to be.

Automation is improving productivity. Well, that is actually true. So the biggest criticism that I get when I say it's not a factory anymore is that, "But Toyota." I'm like, "Yes, Toyota." But most of the other factories don't look like that. They look significantly different.

But automation is definitely a good thing, and what we're trying to do is we're trying to get developers and engineers to really do what they can do best: creatively solving business problems. They're not code cutters. They're not translating technical designs into code. Our testers shouldn't have a test script where they're just manually executing an Excel sheet from step one to 100.

Now that's pretty... I was a manual tester when I started in my career, and I found this pretty boring and dehumanizing. I was like, "Press this button, enter 6RC." I was doing some pretty crazy logistics stuff. I had no idea what I was doing, but I was filling in scripts, and it's terrible.

We really want to help them doing the creative stuff, the things that only humans can do, by removing everything else. So that one ticks the box.

And then the economies of scale and effort of scaling. If you have a good running factory and you take the blueprint and the processes and build another factory next door, you're pretty sure that you will do roughly double of what you do the first time around.

Anyone here ever scaled from one agile team to two agile teams? Yeah. Does it immediately give you double? No. The people who believe that are the kind of people who believe that nine women get a child in a month. And I have a 16-month-old at home, and it was a significantly harder process than that. No, my wife can tell you I was the observer.

But yeah, so that doesn't work either.

So as you can see then, I did an MBA a couple of years ago, and what you learn about management is manufacturing management. You don't learn product management that kind of works in different principles. And that really hurts us as an industry, because all these decisions, you can see what decisions you make when you believe in these things, when you believe in productivity as something measurable, when you believe that you need to plan everything up front, when people are replaceable. And that makes the wrong decisions.

All right, so hopefully you agree with me that we can burn this factory down now, and we need to come up with something different.

There's a company in Australia called Atlassian, many of you might be familiar with. They did a talk at Agile Australia, and they did a really cool thing. They basically went through a similar exercise. And they said what IT is really a lot more like is like a laboratory.

Because no matter what people tell you about business cases, they are experiments. There are no guarantees. There are justifications for an experiment, and what we really need to do is we need to make that experiment and then measure whether it's successful or not. And too many people forget that about it.

So if you take the lab analogy, we're in a better place. So this was all pretty depressing so far. Right? Great. Mirco's done a great job of depressing, but you're in Great Britain, so that's kind of par for the course.

So I want to give you a little bit of also what you can do differently. So let's have a look into this.

Not surprisingly, I use a framework that I use in my book. But there's really three dimensions of what you need to do. There's technology architectures, and this is where the stuff that all we techies want to talk about, the tools, the practices, continuous delivery, microservices, liquid architectures, you name it. I think that's a pretty obvious one.

The next one is in organizing and managing knowledge workers in IT. And so that's about providing the right context to allow people to make the right decisions. We'll talk about that in a second.

And then the third one, and I think this is a little bit unique for what I say in my book, is the ecosystem. I had a big frustration when I went to conferences like this. I'm a vendor, by the way. I'm an SI, I'm a consultant, whatever you want to call it.

And you go to these conferences, and people are standing on stage, and they talk about culture as a really important thing. And then they talk about what they've done in-house and, in the East, some are in a digital space. And I'm like, "I don't know that many organizations that are all in-house." They usually have some product vendors, they usually have some vendors like an SI, they have a test vendor, whatever.

We need to talk about how can we create an ecosystem where we can work together as partners. And no one had really done that.

I had this really embarrassing moment when I started doing these kind of talks in front of clients. Afterwards they'd come to me and pat me on the shoulder and said, "Mirco, that was a fantastic talk. Thank you very much. Let me introduce you to someone that you should talk to."

I'm like, "I'm always happy to chat."

They're like, "You should really talk to this Accenture person over there. They're not doing anything of what you've described."

And I was like, "Jeez."

And so I had to go through this exercise of understanding that the ecosystem that we've created incentivizes certain behaviors. And if you don't set this up right, you don't necessarily get the right outcome. You get exactly what you ask for.

And so I spent the next few years really helping organizations reshape the ask that they are asking us, to help us being the best provider for them. And I will give you a couple of examples a little bit later on that.

But this is really my kind of three dimensions, and so I'm going to go through all three in a little bit.

Now, here some of you might have heard about Maslow's pyramid of needs. This is Mirco's pyramid of DevOps. As I said, I'm a very simple man, so I have very simple diagrams, ideally.

And really what this is trying to say is we are getting so focused sometimes on the shiny bit on the hill that we are forgetting about what is most important.

I've been to organizations where when you look at their defects in integration testing, 60%, 70% of the defects have nothing to do with functionality. They're deployment issues, environment configuration, data issues, all that stuff. And that's done in a pretty expensive process.

So if you ask me where to get started, get the hygiene right. And if you have an assembly line, we all use the assembly line as a metaphor. If you have an assembly line that once in every 10 times hits the package and damages it, and all you're doing at the end is figuring out if the package is broken or not, well, you will never, ever get to understanding where the problems are coming from because you don't understand that the assembly line is broken.

So really focus on the SCM, build, and deployment process. Then you can start talking about the QA stuff. And it's really QA. I really hate when we talk about testing because testing is such a small aspect of quality.

And one of the worst things that we've ever done is called it test automation, because what we're doing with test automation is not automating testing. We are automating quality assurance, which is very different.

Anyway, and then you can start talking about throughput and actually talking about productivity. And all we can do in IT to measure productivity is really measure the opposite: measure toil, measure the waste that we produce.

So this is kind of the way that I see the priorities in many, many organizations that I go into. We kind of do a little bit of everything, and that means we're not achieving anything because we have such a huge work in progress.

We heard this morning a couple of people, and I'm really happy to see that everyone is talking about how we actually measure these things. This is one of the things that we do. This is based on Splunk, but it doesn't really matter.

At the end of the day, we have so much data in all our tools, and for such a long time, we ignored that. We have the individual dashboards, but we couldn't really correlate the information from our defect measurement tool with our release tool, with our monitoring. And what we've tried to do with this dashboard is pull these things together.

At the bottom, you can see we have a release readiness score. And what it allows you to do is correlate the information in here, which might be things like late changes or known defects, and relate this to the availability in production.

I know of many organizations where the CAB process is really looking the project manager in the eye and saying, "Are we good?" And they present a status that is green, whatever that means. But it really comes down to looking them in the eyes and saying, "Are we good to go? Can we go live?" And then, "Yes, we go," and then off we go.

There's not more rigor to it than that because everything else is just PowerPoints and Excel sheets and all that kind of stuff, but not real information from the systems. So this is trying to help that.

And then there's a little tidbit in there about all the Agile projects. Agile, by definition, allows people to be flexible. But at the end of the day, you still need to be able to govern something.

So what we do there is we basically use all this relative to 100%: how much is the amount of scope that we are trying to deliver, how far are we into the release, and then you can plot your teams on this and actually identify who needs help. Who needs "help." We all know the kind of help that you don't want.

But that kind of helps us really correlate all the different data points from a delivery perspective and the engineering perspective to drive something through. I just wanted to give that as an example.

But technology is really not what is holding you back. People are.

I found this quite neat expression from a different website. As we are all standing on the shoulders of giants, I can't really draw well, so I use other people's drawings. But we had these pyramid-driven organizations, and they were organizational hierarchies. Everyone has to go through their managers to get somewhere, and that takes a long time.

We need to move into a new model where we are much more network-organized.

To make this really concrete, and this is again from the website, the BetaCodex, we were in the world where we had this thing on the left, where products were driven from the center. And some product manager thinks about what product should we do, and then we kind of get a business case on that, and it takes us nine months to create something. And then the rest of the organization needs to push it out.

Where we want to be is in an organization where the people who are closest to the market are self-organizing and figuring out what is required, and hence create the products around them. And in the center are common services like HR, governance, management. You might have your DevOps service in there. You might have your environment services in there. And they provide services to the next layer.

And it's really this end-to-end service mindset that is important.

I'm experimenting with this at the moment in my own team, where we have obviously traditional hierarchies in many senses, but we have other areas where we allow these people to organize like that. And you might have more senior people taking a back role and supporting someone more junior driving something like our training strategy, our tooling experimentations, our HR process internally.

And that really allows people to move away from, "I'm doing as I'm told," into, "I'm doing what is required and what is necessary and how I can help them." And I think this is probably the biggest challenge that we will face organizationally as an industry. How do we get closer to that? Because we are so married to the pyramidal structure.

And as I said earlier, it's actually always the context that we're trying to drive. No people make mistakes because they want to. There's very few bad people in your organization, I assume. But people make mistakes, and the idea here is that we want to start looking into how can we create them an environment where the context lets them make the right decisions.

And this is my latest pet peeve. Management still matters. We are so technology-centric sometimes that we believe if you install a new tool, everything is going hunky-dory.

There's a client of mine that I worked with. They had fantastic engineers, and they had done everything that's in the book. They had decentralized teams. Everyone had their own Jenkins setup. Everyone could do whatever they want. Brilliant.

And then they had the developer that created a new Jenkins job, and they had this kind of path variable that was straight from root. Unfortunately, for whatever reason, that didn't get filled in, and they deleted the whole Jenkins server on the cloud.

Now, if you're a very traditional organization, "Oh, it's just a tool. It's a tool that's gone down." Well, for that organization, that means they couldn't deploy into production, right? Because no one knew how to manually deploy into production. It was all codified in Jenkins.

And it was not as though the Jenkins job that someone had configured, it was many people had put Band-Aids on it and embedded one script and another script. And so it took three weeks to recover from that.

And that's the extreme that we sometimes get into, where we believe, oh, as long as we have Jenkins, everything is okay. Well, but how do you manage this? This is now as much a production system as your production system is. So we've created a whole IT infrastructure that we also need to manage.

And another client of mine works with a relatively complicated architecture. Their DevOps toolset, so just the tools to build, deploy, test, is 180 tools. All right. And all of these 180 need to work to deploy into production. That's a complexity that you normally see in business applications, where people have hundreds and hundreds of applications.

So we need to start thinking about it because automation by itself will not necessarily manage that for us. So how can we create managers that can manage automation and can herd the cats of all these engineers who, "Oh, let's just do another microservice over there," or all these shiny objects that we all want to deal with?

There's another organization that I work with. I'm significantly better in telling you about failures than about successes, I notice. But they're, again, really good techies, but it's very optimistic, positive. They are always focusing on the happy path. And so what that means is, if we automate it, it will work.

Now, I don't know what your experience with automation is, but automation works 99% of the time. That means there's 1% of the time something goes wrong. And that was okay when you had SAP, right? One application we deployed into production.

But now if you deploy hundreds and hundreds of microservices or different ecosystems of applications, 1% is a lot. That means you basically can guarantee that something is going wrong. And if you haven't managed for that, if you haven't got process for that in place, you will not be able to be successful.

And as engineers, we really don't like that, right? We don't like, "Oh, I've deployed this, so it's in the environment." Well, what scripts have you written that validate that it's the actual right version of the code, that we haven't picked up by mistake or random different versions? What have we done to make sure that the data configuration, that no one has gone in and fixed it and changed it manually in the environment? All these kind of things need to be managed.

All right. So this is the last dimension, which is the ecosystem. So that's obviously something I'm very passionate about, and we're going to do a little bit of a mental exercise here.

So we have this world where we have vendor A and vendor B. Vendor A charges you $100 per day, and vendor B charges you $80 a day for their engineers. I know that's cheap, but it's an example. Don't quote me on that. Don't ask me to provide the service.

Who do you think has more automation and is more productive? Well, in general, people think the cheaper one should be the right one. Well, let's have a look at that.

Here's your pyramid of work. We have simple work at the bottom that is relatively cheap, and then as it gets more and more complex, we get to the top of the pyramid. Now, when we start doing automation, what do we automate? The bottom one, right?

Now, what does that do to the average day rate of an engineer in your organization? It goes up, right? It has to. The overall cost goes down, but the average day rate goes up.

So when a vendor comes to you and says, "Hey, I'm doing a lot of this DevOps stuff that you told me about, and I can take 30% of the average day rate," I can tell you the one thing they're not doing: it's automation. They're finding more junior people doing more work. That's the only way that you can achieve that price change.

And that's kind of very counterintuitive to a lot of procurement systems that have been set up. So that was one of the things that I ran into when I was running a DevOps team, that even if I wanted to do automation, contractually, I would start getting penalized for it. Go figure.

Here's another one, SLAs. So I spend a lot of time in conversations around contracts and SLAs at the moment. SLAs is basically a good way for you to get what you want. You get a guarantee for the service level. What could be wrong with that?

Let's look just at a simple example. We have a password reset. Let's say it's two hours for that as an SLA, and we have a Sev 2 in production. It's a bit more complex, so we give a day for that.

Now, I have two of these tickets coming in, one each, and it's lunchtime, so I'm going to a pub in Australia. It's World Cup, so I'm going to watch a match, have a pint, and come back to work an hour and a half later. Which ticket do you think I pick up?

Well, I'm going to pick up a password reset, right? The clock is ticking. What do you think as an organization I should pick up because it's more important? The Sev 2 in production.

That is two SLAs. I don't know many organizations that have two SLAs. Most contracts have like 20, 30, 50 SLAs, and you can imagine what kind of unintended consequences you've built into that structure.

Another one is, let's do a bit of an on the opposite. Operations. Tickets. What is a good measurement for how well you're resolving tickets?

Mean time to close. Mean time to close. Yeah. Mean time to close. First time getting it right.

Now, when you automate and you think back into the pyramid, what are we automating? All the simple requests, right? Your password resets. What does it do to the average time to close a ticket? What does it do to how often I get it right? It goes exactly counter to what you want.

And so you can look at this for your own organization, you can look at it for when you work with a vendor like us. But that creates the wrong incentive, and that is really, really dangerous for your organization. So you really have to think about these things and create this new mindset of figuring out how things are different now.

So I think that's one of the things that is really holding us back, that we haven't created or we haven't opened up those conversations.

Now, I haven't been able to provide you the silver bullet that DevOps is sometimes purported to be. If you want snake oil, I can sell you that in any flavor you like. But the reality is, to come back to the kind of diet thing, it looks a little bit like this.

And Damon Edwards had this on a slide a couple of years ago. You're going into this automation journey. The initial bit is really easy, right? You shed the first few kilos really easily, and then you kind of bounce back. You know, that one muffin, that one extra croissant. And then actually sticking with it at that point is where it gets hard.

And I have many stories to tell on where these things start to fail, and then you really have to stick through it. And as if this would be hard enough, it actually looks like this, right? It's many of these back to back to back to back to back.

And that's the mental mindset, the rigor that we now need to get people to believe in the progress, to believe in this kind of ongoing improvement rather than the jumping ship and just another tool will solve it, or if we can just all do microservices or whatever. That's not the answer, right? The answer is this incremental improvement that we need to keep going.

So with that, what are the problems that still remain? How do we actually work together? How to create this anti-transformation transformation that I was talking about? And how do we make sure that the good discipline and end-to-end thinking is easier in organizations, rather than just jumping to the next bit of easy solution?

Thank you very much for staying with me, and hope to see you guys around. And say hi when you see me at the book signing. Thanks.