Haydn Shaughnessy: Transformation Sprint

We talk to Haydn Shaughnessy about transformation and how organisations can reduce the risk in change and transformation by running a transformation sprint.

00:35 Insights & Takeaways
05:00 Interview

Links:
Book on Amazon: here
Author website: here

---------------------------------------------------------------
 The Wicked Podcast:
Support us on Patreon: here
The Wicked Podcast website: here

Find us on Youtube: here
'The Wicked Company' book on Amazon.co.uk: Buy
The Wicked Company website: visit

Music:
'Inspired' by Kevin MacLeod
Song: here
Creative Commons License

Sponsor: Zencastr : http://www.zencastr.com Get 40% off the first 3 months for unlimited audio and HD video recordings Code: wickedpodcast

'The Wicked Company' book on Amazon Associate Link: https://lnkd.in/dk34h-_s

The Wicked Podcast: Support us on Patreon: https://www.patreon.com/thewickedpodcast

The Wicked Company website: https:www.thewickedcompany.com

Music: 'Inspired' by Kevin MacLeod Song: https://incompetech.filmmusic.io/song/3918-inspired License: http://creativecommons.org/licenses/by/4.0/

Transcript

Marcus Kirsch: 0:15

Welcome to the wicked podcast where we read business books you don't have time for. I'm Marcus Kirsch.

Troy Norcross: 0:21

And I'm Troy Norcross,

Marcus Kirsch: 0:23

and we are your co hosts for the wicked podcast.

Troy Norcross: 0:26

We take from the 1000s of business books out there and test the author's ideas by comparing them to real world challenges. With over 40 years or projects between us, we've got quite a bit to compare against. We give you the condensed takeaways followed by an interview with the author's

Marcus Kirsch: 0:41

we know you want actions, not theories and his actions that we want to help shape because that's what the wicked podcast is all about helping you to become a wicked company.

Troy Norcross: 1:12

Right. So do you prefer crickets? Or do you prefer beetles? Or do you prefer ladybugs?

Marcus Kirsch: 1:22

ladybugs are quite cute.

Troy Norcross: 1:23

Oh, yeah. Okay, so they are all the nice kind of insects. They're the nice kind of bugs, as opposed to technology, bugs. And you and I, neither one of us like technology bugs?

Marcus Kirsch: 1:35

Yeah, let's hope we're gonna have to video on this one, right.

Troy Norcross: 1:39

So I love to be a beta tester. I'm really happy to find new things with technologies that were good when it effing works. By complaining who's on the show?

Marcus Kirsch: 1:53

Yes. So today, we have Hayden Shaughnessy in here, who is one of the co authors with Finn Golding on a new book called transformation sprint, which sits close to my heart, because it's really focused on transformation project in particular, and has some some great views on that. And generally, sort of a book that we seem to have been missing a little bit.

Troy Norcross: 2:16

Well, I like the whole idea of doing sprints, and doing the transformation sprint to get ready for transformation and give yourself a chance, it's for really, really good success. And this is really aimed at large enterprises who typically don't do very well at these kinds of things. My big takeaways were, again, break it down into smaller pieces, make it a bite sized piece, don't try to eat the whole hog and do three different large global transformation projects all at once. And the other one, you know, he says, if you look at an organisation, they've been through transformations, intentional or otherwise, like adapting to supply chain challenges coming out of the pandemic, or adapting to remote working. And so if you look at how these things have been transformational, and how they've been successful, it hasn't been without bumps along the way. And if you can look at how, as a company, as an organisation, you not only survived the bumps, but thrived and move through them in may give you the confidence for future transformation projects. And I love both of those. What about you?

Marcus Kirsch: 3:26

