Episode 20: Solving Problems with Domain-Driven Design

Hey listeners, welcome to SphereCast, a podcast all about technology, technology advice, technology inspiration, and how real entrepreneurs have used technology to build their businesses from the ground up.

If you're wondering how technology can support your business goals, rest assured, our guests have been there and done that.

Austrian-British philosopher Ludwig Wittgenstein once said, "The limits of my language mean the limits of my world." And nothing could be truer of the technology industry. In a world where a myriad of skills and personalities must come together to develop true innovation, there must be a shared language. The fact is the language of zeros and ones may not compute to executives, yet all must have a seat around the table to create something truly world-changing.

Hey, it's Luke here with the SphereCast. And this week, Senia and I speak with Scott Millett, IT Director at Iglu.com. Since 1998, Iglu has been disrupting the UK's ski and cruise travel industries. In these niche industries that often lag on technology, Iglu has set up an online portal for ski and cruise trip booking. The innovative and disruptive approach to booking has garnered multiple agency awards and has allowed Iglu to be named as UK's number one specialist travel agency.

As a disruptor himself, Scott has become passionate about domain-driven design, to a point of writing his own book titled Patterns, Principles, and Practices of Domain-Driven Design. At its core, this concept attempts to bridge the gap between the technical and non-technical team members through tools like shared language and vocabulary. On the podcast, Scott deep dives on the domain-driven design and discusses how his work has made Iglu the success that it is today. So without further ado, here's a conversation with Scott Millett.

Hi, Scott. Thanks for joining. How are you today?

Yeah, very good, thank you. Very good. How are you?

I'm doing well. Luke and I are so thrilled to host you on our CTO podcast. I'd like to start with your most recent venture. Can you share with us, what is Iglu and why did you join this company?

Yeah, so Iglu is a online travel agent with a focus in cruise and ski travel. So cruise ships, sailing cruise ships, and ski holidays, basically.

So it's a great question, what attracted me to Iglu? Well, if we think about leisure travel, then there's I think about it in two ways. There's commodity travel and then there's more unique travel. So commodity travel, like if you're booking hotels or flights. So people like Booking.com or Skyscanner have really cracked that market because when you're booking a flight or hotel, if you're booking it for work, you don't really think too far ahead, as long as it's you're staying in a hotel for one night, as long as it's got Wi-Fi, does it include food or coffee, that kind of stuff, and the flight, you're largely looking at the price and the times of the inbound and outbound departures.

Which is unlike cruise, so cruise is far more complex and because it's more unique, people tend to not book it very often. So they typically book it for a family holiday, so they're doing it once a year rather than hotels and flights where they may do many times a year. And price isn't the biggest factor, so it's the uniqueness of the holiday, it's experience, and because it typically have a high price point, they want to make sure that they're not going to make a mistake.

And really for those reasons, through the complexity, nobody's really cracked the online space for booking cruise holidays, which is why we find for travel agents on the high street or contact centers, or even advertising in magazines still very prevalent. So that was, yeah, so really it's the complexity and the fact that nobody's solved this rich, complex problem that kind of attracted me to it.

So we will delve into the match here because I was just thinking when I read about the domain-driven architecture. So I'm fairly familiar with the event-driven architecture, the modern services, so I do give it a good read every now and then. So it basically works with specific, when you're solving specific business challenges, that's when you go towards the domain-driven design. So and that's your specialty. So I guess that is that where we are heading? Like is that one of the reasons why you chose Iglu or why they looked out for you or why they contacted you perhaps when you started off?

Yeah, because it was because they have difficult problems, really. So you've got a company that wishes to move online, and it's a complex product, nobody's done it before. Like I say, in other parts of the travel industry, the more commodity area such as hotel, flight booking, or transfer booking—

Not many variables, yeah.

Yeah, or ancillaries, they've kind of been done. So which is why if you search for a flight in Google, often the Google app will present results before you even get to the Skyscanner website or a hotel result before you get to Booking, but there's because of the uniqueness of different cruise lines and as the industry has got larger, they've kind of segregated, so there's family cruises or there's fine dining cruises, there's cruises specifically for the British market and different kinds of markets around the world. And they don't really align nice and easy to such as the ubiquitousness of booking hotels or flights, really. So that's it's really that complexity.

