Sooner Safer Happier: Antipatterns and Patterns for Business Agility

The Journey to "Better Value, Sooner, Safer, Happier"

Eduardo da Silva: Hey everyone, welcome to the GOTO Book Club. In today's session, I'm going to be talking about... I'm going to restart. Hi everyone, welcome to the GOTO Book Club. In today's session, we are going to be talking about the book, "Better Value, Sooner, Safer, Happier." This is one of those books I keep on getting back into as I try to help organizations improve and achieve a more sustainable fast flow of change and value. To make the most of this session, I have with me one of the co-authors, Simon Rohrer. Simon, welcome.

Simon Rohrer: Thank you.

Eduardo da Silva: Simon, before we get into the depths of the details of the book, could you briefly introduce yourself?

Simon Rohrer: For sure. So, as Eduardo said, I'm a co-author of the IT Revolution Press Book, "Sooner, Safer, Happier." My day job is right now as head of enterprise technology architecture and ways of working at Saxo Bank here in Copenhagen and Denmark. I've been doing this role for six years. I love it. It's awesome. Before that, before I did my Brexit escape, I lived in London and I worked for ARCLE, a large multinational financial services organization for 15 years. I had a number of roles there in software development, in software architecture. I was chief architect for the wealth management division. Then my final role before I moved here to Denmark was working with John Smart, the lead author of "Sooner, Safer, Happier" in a job that started off as an agile transformation team. And then we learned some lessons. We didn't end up with the team called that. I guess we can go into that in a bit more detail.

Eduardo da Silva: Maybe we can actually start there, Simon, sort of the why of this book, right? So, maybe you can give us just a bit of context because I think that journey per se was very revealing. I think we already had some conversations ourselves. But that's probably something that many organizations can also see themselves into. Yeah, so the why of the book.

Simon Rohrer: For sure. The reason the book is sort of the kernel of it is the story of our journey as a team that started off effectively imposing agile transformation, turning up to sort of senior managers' desks and saying, "Hey, we're here to transform you. We're here to make you agile." And some of them said, "That's very nice. Go away. I have more important things to worry about." Some of them said, "Great, we've been looking for this opportunity for a while." But what we ended up after, probably a year of doing this was a sort of stark realization that doing a transformation, imposing a transformation on people was not a great idea, not awesome at all. And agile, just seeing sort of agile practices as something that everybody needed to adopt, regardless of context, was also not a great idea either. And our realization was, "Well, it's not about agile practices. It's about outcomes. What are those outcomes?" And I guess the story of "Better Value, Sooner, Safer, Happier," is a neat little story.

So, there was a part of the organization whose, I guess, acronym was BPF. That was the name of their division or the acronym for their division. And what they had in their presentation of their sort of ways of working adoption was BPF, better product, faster. We initially thought, "Great, that's awesome. Why can't we take that sort of more broadly to the entire group and the sort of federated set of that point, ways of working adoption rather than agile transformation?" Great ways of working adoption, better products, faster. And then we thought, "Great, better is good. Products are not really what we're trying to improve here, it's value, not just products, you know, value-tivity, not productivity." And then we thought, "Well, faster is not necessarily the best way of articulating this." Sooner, we think, is a better way of talking about improving, continuous improvements of time to value and time to learning. So, cool. That's a value sooner.

Then we said, "Well, there's some missing stuff here because if you just concentrate on those three, you're maybe not looking at what are the people who you're delivering to or the people who are actually doing the delivering or other key stakeholders are really, well, happy with how you're doing this and what you're doing." So, cool. Not better products, faster, but "Better Values, Sooner, Happier." Happier customers, colleagues, citizens, and climate. And then the final piece of the jigsaw was some work we were doing around what we ended up calling safety teams. It was risk control governance and how to do that in a continuous way rather than the sort of upfront way. And one of the things that myself and Miles, the co-author, focused very heavily on in those few years, was transforming the sort of entire risk and control from something that was about reviewing documents upfront at the beginning of a Waterfall project, to this very continuous collaborative attitude. So, that ended up being the last part of the jigsaw puzzle of "Better Value, Sooner, Safer, Happier."