Yeah, that sounds great. I think that the thing that really stuck out for me is the fact that, and I think that goes a little bit back to potentially pivoting or allowing for pivot. And it's essentially saying, he said, in his experience, there's a tendency to, you know, move the initial transformation, essentially just into a digital transformation. And it's not just a digital transformation, you know, in his own words, his own a business is given a pass at having to transform, so they don't do an initial assessment of actually, what's the operational structure even look like? Why we're not baselining. And I found this a lot as well, where, you know, the right areas are not included, and the transformation sprint itself is one of the methods I would say, to be able to do exactly that, you know, and I think therefore, I find it really as a good takeaway to go, when you start, have a look, business should be involved, it's, it's those things always have to dependencies on that. And there's always value to be created by transforming wider into the organisation essentially, plus your de risking because you're involving other people, other voices, other views, other other requirements, and therefore they should all be part of it. Otherwise it's too tech driven. In that sense it often up for failure.

Troy Norcross: 4:45

And, you know, I've got a background in tech myself and on the business side, and it's finding that balance between the two. That's that's the real art but again, none of our waffling What should we do Marcus,

Marcus Kirsch: 4:57

we should go to the interview. Hello, everyone, today we have Hayden Shaughnessy with us. Hello, Hayden, how are you doing? And thank you for making time for us.

Haydn Shaunessy: 5:11

You're very welcome. Nice to me.

Marcus Kirsch: 5:14

Thank you. As usual, we start at the top. So tell us a little bit about who you are and why you wrote this book.

Haydn Shaunessy: 5:22

Okay, so my background is in technology, not in it, particularly in product development, but also in Think Tank. So I've done a lot of product development work in my life. But I've also done a lot of thinking about that a lot of writing about it as well. He about three years ago, pin Goulding and I set up a company called the flow Academy. And flow Academy is a transformation specialist. So we do a lot of transformation work for organisations in Europe, in the United States. And after a period of time, we started to realise a couple of things, you know, one is that most transformations go wrong, that's very well evidenced. But also that the transformations weren't most transformations that we've been involved in and probably had the same fault lines, who probably had the same things going wrong. And that's things like they tend to default to an IT transformation, even though they begin as a business transformation. The business tends to be let off the hook. To a certain extent, a lot of the things like the promise of new ways of doing business isn't followed through on and things like the it transformation itself tends to be a bit heartbeat, you know that in that they don't deal with some of the critical dysfunctionality that stems from poor legacy management. So you have this thing where you've got this big transformation, it defaults to it, lots of business off the hook. But also it tends not to follow through even on the it transformation, it doesn't do critical, critical change where it's needed in it. So you can see why things going wrong. And because it's these are all so common, we thought, actually, there's probably a simple method for addressing this. And that's what we baked into the book. So the book is really a six step method for rectifying your transformations go wrong, or designing one before you set out.

Unknown: 7:16

So one of those.

Troy Norcross: 7:18

So one of the things I want to kind of get really clear right at the beginning, is you talk about transformation. And you say, it winds up kind of defaulting to it and then the business gets let off the hook. Is it digital transformation? So one of the things I always try to work on when I'm dealing with clients is getting clear on the terminology. So what is the scope of transformation when you say it, because we can transform all over the place. But when you say transformation, what are you specifically looking at,

Haydn Shaunessy: 7:47

I think you've just put your finger on one of the big problems that very often these transformations are designed into mega projects or mega programmes. And they try to incorporate far too much. So you can be working on a digital transformation. And within that you've got an agile transformation, that somebody is given the task of trying to stand up. And typically, while we worked in an insurance company a couple of years ago, where exactly that was happening, you had all this stuff going on a big programme, a big digital transformation, if you like, at the same time, a big legacy rationalisation programme that wasn't working particularly well. And at the same time, there's this other thing going on, where they put a couple of agile teams together, and actually had nothing for them to do. So yes, they were trying to cover every single base. And that is part of the problem.

Marcus Kirsch: 8:37