And how to and how to take a model that is still largely the revenue in leisure travel, family holidays, apart from the bucket-and-spade holidays, which is now increasingly done online, you still see high street travel agents. So people go into them to buy brochures and talk with an agent because typically they want to go somewhere different each year. And if you're going somewhere different each year, obviously by the very nature, you don't know anything about it, so you're looking for more information to make sure if you're spending if you saved up years and years for this big family holiday, you want to make sure you're not doing it incorrectly. So it's how to take that engagement style and that relationship between a customer and a human where a customer wants validation that the choices they're making are correct, then how to transfer that online, really. So that's the that's the difficult bit.

And that's really the difference between a cruise holiday and booking a flight or a hotel where there's where there's kind of little to get wrong, I guess.

I see. I see. I mean, yeah, it is a challenge. So okay, I understand it now better. So thank you for that. Senia, back to you again.

I love that technology challenge. It sounds like, Scott, you are a problem solver. So can we talk about the technology aspect of it? How did you bring that aspect into tying it into the business challenge, and how were you able to maybe solve it or mitigate this?

Yeah, you're right. It's a really good question. And really it's technology is a means to an end; it's not an end in itself. It's a way to help solve problems and bring in automation and opportunities that that may not may not have existed before in different business models.

The probably the biggest challenge is at Iglu, and this is not no this is not specific to Iglu, it's really for the cruise industry as a whole, is that that the industry is still is largely focused on a a contact center model. So or there could be a contact center in a phone contact center or it could be a travel agent on a high street. So it's still very much based on humans interacting to book bespoke packages.

Because of, like I mentioned, it's very different to booking a hotel or a flight. And because of the the high price point and the the infrequency of booking a product, so it could be anything up to three years between between purchases, that customers really need the confidence that they're booking the right thing. Obviously you know, if you've only got if you're looking forward to your two weeks holiday and you've saved up for many years, then you you absolutely want to make sure it's not incorrect. And this is why, for consumer confidence, they want to speak to humans. So the suppliers are kind of set up, so they're not really focused on on digital growth. Obviously slowly they're moving in that direction. So it's so I guess there's three big challenges.

One is, how do we get customers comfortable with buying online? So making sure they've got the right content, the you know, we're asking them the right questions, and we're providing them with the right information. And secondly, how do we get suppliers that don't have great capabilities to improve those capabilities or work with them to provide the information we need in order to support a a more online, e-commerce-led kind of engagement with customers? And thirdly, whilst the demographic, our customer base is moving toward online, it's still relatively speaking is in in its infancy. So how do we how do we still improve the efficiencies of our sales agents because they're they'll still be focused on driving revenue, a large part of revenue for for for some years to come?

So it's it's that balance of of driving kind of innovative and creative ways to improve online transactions with the constraint of working with our suppliers. And some of the suppliers are very big, some are very small, and they don't have huge, even though they're multi-billion-dollar organizations, they tend to have huge IT departments. Whilst so balancing that that need for so if you balancing the need for the digital kind of transformation of the business with the reliable operational efficiencies of of the the contact center, which at the moment is still which still basically drives the the the the the the the money side of the business. So it's a real balance between that agile approach to where you have a complex problem of how to get people to book online with a slightly simpler problem of how can we automate and make agents more efficient so they can handle more calls, otherwise we're as we grow, we're adding people in, so we're not necessarily seeing the operational efficiencies kind of flow down to the bottom line.

Very interesting answer. I mean, something just popped in my mind. So I've come across something interesting in the last few days. So what what I'm seeing is that a lot of the organizations are developing very, you know, let's say hybrid solutions nowadays. So what they are doing is they have realized that everyone's got a smartphone and people prefer using WhatsApps and other, you know, apps over, let's say, the normal messages or telephone. So what I'm seeing is happening is people have vendors have now placed these WhatsApp links on their products and if there's an inquiry, people are talking with a bot on WhatsApp. And then seamlessly, if the bot realizes it cannot handle this any further, it's transferring people to, you know, speak with a live agent, which is again very carefully chosen based based upon the AI matching that they're doing based upon the query and the keywords that are being searched.

So do you see that as like a transition kind of, you know, into the future before we completely fade out the let's say call center or contact center bit, which, I guess, will still exist for many years to come, but, you know, it's slowly being faded out, I guess?