Recommended talk: Tap into Fast Flow w/ Team Topologies & Platform Engineering • Manuel Pais & Julian Wood • GOTO 2025

Antipatterns & Patterns for Business Agility

Eduardo da Silva: That's why I'm really interested in that journey, because I think most organizations often try to accelerate the transformation, right? That initial, big grandiose goal. But most of the time, it means looking at many of these perspectives and also meeting where the organization is, right? So, this is, I think it comes really strong on the book, but also on as you were just sharing some behind-the-scenes. And Simon, I think you already went into that, but could you just share very briefly what's in the book? So, I think you shared those keywords, but maybe just give us a bit of an insight on what all of these dimensions are, right?

Simon Rohrer: For sure. I mean, I'll delve a bit more into the outcomes and I'll also talk a little bit about the structure of the book. And rereading it as prep for the book club, just made me smile. That was the structure. So, absolutely, it starts with focus on outcomes. You can see some of John's talks online on YouTube as he was starting to write the book, as we were starting to collaborate on it. It's like, what are you optimizing for? So, it very much starts with that. You're not optimizing for outputs. You're not optimizing for the process. You're optimizing for those outcomes. Value at the center. So, value is what makes you, you. We can't define what value is for you, only you can. If you're Burberry, then value is delivering awesome raincoats or fashion. If you're an investment bank, then value is delivering, you know, everything from advice around measures and acquisitions to the ability to trade, buy, sell various equities and do that in the most efficient and most, you know, sort of customer friendly manner.

But the value is what makes you a special snip-effect. That's awesome. But then there's balancing factors around the outside. Better is quality. How well are you doing this? Quality again. There are some decent definitions of that. So, typically, again, for sort of modern ways of working, it's defects in life. Are you delivering value? But actually, you're getting, you know, the severity of one incident once a week because you've not focused on quality. And sooner is everybody's favorite flow. It's time to value, time to learn. And the book talks very much about the sort of practices that are not necessarily best, but good practices around that, which are around, you know, thinking small or working in the smallest batches that you possibly can. And that's an easy concept, but it's potentially hard to do based on where you're at, your history. And so moving towards sort of small batch delivery in order to be able to get faster, time to sooner to learning. Safety is agile, not fragile.

It is doing things in such a way that is compliant. It's secure. It's private. It's a lot of these things that, well, you honestly want to do anyway, but it's things that the regulators are enforcing on you more and more. Today, the Digital Operational Resilience Act in the EU goes live, which mandates a lot of these things. A lot of these things are just, again, good practice that you should be doing anyway. As we said, happier covers a number of stakeholders, a really broad set of stakeholders. And a lot of firms measure things like MPS. We'll delve into whether MPS is a good or bad measure, but it is at least a measure of customer happiness. But colleague happiness is key as well to this. The people who are sort of going on this, whether it's transformation or adoption or changes in their ways of working, I think, are they good with it? And again, citizens and climate are yet another balancing factor in what you're doing and how you deliver it.

Eduardo da Silva: There you cover those. But also the way I find the book very interesting and sort of I often find myself just going into certain parts of the book because you had this interesting format of making it a sort of a pattern and anti-patterns book, which I'm pretty sure I read it slightly different and I'm going to be applying it differently than what you had. But the interesting thing is that it gives us these ideas or starting points to accelerate a bit, to navigate certain situations, right? As patterns tend to give us, which I think, and I want to zoom into one of the chapters that actually were the main author, Simon. But this idea of patterns and anti-patterns are very interesting, I think, where we are living today, right? So, where this is not anymore that factory, very clear processes and we can plan and it's predictable. So, just sort of a thumbs up on the format that it's sort of you... I think the experiences you had at Barclays highly inspired this, probably, many other experiences you had before, but sort of coming to this number of patterns and anti-patterns.