So when when when you say that. The other thing I just wanted to get to as well was that. So I've been I've been in a number of those as well. And, you know, when I read the book, the whole idea of looking, first of all at are we actually looking at the real at the right problem? Are we involving the right people? Are we transforming the area we should actually be transforming often doesn't seem to be able to be addressed. So I think it's great when you read a book cycle. That's great when that happens. If I take one step back from that and say, how do we get organisations more to care about that step to say, hang on a second, let's treat what we're trying to do, at least for a little bit as an assumption for the four weeks of a sprint or something and say, let's get a bit more evidence there because we might missing a track and a lot of projects are missing a trick. So how do we get organisations more to care and valued that time of the programme?

Haydn Shaunessy: 9:37

Yeah. Well, I give you a little story. I read recently about heart attack victims. Apparently anybody has a heart attack is told to when they recovered, go away, exercise more and eat the right things. study on that particular population found that only between three and 5% of people followed that advice. So here you have a problem where most people are risking their lives by not eating better and not and not exercising properly, even though they've already had the, the near miss. So this problem of people doing things that they shouldn't do not following advice, and taking things on that perhaps beyond them is very, very common across human nature society or whatever you want to describe that as it's very, very common. And try to find the catalyst or the switch that says, you really don't need to do do it this way, I think is very difficult. And, and our experience would be that you will, you will only really get the chance to do these things, if they are small, and seen as less important. So I think it would be rare to see organisations say, you know, what, will abandon that big transformation programme that's costing us 10s of millions is going completely wrong. And we'll do something else we'll do a transformation sprint, instead, they won't do that, what they might do is do a transformation sprint as well. So at least with the transformation sprint, you've got a low cost way of saying, we can now learn something we can we can get into an environment where it's predicated on becoming a learning organisation. One of the big problems with these transformations is that they do not teach people very much at all, they're not learning environments. And you see that in the way they're set up, they're set up through these long consultation exercises, usually using consultants who are using a model from somewhere else or from their last assignment, you then go through that planning process, as I've said earlier, you tend to get very intricate dependencies in entwined in those transformations. Because people have had 12 to 18 months to plan them out, you know, every time we look at them, we think we can do a bit more there. Or I could add this in I can add that is typical of the old requirements documents. So you have this problem that they're intricately planned. The bigger problem comes when you start to design the governance and management of them, because you use very traditional techniques for that. I think this is one of those great hopes is you can say, look, it makes no sense whatsoever to use traditional planning and management and governance techniques to get to some way completely new, which is going to be agile, fast moving and small. If you can win that argument, fantastic. But even if you can't win the argument, we need to start pushing this observation that the way in which transformations are set up is intricate, beyond human ability to deliver against, there's far too many dependencies in there. And that's why they go wrong. Far better that you go back to what we're talking about, which is the kernel of a learning organisation, and grow your learning and capability.

Marcus Kirsch: 12:50

Yeah, I think that's that's probably what you just described. You know, I've seen in a lot of projects, and I think when it's done, right, things like governance were actually included in like, well, we need to find a new way of that, too. Yeah, and I just had a recent experience with a project where the first thing they did was structure, everything via governance, and then trying to similarly figure out what to do, which is totally backwards. And, as you said, also, like improve, you know, including these classic governance models that are just still ending up with way too many sign offs to why managers haven't even shifted their roles yet, but you want to introduce an agile process, which might still in the end, just be a garbage in garbage out system, because it doesn't ask the why. But when I look at that, and you're saying you're talking about lots of requirements, and lots of things to address. prioritisation is always something that comes up, which also often there needs to be rejuvenated or adjusted often, because you might be measuring new things. So what what's your view on prior to prioritising once you start typing out new things?

Haydn Shaunessy: 13:57