Yeah, no, it's a it's a great question. And I think from an ambition, from a from a aspirational point, then, you know, we'd like all customer transactions to be completely self-service, and customers have all the information they wish or or all the information they need to make a purchase and a and a considered holiday booking at the at the at their fingers. However, the reality is we're being led by what customers want. And whilst we can obviously present prices, we can present images and textual information about the content of holidays, the content of ships, the itineraries, departure times, and FAQs and stuff like this, I think if the if what the customer needs is is validation that the that this holiday will suit them, and if that if that means there's a a hybrid between a digital and a human-assisted kind of buying funnel, then then that's what we'll we'll strive to do.

So it's yeah, you're absolutely right. It's you know, we have ideas, but really we're just experimenting and see what works. And certainly the the assisted kind of agent buying or helping them down the funnel being there, you've probably seen it on websites when you go down a checkout funnel or on a website, a web chat will pop up asking the customer if they need any information. So certainly either having the the the online journey be complete enough that the customer doesn't need to interact with people, or that if the customer does need to interact with a person, then they have they're not asking questions that they could easily self-serve. So that perhaps the the website or the UX and the information gets them a lot further down their journey and they just need a little bit of validation to say, "Is my I've got a seven-year-old and is this club happy? Is this club going to be suitable for them?" Just to get them over the line and make them make them confident that this is the right holiday.

So it's a it's a bit of both, really. It's whatever drives that confidence into transacting online. And definitely if there obviously there's we're experimenting with AI and and, you know, automated chat bots, things like that, but if the if the customer wants to speak to a human, then and if that if that helps the transaction, then then absolutely we'll we're certainly looking into those areas.

That's wonderful. Let's leave business behind. Let's go a little bit towards the the personal side. So now, I think it's common knowledge if we Google your name online, I think you're you're a huge proponent, you've written on domain-driven design, etc. So I'm just curious to understand what's been inspiring you with this, and in particular, what inspired you to start writing about it? How do you find this passion and motivation?

Yes, it's a great question, and one that when you're halfway through writing a book, you do often have to ask yourself, "Why am I doing this?"

I think like many people in IT, really, what drives many of us to get into IT? Really, it's all about solving problems and learning. You're always looking to learn something — that thirst for knowledge. However, what I found was that it was very difficult to understand how much I was learning. I think it was who was it, Albert Einstein said something like, "If you can't explain something simply, then you don't know it well enough."

So what I found is when when, for example, like domain-driven design, when I was, you know, first exposed to it and I was researching and learning learning all about the philosophy, I was so I read Eric Evans's book and there were at the time, there was only really his book and Jimmy Nilsson's book. And there were various blog posts or forums about it or tech meetups, there were discussions and presentations about it. But all this information was kind of in discrete places, it wasn't pulled together. And Eric Evans's book, while it's brilliant, it's quite a difficult read. And so what I found I was doing was distilling all of this information into what was core and then I was using this internally to talk to teams about, you know, breaking down what really the the fundamental principles were behind the philosophy.

And that kind of led me to the conclusion that perhaps other people are struggling with this, you know, with this vast array of information of how to really pick out what's key and succinctly kind of understand understand what it's about. And that's really what led me to Well, first of all, part of it was what I'd like to search for a book that kind of pulls all this together and tells me about it. And then really where where I couldn't find that book, then it was that because I'd done the research, the next logical step was to to be the person to write that, really.

So the purpose was twofold, really. One was to prove my learning and and two was to you know, help communicate this fantastic way of approaching complexity. And and the motivation, obviously, these books, it took several years to write, and really the motivation was a good editor pushing me to meet deadlines. So whilst it was it was very difficult, and some people use some people do it use blog posts or presentations at meetups to channel this this way of communicating, but I found having a book, and having deadlines, and having an editor was a was a good motivation, was a good stick to do it.

And really was the it was the like many people that write books, the the the first the first kind of reader I was thinking about was myself. So it was really, can I articulate, can I communicate this this difficult, conceptual philosophy, framework, collections of patterns and principles in a manner that people can really grasp it and and communicate it in a way that through stories and through theory, as well as kind of practical lessons learned from from my experience, really? So that was the so that was the passion. The passion was the learning and the motivation was kind of proving that I was able to articulate it in a in a simple and and and concise manner, really.

Yeah, that's that's quite a story, by the way. So you solved somebody's problem, while solving your own problem, you wanted to share something that's not readily available. So yeah, great, I mean—

Well, there was actually there's a funny story. When before I wrote the book on domain-driven design, I wrote a book on ASP.NET design patterns. And I actually because I wanted to learn about architectural design patterns to construct ASP.NET-driven websites. And so I found, searching on Amazon, I found there was a book about it. So I put it in my basket. It was a book it hadn't been published yet, so I put the book in my basket, checked out, and Amazon said, "As soon as it's published, it'll be delivered for free."