Simon Rohrer: Thanks so much. And just to pick up on that, it's a crucial way and it's there in the sub-head of the book itself. It really is that sort of humility that says, "This is not a playbook." John Cutler calls it sort of in the blurb in the front, like a meta playbook.

Eduardo da Silva: Exactly.

Simon Rohrer: Because we are really clear that there are no best practices. And even in sort of Chapter 0, we talk about the Cynefin framework and how so much work in the digital age is in the complex space. So, there are no best practices. There are some potentially good practices that we have observed in our many decades, careers. But ultimately, the book focuses more on principles and it says sort of context plus principles give you practices. Here are some practices that we have seen in some contexts, may give you a headwind. These are the anti-patterns that we have observed might slow you down in some situations that we've seen. And then the converse is the patterns are, "Here are some practices that we've seen might help you." And again, it's back to that small batch work, even on the small batch in two ways. Small batch in terms of the value you deliver, but also small batch in the changes you make to your ways of working and experiment and sense and respond.

Recommended talk: How To Lead Through Transformation in Tech • Hannah Foxwell & Charles Humble • GOTO 2025

Embracing Continuous Attention to Technical Excellence

Eduardo da Silva: Yes. I think this is a great segue to... I had some sort of deeper dive into Chapter 7, which was where you were the main co-author, which has this brilliant title, Continuous Attention to Technical Excellence, right? So, obviously, as you already said, this is not just about technical aspects or just one of the perspectives that you have within a big organization. But this title has a very interesting continuous attention, right? So, already building up on what we were just talking about. And so, Simon, why do you think modern organizations should really embrace this idea of continuous attention to technical excellence? And maybe you can also just share a bit more of what we mean by technical excellence. Because as I was already trying to bring in, it's not just about being great technically, but it's a bit more than that.

Simon Rohrer: The chapter title still is a really interesting one. It was inspired by the fact that sort of just the practice of continuous delivery is taken from a quote from the practices, from the Agile Manifesto. The chapter title of Chapter 7 is the same, Continuous Attention to Technical Excellence and Good Design is one of the practices from the Agile Manifesto. So, excuse me, that's where that comes from. Absolutely, it's contrasting with occasional attention to technical excellence. It's the sort of feature factory approach that says, "You know, we'll just do the code and infrastructure and testing that is necessary to build the next set of features that were our backlog." Occasionally, something's going to break or occasionally a sort of security vulnerability will come up. But until that happens, just we'll ignore that.

The only code we will write and the only sort of activities we will do in the technical sphere are ones to deliver those features. And Chapter 7 tries to say, "Well, look, that's not a sensible attitude." And the very first anti-pattern is going faster leads to going slower. Because as it says, "You know, you just keep trying to deliver feature, feature, feature, feature. You are going to build up entropy. You're going to build up technical debt. You're going to build up quality debt. Your software is going to become less and less maintainable. And your attempt to deliver more features is just going to slow you down." And the ability to deliver continuously sooner depends on you paying dual attention to delivering value and delivering technical excellence. That's the crux of that.

Eduardo da Silva: I think this is, I think you wrote it somewhere in the chapter. Also, the realization that we are not anymore working on just this little project delivery and then this is done. Work is done. We are living more and more on building something that lives in an environment that's changing and technology changes. As you said earlier, maybe the law is changing, right? As, for example, you work at a bank, you get a lot of legislation on your way and you need to act on that. So, I think that's a key thing, a key realization of this chapter that you write on, acknowledging that we have different types of work, right? You also, I think, touch on that at a given point. It's not just features. It's also improvements. It's handling defects. I forgot the fourth one, but there is, I remember there are four.

Simon Rohrer: It depends who's slice you take...