Well, I think that just to conclude some thinking on on those big programmes in the management and governance. The problem with that is what tends to then happen is you you also have a conventional set of KPIs, and you also focus on execution. And that's another big problem, you know, you've got all the management of governance in place, it's only about execution. And that's what we found goes wrong. People can't execute against these plans. In terms of how you prioritise, I think, what what companies often fail to do, because they don't have the capability to do and consultancies don't have the capability is to understand what the current operating model is. So if you look inside a lot of organisations, you see quite disjointed and incoherent operating models, and that's nobody's fault. So it's not somebody sitting there thinking, I know how to design the way we should get things done. And I'll do it badly. It's more that over time, what's happened is that things have been added into the mix. You've had this say in the 1990s went to global supply chain models, only to be hit by the world. Wide Web in 95 to 2005, and have to adapt to selling online or dealing with their procurement channels online, only to be hit by global mobile in 2007 2008. And having to do with that, and then coming across things like I'm just distracted by the light there. And then coming across things like AI and machine learning, and platforms, and business ecosystems, all these things are kind of on a continuous roll over the last 25 years. And it really means that companies have been tasked with doing two or three simultaneous transformations all the time, I think we need to acknowledge that, you know, if we can back out to the big transformation plan and say, actually, you know, we adapted to global supply chains and World Wide Web, global mobile, with now adapting to AI, we're adapting to remote work and and look at it as a continuous process and say, okay, where does that leave our operating model? If we were to describe how we actually function as an organisation? What does it look like? In transformation sprint, that's one of the things we recommend that there's a real focus on what is the existing operating model of the firm, starting to teach executives, what operating models are not organisational models and not org charts. And they're not to do with the IT infrastructure or architecture, they're the business architecture is how things get done. And those things, those models, or, yes, operating models are changing all the time, we need to stop and think how we develop skills in developing those. And I think when you start to look at an operating model, in flight, you start to see what needs to be fixed first. And that's one of the things that we're trying to point out in the book, that actually, by defining or describing the operating model, as it is, you can see the critical failure points or the critical crisis or response, and address those, but only address one of them.

Troy Norcross: 17:02

So I like what you said, when you said kind of look at what we've actually achieved, you know, we've done global supply chain, adapting, we've done remote working, adapting. And I would hazard a guess that none of them were smooth processes. I would hazard a guess that actually there were a number of kind of faults and failures and problems along the way. And the reason I'm saying this as I think a lot of people look at transformation, and innovation in general as being very risky. And they're afraid to try things. So I think if we can look back and say Yeah, well, we tried a whole bunch of different stuff. Some of it works, some of it didn't. But we survived and became a stronger organisation for it. That's really important. How can a transformation sprint? Do you help organisations get ready for things not working? and dare I say the the F word for failure?

Haydn Shaunessy: 17:54