And then at the time, I was writing a book for the same publisher and I just finished that book and I'd asked them, "Is there any you know, is there any subjects that you need help with doing?" And they said, "Well, actually, there's the authors that were going to write this book have pulled out." And the book, it turned out to be ASP.NET Design Patterns. So I ended up writing the book that I'd purchased from Amazon. Luckily, I took it out of the basket.

Wow.

Yeah, so I ended up writing the But again, it was really it's it's it's very fulfilling. It does take a couple of years, and they're and it's hard to do, but it is you know, this is why people that write blog posts, it's brilliant.

I would encourage people to write stuff down because it helps either write stuff down or or present things, ideas, it doesn't matter how big or grand they are, because it's a it's a great way to cement kind of your own knowledge. Because if you can articulate it in a in a manner that people understand, it's a really good way to to to ensure you learn. And there's nothing like if if you've got to present something or you've got to write something down that will you know it's going to be in print or on the internet, it's a good motivator to make sure you really know your stuff, because people will certainly pull you up on things that are not necessarily correct. So it's really it does help to sharpen your pencil.

Otherwise, I I found that just reading about technology or reading about patterns or or or frameworks or or ways of working, they're very easily you can read it and it just kind of goes over your head. You don't really Dan North calls it, deliberate discovery, deliberate learning, to really focus, to really understand what things mean and then kind of play them back, use that theory and how it how it applies to your to to your way of work and how can you utilize that. So it's a really good discipline and it helps to make sure that you know that what you're learning is is really going in, really.

I agree there. I think I've stopped learning lately, so during my school or uni days, I always used to write, and I was that that's my thinking, like if I if I've written it, like just while learning it, I'll I'll somehow remember it, you know. It'll come when I need it. So that's always been my belief. So yeah, I agree with that.

Amazing, amazing. It's it's funny how things, you know, happen. So yeah, that's that's quite a good story, by the way. Thanks for sharing that.

An amazing story.

Could you share with us, what a little bit, what is the philosophy of domain-driven designs, as described in your Patterns, Principles, and Practices of Domain-Driven Design book? Why do companies use domain-driven designs as the basis of their architecture? What do you think?

Yeah, so it's a really good question. So domain-driven, if we if we think about fundamentally and go back to first principles, what what is the point of domain-driven design, it was really a way to manage solutions for for complex problems. So it's not you can't really it doesn't solve all problems, in the same way that agile doesn't solve all problems. It's and the the the simple premises, it's a paradox, it's quite simple to understand, very difficult in in practice, really. So it so what it does, it bases solutions to problems around the domain you're working in, so that both technical people, non-technical people can can reason about the solution to the the problem you're tackling.

And in order to achieve this, it has a very heavy focus around the idea of a a domain language. They call it the ubiquitous language. And the need to embed this this shared language and therefore the shared understanding into the code. So the the the language when you're speaking to technical people, non-technical people, you're you're using the same language to describe the problem and the rather than the solution. This removes the need to translate, or or or more importantly, mistranslate the technical terms into domain terms. So when you're when you're trying to solve a problem in that manifests itself in code with, and you're talking to with a business person, you don't need to change the the kind of dialect you're talking in, in terms of that they understand in a shared language that was built in order to to solve a specific problem.

So that's probably one of the biggest principles around it. And you build the idea is that you build this kind of model of this this problem you're trying to solve with with words and language that that articulate it, so it's it's easy to to to reason about.

When you when you start to read about domain-driven design, it's very easy to pick up the tactical patterns. So these are the the the the coding patterns on how to structure code and how to structure objects and and how to build it at a very low level. So that these are very kind of simple things to understand and comprehend. However, probably the best and the and the most the the best advantage of domain-driven design in addition to the ubiquitous language, and actually to answer your question of, you know, basing architecture around the principles of domain-driven design is the is the idea of a a bounded context, which is a strategic design pattern which helps to I guess distill and separate different solution spaces in in in a larger project.

And the and the bounded context, the idea of this, it's a it's a it's a physical in in well, physical terms of code, but it's also a linguistic boundary, so that things that make sense together, that the whole coupling cohesion over coupling is things that make sense together and and belong together are kind of, from a code point of view, kind of isolated together, so that concepts don't have two meanings in in two areas, really. And so that's the idea of a bounded context, which and there's other strategic design patterns of domain-driven design, but the bounded context and the different ways that that different areas of the business will talk to each other is probably the the area that has the biggest impact, or the biggest influence rather, on on architecture.