Eduardo da Silva: Exactly.

Simon Rohrer: ...so there's Mik Kersten's view on it. There is the making work visible too on it. There's Dan North's take on it. There's roughly four or five slices put on his perspective. But yes, always, like you say, there is some kind of improvement work. There is safety work, which actually Mick was inspired by the work we were doing. There is feature work and there is some kind of sort of unplanned or defect work. And you have to balance them on a continuous basis.

Eduardo da Silva: Exactly. You also get into this other part, which is in the end for us to do that work effectively, we also need to break out the idea that we are just the technical people and we are doing the technical work. And you need to actually embrace this idea of partnership, right, Simon? And you go into, say, the value outcome lead, the team outcome leads, and the architecture leads. Can you maybe tell us a bit about that? Like, the importance actually? In order for us to get into this path of continuous attention to technical excellence, actually, we can't just be really good at doing some of the technical work, but it's positioning this in a broader scope of work and a broader scope of interactions if you will.

Simon Rohrer: Absolutely. So, throughout the book, we talk about this triplet of the sort of leadership or coaching triplet of our role, focusing on value that might in some cases or in some methodologies be known as a sort of product owner or product manager, a role focusing on sort of team effectiveness, which might be an XP coach if you're an extreme programmer or it might be a scrum master or...

Eduardo da Silva: Engineering manager.

Simon Rohrer: ...an Agile thing. From discipline agile, you know, the various names, that somebody who is there sort of coaching the team, potentially, if you still like certain leaderships, and people don't anymore about that sort of servant leader role, helping to move impediments or escalate impediment. And finally, again, sort of inspired by some of the stuff Martin Fowler writes as somebody who is a peer of those, who is not necessarily the architect, but the person who is able to advocate for those technical outcomes and that sort of continuous attention to technical excellence that we talked about. Somebody who is a peer of the person who is just driving the value.

Eduardo da Silva: At the end, so it's very interesting. It seems like a lot of what you write on that chapter is actually to sort of, in order to achieve technical excellence, we actually need to think a lot about the people, right? The interactions, at the given moment, you also talk about Conway's Law and all of that. So, this is a realization that I think many organizations really need to embrace, because otherwise it becomes very difficult to achieve a more sustainable, say, flow of doing this work, right? Or do you agree with this claim, Simon Rohrer, or is it...

Simon Rohrer: Absolutely, Eduardo. And I think, yes, you're right. It's a really interesting sort of flip here. "Sooner, Safer, Happier" is not a book about software. It's a book about organizational, efficiency, and business agility. Chapter 7 is a book about software, but Chapter 7 is not a book about technology. It's a book largely about people. Or it's a chapter largely about people. One of the anti-patterns we had observed was people saying, "Right. We're doing a DevOps transformation now. We've rolled out Git. We've rolled out some kind of build automation software. And we've rolled out some of those, you know, two of SonarCube and some security tooling, and we're done. That's our DevOps transformation. We've rolled out some tools." And there's a sort of really clear thing in the book that says, "No, none of these things, none of these, perhaps DevOps, it's not about tools. It's about people."

Sort of extreme programming. It's not about tools. It's about people. Test-driven development. It's not about tooling. It's not about, "Great, I use X unit now or J unit and now I'm done." It's a hugely sort of cultural practice about how you work. And like you said, architecting, and as you know, I've talked a lot about this in some conference presentations over the last year. Deciding what new components you're going to build or how you're going to refactor or rewrite or restructure existing components has a huge impact on team structure. And who does what, where, when? And so that is as much about people as it is about software. So, yeah, Chapter 7 is hugely influenced by the impact of software on people and people on software.

Recommended talk: From XP to TCR & Limbo • Kent Beck & Daniel Terhorst-North • GOTO 2025

Embedding Safety in Continuous Delivery