Yeah, well, I think that one of the points we try to make is exactly that. How How do you deal with failure, if you're not alerting your organisation? Very often, organ companies don't learn from those failures. Because that's the moment when you start firing people, it's the moment when the transformation director look for another job, or she's probably already been looking for one for three months. So a lot of the things that happen in this failure environment are what generally happens when it starts to hit the fan. So you what you need to do is to is to, again, peel all that back and just say, okay, we can start with one project, we can look at our as his condition, or his or his as his operating model, and we can identify really critical points of dysfunctionality, what's causing these dysfunctions? What's the underlying cause of the dysfunctionality that we're suffering from? Well, let's address that. Let's address it in one project. And we call those projects, lighthouse projects. And what we mean by the lightest project is that it's not just another programme, it's not just another innovation, it's not a project like an MVP, or a pilot or proof of concept. It's a way of saying, we're going to make one critical structural change, we're going to fix one structural problem and one only, we're going to do it through new ways to work and we're going to do it really quickly. We're going to deliver value very quickly. So we're going to be delivering value within a month starting. So if you start to take that approach, you can start to test what it means to be a learning organisation. Because the first thing that you find when you start to do these lighthouse projects, is it starts to dawn on people that they don't actually have the skills to execute them. And that's another big problem. You know, that very often that transformation programmes rely on who's there. They do rely on contractors who are not necessarily any more skilled than people in the organisation. They rely more on consultants who are not doing anything for your context, really working out their business model, and they rely on vendors in a very, very rarely rely on the skill, ingenuity, commitment and engagement of the people working in the firm. And shows when you start to do the lighthouse project, it really shows because what it means is very often looking around and saying, well, the way this is going to go, if we're going to say rationalise some element to the idea state, we actually don't have the skills around to execute on the next new normal. So getting these experiences having the opportunity to get these experiences. So one of the lighthouse projects we tend to favourite is one where you do a lot of value discovery. So you go and segment your market differently. And you look within those segments and new things that you could be offering to the market. And you start to revise or refresh your innovation capability, your Innovation Model, if you like our innovation processes. So when you do that, again, it tends to be the case that most organisations have jettisoned the critical insight capability that they once had, just like they've jettisoned a lot of their r&d capability, because now we rely on lean startup and fell, fell fast and cheap those types of scattergun approaches. There was a study recently, I was published recently, anyway, that actually looked at the massive innovation deficit, and traced it back to the way companies been closing down their r&d departments, we have to remember a lot of those r&d departments where they had in them philosophers, mathematicians who were not doing anything related to AI, they would just think there would be I mean, remember, IBM used to hire loads of people like that, just having the brain power out. There would be anthropologists, they'd be sociologists, all these people were gathering insight continuously about how markets were changing. Most companies don't have that because they think that big data is going to solve that problem. So so you start to wrestle with this latest project, you're going to refresh the innovation process, then you get into it. And you see, actually, we don't have the insight capability to do that. And therefore, in the learning within within weeks, you've learned, we need to start refreshing this area of our business, we need to start rehiring or accessing people who have genuine insight around customer segments. Now, I've lost track of the question, but my, my answer is duerr. The question was, like, as projects get you back to these critical learning opportunities, and that's what companies need more than anything else.

Marcus Kirsch: 22:24

Yeah, I think there's about probably at least three things in there exactly the way you answered. And they're all they're all great, great points. So I would like to follow on the one where we say, again, I'm drawing some experience in here where we had project, for example, when we had we started with three teams. And two of them ended up actually pivoting. Because they found something right. And my background is design thinking service design, which is a lot about investigating the problem. Is it really a problem, checking if the assumptions Hold up. So we ended up being able as a luxury, I guess, to pivot, quite a few teams and projects. However, the way you just described it sounds like there might be a main purpose of the transformations. And that's not just to plan and, you know, risk, assess, and get a few things straight, and discover a few things, but actually to mainly discover if you can actually do it or not. And you know, when you're saying learning is to happen, like, Oh, we forgot the whole learning. Yeah, it's a maturity check on bit of a checklist of things. Yeah. Would you say that that's more correct. And therefore, it should be used for that more often without the anticipation even a transformation to kick off? Well,

Haydn Shaunessy: 23:47

I think that's a critical critical point. And Finn, my, my partner and co author introduced me to a phrase that I love using because it is mine actually, being there is not a qualification. And very often, that's what you get with translations, you're you've got a translation director, who just happens to be there in another role, and they get appointed, you get various people in that mix as well. You just happened to be there, and they get appointed. So you're already starting off with that without enough awareness or appreciation with the skills it takes even to design the transformation, let alone manager minutes in flight. So So what can you say about that, that we can use constructively and how hard is it for an organisation to acknowledge that it doesn't have the skills that will equip it for the future? I don't think that should be a difficult thing to do. But what makes it difficult is often the HR is concerned with something else. So HR might be concerned with, it might be the communications in the transformation or it might be Be that they are wrapped up with problems around hiring into parts of the organisation where there's a large amount of staff churn. They're not necessarily focused on on nor do they understand and nor does anybody necessarily understand what skills do we need when this transformation becomes real? When we've got to the outcome stage, what skills it takes to manage this business going forward? I think that's a really big deficit and transformation. It's like the the inquiry and the continuous investigation of what skills are we going to need? Let alone What skills do we need right now.