I see. So, so what you're saying is it's two things. I don't want to demean anything, but this is my common man thinking, right? So, so it's the easiest way to to map a business in code without making things very complex and and also it's easier to keep let's say if the business comes to the, you know, PM or the product team comes speaks with the the project team, there's less matter lost in translation because the there's less complexity around translating the business requirements into technical requirements and you you just keep it very low-key and very similar in terms of business and and that's that's how this design thinking helps, I guess.

Yeah. So if you think if I take a really, really simple example, if you in the world of e-commerce, you have products that you sell on the website, right? Whether they're bottles, bikes, bananas, or balloons, and other products start with other letters are available.

So with products, you might Somebody in the warehouse, when you talk to them about a product, well, first of all, they might not call it a product, they might call it inventory. And they think about inventory, they think about weights and dimensions, they think about storage locations, they think about how many can fit on a pallet, they think about how you how how those products get delivered, or how that inventory gets delivered. But if you speak to somebody in the commercial department, they might think of they might describe it as a product, but they might think of it in terms of how much margin it makes or the resale value. They'll think about it in a different way. In the same way as someone in marketing might think of a product in a different way, they're they're thinking about the imagery that goes along with it, the narrative, they're thinking about the descriptions that the customers, what will appeal to customers, or they're thinking about the product in in placement in their home.

So each different part of the business, or they those different parts of the business think, you know, if I well, it's a struggle to come up with a term that they would all agree on, if the warehouse are thinking in terms of inventory and the and the marketing and and product team are thinking in terms of product or or or maybe they have their own term for it. And so the idea is instead of trying to build a a model that will suit all of their needs, which would be a humongous thing and it would be very, very difficult to reason with people about this because the people in the warehouse will be thinking in very different ways than the marketing people and the commercial people, then we we put a boundary around the terminology. So inventory becomes bounded to the the the domain of the warehouse and product maybe the the the domain of the of the commercial department, and maybe product it is the same term, but but still, you know, defined in terms of what means to marketing.

So the idea is to separate, even though conceptually it's the same banana, balloon, bike, or or bottle, it's actually it means different things to different people, and those different people have a different vocabulary of describing it. And if we use the same vocabulary in that context and and embed that language in the code, then it makes it much easier to have conversations with them and and to reason about solutions and to work with them, and collaborate with them, because certain terms are have over you know, a term in in marketing will will mean something completely different and have different overloaded meaning than in a different department.

So it's about understanding the context, really. Context is a it's a massive, massive a massive thing. To understand things in their context and and understand where the boundary of that ends and begins, really.

I would love to offer this chance for our listeners to learn about you as a person. Scott, could you share with us or outline your typical day?

Yeah, that's a great question. However, as you can imagine, during these difficult times, there's doesn't tend to be a typical day, although that's probably part of the fun and the and the challenge.

However, what I tend to do regularly is have daily stand-ups with the various team leads, so the product leads, to understand really any blockers or or issues that are out of their control and that are stopping them from delivering business outcomes. And and also, it's a an opportunity to articulate to them any new narrative that's happening within the business, as you can imagine, very especially at, you know, in times of COVID, the pandemic, that the that the business environment we're working in is is changing extremely rapidly, especially in travel where, you know, when the Prime Minister gives updates on travel restrictions, and what you can and can't do, and that has massive repercussions on the business, and what we can and can't sell, and the suppliers, and the restrictions of certain cruises, and and this that. So it's a a constant way to get get feedback on what they're doing, how I can help them, but also them give them understanding of the wider context so that they can understand.

The more that they understand of the business environment and the business context, the more that they can offer support when when when confronted with new opportunities and and new constraints. So that's yeah, so that's a regular occurrence, the daily stand-up.

Then typically would check in on teams and help where I can facilitate problem solving between our, you know, our business peers and and the tech teams. And especially where we are all remote at the moment, historically we've been all built residing in the same building, but now we're remote, there's an even greater need to have to utilize problem-solving frameworks to really visualize ideas. So we we use a lot of shared boards online, Miro boards and tools such as impact mapping to visualize problems and visualize ideas and planning so that so everyone's really aligned. Because I think that's the one of the biggest challenges is we don't have the what do the Americans call it, the water cooler moment. You don't have that opportunity when you're going out going out to make a a cup of tea so that you can have that just you know, where you're just you're having that chit-chat, but you're actually you're learning about new stuff, and if people you know, you don't have that.