Eduardo da Silva: Simon, I know I have two things that I want to still go a bit deeper. One, maybe just touching a bit on Chapter 6 because I think I know you also worked quite a lot on that chapter, but there are some interesting things there, which is this idea of the safety aspect, right? I find it fascinating, to be honest, because often when I get into some organizations, the safety aspects are kept a bit outside of the normal work, because we want to separate the concerns and we want to do this and that. But if you wouldn't include it in this approach or these considerations, let's say, you often get blocked, right? So, you will get blocked and sort of treat it in isolation. Could you just share with us some of the big lessons from that part? And maybe just give us a hint. And I think I highly recommend people to look into this, this idea of moving towards the idea of safety teams, and yeah.

Simon Rohrer: For sure. As I said, this was very much from our experience of solving problems, solving flow, solving sort of blockages in the value stream. That various of our sort of risk and control and safety colleagues wanted to understand up front and be presented with a form. You know, we need to do a privacy assessment or we need to do a security review of everything you're going to do in this 18-month project. And so we're not doing an 18-month project anymore. We're going to deliver on a regular basis, every two weeks. And that sort of flammocks people a little bit. And then we said, "Well, actually, what we want you to do is collaborate. As our backlog evolves, we'd like you to collaborate." And luckily, we had some extremely forward-thinking senior people within security, within privacy who sort of it clicked.

Eduardo da Silva: Clicked. 

Simon Rohrer: And sort of the ideal, the absolute ideal is you have experts in your team continuously. So, you have a security expert from the team. That willeconomically not going to work. So, what we said was, "Well, no, you lift this one level up. We'll cluster our teams into domains." And Miles has drawn some awesome pictures in Chapter 6 around this. But we'll cluster teams into domains. So, let's say in the payments domain, we've got sort of eight, two pizza teams. We'll then sort of have a long-lived safety team that works with those teams and builds up an understanding of what they're doing, what their context is, what their backlog is, what their challenges are. And we did some super interesting work on sort of expanding what we expected those teams to write in terms of documentation. So, again, the sort of previous process was... And I liken it to those who've seen the movie "Men in Black." At the end of every project, you press the memory erase button and everything goes. So, at the start of the next project, you need to document everything about payments so that people can review it. We said, "No. Look, have some long-lived documentation. What's your thing? What's the thing that you own all about?"

The system or the system of systems so that we don't go from a standing start. Every time you need to talk to some people about a thing, there's a nice sort of confluence, a Wiki page about payments or about the sort of regular payment system or the swift gateway or that kind of thing. Great. And then on a regular basis or when you've got a sort of new interesting big rock on your backlog, go have a conversation with your safety team. "Look, over the next three months, we're focusing on this thing. We think it's got these security aspects and these privacy aspects. Can you advise us on these? And what sort of risks do we need to place on our backlog alongside the features?" And we sort of even in our heads, we're not able to do this in the tools we had, but sort of in the old school card wall when you had a physical card wall bigger than that. These would have been sort of red cards that were clearly sort of different things really.

Eduardo da Silva: Different type of work.

Simon Rohrer: Again, this real sort of ongoing continuous collaboration. You're not in the team permanently, but depending on the work that's, again, let's say the swift gateway team is doing something that's really interesting and has some security aspects. Cool. At that point, the security member of the safety team is on a sort of high level of engagement with that team. The privacy person might be on a lower one. And again, the chapter goes into it in much more detail, but it is ultimately down to that sort of continuous engagement of people who know the safety domains with people actually delivering on the business domains and a way of orchestrating collaboration between them.

Eduardo da Silva: Yes. I think this is really, yeah, as I was saying earlier, and this also reminds me a lot of what you can also find in a lot. I'm starting to see this more and more, the ideas of security compliance, leveraging say the Team Topologies lingo, right? So, as an enabling team, but also as a platform, which is this idea, how could you, because you need to interact and understand what's going on? And I think in a nutshell, this really boils down into that continuity of learning, right? So, now we look at this project and then good luck, but more of this involvement and building. It's not just sort of helping the team, but also learning with the team, what actually we, as a safety team or platform or enabling team or whatever, what are we actually learning and improving in time, right? So, it's a two-way street.