Marcus Kirsch: 25:39

And even even then, further, as may be nearly an obvious step, I'd like to have your view on that. Because we literally on Monday, we recorded an episode with with Jeff Schwartz from Deloitte, who is working in human capital. So we talked about they had done some research with CEOs or leadership, who weren't even aware to the amount of their existing employees and how much they actually want to learn new things and are happy to do so their perception was like, No, we have to wait bigger amount have to let go and then hire new talent. So that goes to that kind of hiring and firing whenever transformation happens. And most companies anticipating it will be a fair amount, and we want to minimise that cost, how we do that. Whereas research shows, if you probably due learning better, you actually going to end up with being able to upskill people, what's your view on that in order to? How can you bring that in? Do you need to bring that in during the transformation sprint? Or can you learn that on the go while you phasing in or sort of raising those capabilities are new ways of working? what's what's your experience?

Haydn Shaunessy: 26:52

I think your transformation Sprint's what you're primarily trying to do? Well, what you're trying to do with transformation sprint is designed the lighthouse project, and that lighthouse project is your opportunity to learn and your opportunity to embed learning as a critical mechanism in change. So you have to appreciate that limitation. I think, once you start to which we start to do that, once you start to think about this one critical project that's addressing one structural element, you can start to expand that outwards. And you can start to use the people in the initial team to seed capital, the human capital development if you like to use that term in other teams, so you can grow outwards, you can sell divide, and Amoeba like grow your transformation that way. There's a tendency amongst amongst large organisations and people hiring the Echelon not to particularly like small projects, big projects are what really matter. The problem with the big project again, it's another problem. You don't want to talk about problems all the time, but you pointed it out a lot of the people in that programme. Now there for the sack, you know that we remember when lean first came in and lean at the moment is, is it is getting a pass from it's quite totally passed. In some respects. If If you went into organisations 10 years ago, and mentioned the word lean, people would want to cover because they knew that it was their job at stake. And they'd seen a lot of their colleagues being unceremoniously dumped. And that's the case with translations. You know, it's unfortunate, but the way they're set up the fact that they are planned and run by consultants that they immediately bring in loads of contractors, that they don't trust the people in the organisation to plan, design or execute on the transformation. All those are red flags. And they are they're all going to cause you problems because you immediately create the levels of passive aggression, sometimes outright aggression, that absolutely do what you're trying to do. Alright, so

Troy Norcross: 28:53

we know how to crash and burn. We know we've got a great book that we can refer to you know, Greg, we have customers and colleagues on how to do a transformation sprint and how to do a lighthouse project. Can you tell us a story of one great success and why it was such a success?

Haydn Shaunessy: 29:12

I think that question would be better put to an existing traditional transformation project because they are great big programmes, but you really need to look for a small successes. Yeah, okay. So so one of the examples we give in the book is at Paddy Power where they had malice like a lot of companies do to generate something like seven core platforms, or more or less replicating what the first of those platforms did. So rather than ever rationalising platform one, they grew another platform and another and another and another. Them way in which that would ordinarily be involved would be very disruptive to the organ evolved would be very disruptive to the organisation. But what power did in that position? case we say, okay, we are not going to do that big transformation programme, we'll take one part of our core platform. And we'll experiment with how to make that work more effectively with one product line. And that particular product line for a company that works across all gambling and gaming projects, products, was just one in dog racing. And they use that as a way to learn what it meant to do the transformation, what changes were necessary, what new skills were necessary, what the times COVID look like, what resources look like, what the learning ramp looked like, unused all that then to move on to the next product, and then the next product, doing that cell division, as I mentioned earlier along the way.

Marcus Kirsch: 30:49