Online, you do have to book a meeting. Sorry, remote, you have to book a meeting with people so you don't get that kind of flow of conversation. So ensuring that people understand the narrative and understand and are aligned to the purpose and and the goals we're trying to achieve, because the goals do change rapidly as you know, I mean it's in a in a travel, sales-orientated environment at with the backdrop of the pandemic, things evolve extremely really fast, and we have to react to react with them react to them quickly. So keeping everyone on the same page and aligned, and and so that people really know the the context behind why we're trying to achieve something really helps. And then then they're more empowered then to do something about it.

And then really, in addition to that is I work with other business leads really to understand what's happening in in their different areas of the business, what new opportunities that we have, and increasingly what what new constraints we have, and how technology can contribute to resolving the the constraint or or capitalizing on the opportunity.

So what we found in the past is that the our business colleagues have often tried to come with us with projects or solutions. You know, "I need this project doing," or, "I need this built." Whereas we I try to get them to articulate their problem in terms of an outcome. So what what is it you're trying to achieve? And and trying to get it back to really what is it that they're trying to achieve in order that we're not we're not tied to solutions or projects, and we're focused on the opportunity or or the constraint. And this way, when we we engage the team, we're not really we're we're asking them, "This is the outcome we're we're looking to achieve," and we're giving them a problem to solve.

And because they are by their nature, they're closer to the problem, they're closer to that area, and they have the the art of the possible in terms of the technical expertise, we find that they they are able to offer more innovative and and creative solution. And the number of times where business colleagues have said, "Oh, really? I didn't know you could do that." And and if we if we'd given them specific solutions or projects, then then they wouldn't have had the opportunity to offer a new way of doing it. And and by giving them a problem to solve with good context, good measures, and and how it aligns to our overall kind of business objectives, then it it gives them a a sense of ownership, so they're they're more emotionally attached to it, I guess. And so they they and they get emotionally attached to the the problem and not the solution.

So they can they focus on what we the outcome we're trying to achieve, but they'll be they'll be open to the different options of how to achieve it. So it's really giving them given articulating the purpose and giving them the opportunity. So that's where, yeah, working with the the the other my my business peers on what's likely coming up, what the constraints, what the opportunities, and then and then kind of putting that in a in a way that that we can that the guys can action it.

I can see like how doing things on Zoom or Hangouts could be an issue when you have a totally different mentality in terms of problem solving and how you want people to discuss problems rather than saying, "Okay, we need to build some solution," instead of thinking it through properly with the with the leaders or people who are solving problems, I guess. So, yeah, I never thought about this. I thought we were coming to a point where everything would just be, you know, working from home future, but okay, maybe, you know, I need to cool it down a little bit. It's not as straightforward as, you know, we've been thinking because we we have been working from home for the past three years now, me.

Yeah, yeah. Yeah.

So, um, yeah, but, you know, what do you call it? Horses for courses, you know. Every business has a different requirement, a different need, and and maybe they don't some businesses can't operate, you know, working from home until we have virtual environments where we can see people in real. So, okay. Anyhow, let's move on. So, Senia, what's what's the last part, then?

All right. We're at the dessert part right now. So during the final part of the SphereCast, we ask our guests a tricky question. So, Scott, this is a tricky question for you. If you were able to go back in time, let's say 10 years ago, what would you tell yourself about leadership that you didn't know then?

Oh, that's a good question. Probably that leaders are kind of making it up as we go along. And what I mean by that is there's there's more data now than than we've ever had, right? There's more information, more data, but you you still need to have use good judgment on how on how to interpret that data. And actually, you can never be 100 percent sure of everything, so it's all based on hypotheses or assumptions. Because when you're working in in Well, actually, let me clarify that. It depends on the problem context you're working in. If I know that I don't know, if I know it takes me 10 minutes to walk to the the the kettle and make a cup of tea because the kettle's on the other side of the building, then I know if I move the kettle closer to my desk, I can reduce 10 minutes down to 5 minutes. So that's a simple problem to solve and it's it's you know, it's an obvious problem domain.