Simon Rohrer: Exactly that, Eduardo. And I think this is right. I think from the team topologies perspective, the safety team constructed in Chapter 6 probably is an enabling team. And I think there's this really interesting thing that, again, Marz and I and the four of us have discussed. There is a perception that everything in safety can just get automated. It just all goes in the pipeline. That is not the case. It's the same sort of people versus tools conflict that we spoke about in Chapter 7. You can automate an awful lot of security. You can push a lot of it down in the pipeline. And then you're right. That goes into a sort of platform team approach. And there are still a lot of human elements of, "This regulation is new. How am I going to interpret this? What do I need to do to meet this? How do I do that?" And that it requires people not...

Eduardo da Silva: It requires it, exactly. And I think this is where those experts shine, right? So, you come with this deep understanding of that regulation, but you work with your teams which are building your products and are affected by that. So, yeah, I find it a very inspiring chapter. And obviously, this is about safety, but I could see that applied into many other sorts of this pattern of involvement could be applied into other domains. I don't know...

Simon Rohrer: That's right.

Eduardo da Silva: ...marketing, whatever, other domains.

Balancing Incremental Change and Big Leaps in Transformation

Eduardo da Silva: Simon, time is going. And I actually have a surprise for you because I got some questions from some enthusiastic readers of the book. So, some people I work with and they actually use this on a day-to-day basis. They use a lot of these patterns and actually often come with, "Okay, in the book I saw this and that." So, I have two questions that I collected. And the first one has to do with sort of how you do... So, what would be some of, say your risks, not your risks, but like recommendations to recommend leaders to evolve their sort of mindset and behaviors when trying to get into this idea of, first of all, continuous improvement, but also this idea of that you actually need to decentralize more the decision-making when you are doing this and you are empowering your teams. While being sort of aligned to the overall more like we as a company, we have a strategy or we have some ambitions. So, what would be some of the top things that come into mind when getting a question such as this?

Simon Rohrer: It's a super interesting question. And one of the presentations I'm working on at the moment talks a lot more about this balance of alignment or coherence from the top with autonomy at the bottom. So, we were very much inspired by David Marquette and the book, "Turn the Ship Around." And David Marquette's sort of intent-based leadership and the leader-leader model that effectively, says sort of push authority to the information or to where the information is. The people who are closest to the work are the ones who are most informed about this. This doesn't mean giving up your authority at all. It means that what you have is the sort of broad view as a senior leader, what people on the ground have is the detailed view and it's about building up that collaboration. And effectively co-leading that leader-leader model, rather than leader-follower. And honestly, there are a bunch of awesome YouTube videos in the intent-based leadership space that really sort of switch people, again, get people to click about, "This makes sense. This genuinely will help me build relationships, get the information, and those sort of decisions without me feeling like I'm giving up my role. It broadens and strengthens my role as a senior leader rather than sort of disempowering."

Eduardo da Silva: Maybe one thing that I keep on coming back to that seems very fundamental to actually allow for that is even Melvin Conway wrote on his popular, which is the idea of incentives, right? So, do we incentivize enough so that we can actually allow for these behaviors, right? And I think John Smart is often talking about incentives, right? The idea that if that's not there.

Simon Rohrer: I think John is in the middle of getting towards the end of writing his next book. I'm contributing another chapter to that. One of the things John is writing about is incentive engineering, the incentives, trumpet everything. You are absolutely caught up in that.

Eduardo da Silva: This one is, I think the second question I had from enthusiastic readers is about the "Sooner, Safer, Happier," the name that nowadays most people are using highlights the importance of an interactive approach to transformation. But we know that sometimes you actually need to do slightly bigger steps. Do you even have some language in the book describing that, right? So, gradual, but then sometimes you have the larger or bigger steps. Do you have any sort of ideas on the balancing act of this? Or is this really, again, a sense and seeing continuously?