Yeah, and I think one aspect that brings me back a little bit back to people again, so the other thing, and again, I'm speaking a little bit from design thinking service design, which a new ish kind of practice in that space. But you know, you got business LS, you got Enterprise Architect, if you're talking about practices, and especially going back to nearly the first question around, well, you know, in that sprint, or when you're prepping for transformation, you should actually go and start talking to multiple stakeholders, a lot of different backgrounds to get a more holistic view on things and more quickly get an idea about if you're on the right track or not, and what matters, really. How do you how do you bring? How do you think about bringing these different practices together in terms of often, you know, the language they use, and so on? And do you think it's sort of an outdated model where you say, you know, stopped or silos stop that the practices don't work anymore? Because there's too many overlapping ones who all are trying to do the same thing with slightly different tools? Yeah,

Haydn Shaunessy: 31:54

I think that is a really interesting point, isn't it, because you've now got cx design, UX design, design, thinking design, sprints, product design, product discovery. So there are a lot of methods out there. I think that the critical missing factor, if you like, is what happens when companies change in an unconscious way, or when they change in ad hoc ways. So let's explore that problem or that situation and see what skills apply. And give an example and it could be one of many. I've just focused on one, it's an organisation that was going to do a digital transformation, it did a digital transformation of sorts, not a very complete one. But it went from being a bricks and mortar b2b business. So it never owned the shops, but supplied into them to creating a global mobile capability. So now it can sell via mobile operators or, principally mobile operators. Now, its next move is to say, we can be a platform, an ecosystem business, because we don't just want to rely on retail, or the mobile operator to do and delivery to customers. If we can create a an ecosystem of independent vendors or independent retailers, we can balance our overall portfolio. So we're not dependent on the large retail community. Now, that is all very, very sensible strategy. I don't think anybody would question that. In moving that way, you also give yourself the opportunity to disintermediate the retailer, which disintermediation is a bit bloody, but it has to happen. So what that means in terms of how the organisation functions, it means that the company has three operating models. Now it has its retail operating model, where all of its reflexes are designed around getting product into retail stores. All its sales processes, and its accounting systems are predicated on that as well. Now you've got this other operating model where it's all digital, you're pushing product in a digital channel, through mobile operators. And here, you're trying to develop a third one, which has to do with independent vendors, but only in the sense that, you know, you're not pushing product to them, you allow them to use their facilities, and you are bringing customers to them. So you're trying to develop a quite different relationship. That's manageable if you're conscious of it. If you have a chart, which says our current operating model is made up of these three major components, those major components has different technological platforms associated with it, and therefore has different software development requirements around it. What happens in these kind of situations and this is not uncommon. It's a really, really common problem. What happens in situations like that is the software team here will be saying, we're developing for our core, retail b2b business, and then B To come along, say, No, I need you to prioritise the mobile channel. So they start prioritising the mobile channel. And then its annual sales day. And the CEO says, Why haven't all these things been prepared, ready for annual sales day. And all those people, we dragged off that mobile channel onto that channel. Meanwhile, the be the guy running the platform and ecosystem operating cider, he'll be saying, I need those people as well. So he takes people from the production. So you get people dragged between these different operating models the whole time. The problem with that is you might be really, really well resourced. You might be adequate resources to service all three elements. But when you start dragging people back and forth, they start to context which their efficiency drops off cliff, and you end up with a lot of people not doing very much well. So you can sort of shoot yourself in the foot by not having operating model awareness and not being not designing around it not making you're making sure that you service those operating models properly, not just on software development side is on the business side as well, your business people need to know. And we've seen situations where sales and marketing or sales themselves, our main goals are to sell more stuff to those retailers. And CEO is saying, No, no, no, your main goal is to stop shopping cart drop out. And they're saying, But why didn't you tell us nicely? We thought we had. But it's it's like mixed priorities, mixed goals, mixed messages. People not really knowing what they're doing. But nobody knowing that they don't have the right instructions. That is really, really common. Now, how does design thinking do with that? Oh, well,