But where our problems tend to reside in complex problem domains where there is no direct correlation between cause and effect, i.e., I move the kettle closer to me, therefore I my travel distance is shorter, which equates to less time spent, you know, moving to the kettle. If I want customers to transact online, there is no correlation between cause and effect. I don't know if if changing prices will will make a difference. I don't know if better content will make a difference. I don't know if images or reviews will make a difference, or advertising, or you know, the placement on the page, or the the color of the button. We don't know if any of these things make a difference. So, but we can hazard guesses and we can make assumptions. And and importantly, you know, when we get it wrong, acknowledge we got it wrong, and say, "Right, you know, we've learned what doesn't work, brilliant, so that's one one less thing we've that's one more thing we do know that doesn't work," and then correct the course of action.

So where I yeah, so where I, you know, to clarify, when I say we're making it up, there is a, you know, you've got data, but it's basically down to judgment, really. And that's what and really that's that's the whole if you think about strategy and and kind of leadership, you are you're giving people direction, but it's still a it's still a big bet, it's still a hunch based on on on the data you have. So I guess that would that's something 10 years ago I thought, "Oh, leaders, they must know it all. They've gone to leadership school, they, you know, they know everything." But they're, you know, we're we're only humans, we're fallible, and you know, the the environment, we've never worked with in this environment, in these times, with these sets of people, and these sets of challenges. They're all unique, which is why, going back to what I said at the beginning, why this is a this is why it's such an interesting problem, because it is complex, and why it's a a high barrier to entry, and why it's such a you know, it's a great opportunity.

Probably also, if I went back 10 years, I'd probably realize that actually that probably nine times out of ten, all problems are down to the system, so the system of how we work rather than people, and that a bad system will beat a good person every time. And that I guess leaders control the system, and when I say system, I mean the system of work, how we work, our our mental models and the principles we we behave with, and leaders have the ability to change that mental model through leading by example and by changing.

I don't think I've worked with anybody, and I can say this with my hand on my heart, I don't think I've worked with anybody who hasn't tried their best. And and and of course that, you know, we can never we've never achieved exactly what we set out to do and then there's always constraints, but it's never I don't think I think as a leader, you have to understand that it's you can't blame people when they try their best. You really need to understand what changes do I need to make in the system in order to improve the result next time? And it's the leaders don't necessarily need to have all the answers, but they need to set up the environment so that the the the team has a has a has a better chance of succeeding. And then understanding when when failures happen, what changes do I need to make in the system to avoid this next time, rather than blaming people.

Because I do think there's no I I can honestly hand on my heart, I don't think I've ever worked with anybody who hasn't tried their best and hasn't had the best certainly the best motivations. And through a lack of alignment, or expertise, or support, or the inability to remove constraints or blockers, they haven't been able to achieve what they were able to do. And all of those things were out of their control or or perhaps the the focus of a of a leader. So, yeah, so really the lead I think the leader leader's role is to set up the environment so that people can succeed.

Does resonate with us, absolutely. I think and I think we are we are also lucky in that way that we work with some of, you know, the leadership in our organization is is very much in, you know, operates in the way that it's all about creating that environment which makes the whole team successful and and making sure, you know, like if we fail, we learned learned from it and we are allowed to fail, you know. That's that's a that's a good thing as well. And and they see if we are learning from the failures or not, and I think that's another thing. If you don't learn from the failure, then maybe there's something wrong with the system, you know, like it's

Or if you don't fail, something is wrong with you.

Yes, all right. It's called reporting, so. Yeah, great. So okay, yeah, that's that's a good one. So, Scott, I think we've come to the end of the episode. I have to say it was it was very refreshing hearing the things you said on this episode. I really enjoyed bringing forth your knowledge on the domain-driven design, your stance or your qualities as a leader. I think they stand out. So it's it's been 40-something minutes of, you know, a great lesson for me, so I really enjoyed it. Senia, do you have any ending notes?

I concur, Scott. Thank you so much for joining us. I know there's a little bit of technical difficulties in the beginning, but it all worked out. And thanks, and we would love to have you again sometime in the future.

Oh, no, you're welcome. It was it was lovely to talk to you. Thank you.

A special thanks to our podcast guest this week, and once again to our sponsor, Sphere Partners, for bringing this episode to life.

If you enjoyed this episode, drop SphereCast a five-star review on iTunes, and share this content with your network.

For any relevant links or notes from this episode, check out our podcast website at www.sphereinc.com/spherecast.

And always remember, when you think you can't, technology can. See you next time.