Simon Rohrer: I think it is. We talk about evolutionary revolution a lot. I think, again, going back to Kenevan and the sort of complexity approach, there's this concept of the adjacent possible. You have to move on from where you are. There is a huge danger in trying to make massive leaps because you will very probably find unintended consequences of making a big change. So, effectively, what we see is, learn from making changes. So, you will make small changes. They will make sense in your context or they won't. They'll succeed in your context or they won't. You can then look to scale them. Once you say, "Great, this worked." Firstly, you've learned that this works in your context.

And secondly, you've got a proof point. You've got a social proof point for the rest of your organization that this works in context. You've now got a good idea. It's sort of probabilistic rather than causal. You've got a good idea that within similar contexts, within close contexts within your organization, something similar to that will probably work as well. So, great, try and scale it. You've done it once, maybe try and do it three times in something that's close. And scale it that way. Still with the humility that actually there's a chance this might not work or something weird to happen. But it is you've always got to start small but think big. And that's where we try to encourage you to go.

Recommended talk: Architecture Modernization • Nick Tune & Eduardo da Sliva • GOTO 2024

Exploring Organizational Patterns

Eduardo da Silva: We are reaching the end. I think we should touch two last questions just before we close it, Simon. Is there any topic now that you and John sort of wrote the book for a while that you would like, "Okay, you should have also covered this part," or maybe a candidate for version two of the book? Is there anything that you really feel that, "Okay, this, actually, is very interesting to also consider?"

Simon Rohrer: I think where we are going is more sort of organizational patterns. So, we love Team Topologies. Matthew and Manuel and John collaborate a lot. And as soon as I have a talk about the sort of nested value, and what we want to look at are sort of what are the patterns higher up the organization. So, you know, my world of enterprise architecture, where might that sit in an organization? What kind of decision patterns and collaboration patterns might go on there? How does HR policy work? Where does that get set? Some of those sorts of questions around sort of higher-order patterns, I think, are really interesting ones. And again, the talk I'm working on, on lenses on organizations, starts with that.

Eduardo da Silva: Cool. I also feel that in the first person, to be honest. I think we need more of that. And, yeah, because as you... It screams throughout the book, but I think we are doing this more and practicing more on this connecting the whole organization. Because in order to be effective, you need to connect all of these dots, right?

Simon Rohrer: Exactly.

Eduardo da Silva: Simon, just before we leave, for anyone that would say, "Oh, this sounds interesting, but how could I start doing any of this?" So, we already said it very much depends on where you are, but maybe could you share some of what may be some interesting first steps on moving towards this? Yeah.

Simon Rohrer: I'm going to point people to online. There's, again, rereading the book. The hardback version of the book comes with this really interesting map. Fortunately, it's not in the soft-cover, but is available online. But it basically says, "What's your problem?" So, where you start with "Sooner, Safer, Happier," again, it depends on your context. So, we've got nine questions here. So, what do you want? I want more efficient delivery of value. I want to decrease time to value. I want to have speed and control. I want to nurture some cultural change. I want to know how to fund it. And there are different sorts of start points. Depending on, again, we'll go back to the start. What outcomes are you looking to improve? We can help you, the book can help you with a number of those, but, you know, I can definitely point to the map or Google, "Sooner, Safer, Happier" online. It can help you for a whole bunch of different outcomes. And your starting point will be different, depending on what you're trying to optimize.

Eduardo da Silva: Great, Simon. I think this sort of is a great closing to our conversation. It was really nice talking with you. It's always nice talking with you, always learning. Looking forward to seeing you around in the future.

Simon Rohrer: Yes, I will see you in Berlin, if not before. Thank you so much.

Eduardo da Silva: Okay.