Marcus Kirsch: 36:46

it's? Yeah, that's a really good question back there. And I think it's one of the things I came across tonnes of times. So you know, in my case, I ended up talking to the different practices and say, why don't we align those things, that we actually have the same names, the same target descriptions, inclusive enough so that people get, you know, a more fleshed out picture of what what do we actually want entitles things together? I wouldn't say necessarily that I've been ever in a project long enough for those to really work vertically, you know, on different managerial levels well enough. But some ambitions I've seen, and I think got we got to a couple of good places there. I think I think it's probably that, you know, which, and I totally agree, I'm not married to service design and design thinking, because I've worked too, too much with other people to be happy to, you know, work with what works. But it's really interesting, that language issue because it goes all the way up to business. And then, you know, how do you commute? How you enable something that can communicate in between all these things? Why just? Yeah, go ahead.

Haydn Shaunessy: 37:54

I think there's, there's a good case for saying that there have to be an inclusive design capability that includes the architecture of how things get done, as well as the architecture, as well as the inspiration or design of the product, or the brand or those things. If you if you look at what's happening right now, we've got even more diversity and proliferation on the way because over the past two years, you've got a lot of product design. There's not actually product design, its feature design, or its feature management. So you go on to any product design website at the moment, what you're really looking at is a little bit of software to tweak a feature. And it comes under the rubric of product design. And it's all part of this big project product transition. So now we've got on top of design thinking service design, design, sprints, UX design, service design, product design, and that they're all in their own way, being trivialised by the extent of that diversity. And I do think it'd be better to bring them together on to something which said, actually, what we're about is designing the future. So no, we are we are the future business department. And our job is to design sustainable futures for the organisation.

Marcus Kirsch: 39:13

Absolutely, because otherwise,

Troy Norcross: 39:15

as much as we'd love to keep talking to you, I'm afraid we're running out of time. Because we can sit here and talk to you for the rest of the evening. I'm afraid but but Marcus wanted to wrap this up.

Marcus Kirsch: 39:24

Yeah, so just then maybe please comment on very last question. A little bit, following up from exactly that, I think is one of my question. I always like to squeeze in somehow, which is the idea between, you know, specialists and polymath or jack of all trades. If we're giving that and we're saying you know, there are all these different things out there and we want to create less silos, which specialists tend to be very comfortable in at times. What's your view on you know, are we living a bit more in a time where jack of all trades are the systemic thinkers should be running things more or or can contribute more than previously, specialists, maybe.

Haydn Shaunessy: 40:10

I do think that we've, this is an active process we've gotten more and more towards specialisation. There's not really a specialisation is just a limitation. So a lot of those things we just described like product design is a limitation on people's ability to act and think, and why the design brief is much more appropriate. So I think that we need to recognise the fact that this is not specialisation is limitation. At the same time looking at the other end of the problem. I do think that the, in the age of Google, the generalist is a multi specialist. We don't need to have some into our areas like design data science, where you can say, look, if you're not if you're not doing the right math, you're never going to get this but outside of those very specialised areas. I think that most generalists can be a specialist like like lawyers can be a specialist in you know, each case is different. And each case they really learn from scratch so we can all do that these days.

Marcus Kirsch: 41:12

Lovely, great, great words to wrap this up with Hayden, thank you so much for your time and for your insights. Thank you for for being with us today.

Haydn Shaunessy: 41:20

You're very welcome.

Troy Norcross: 41:28

You've been listening to the wicked podcast with co host, Marcus Kirsch and me Troy Norcross,

Marcus Kirsch: 41:34

please subscribe on podomatic iTunes or Spotify. You can find all relevant links in the show notes. Please tell us your thoughts in the comment section and let us know about any books for future episodes.

Troy Norcross: 41:47

You can also get in touch with us directly on Twitter on at wicked and beyond or at Troy underscore Norcross also learn more about the wicked company book and the wicked company project at wicked company calm