Colin (00:01.775)

Hi and welcome to The Growth System, the podcast that looks at the world of B2B growth through a systems thinking lens. I'm Colin Shakespeare.

Chris (00:10.454)

I'm Chris Bayless.

Colin (00:12.613)

And in this episode, we're diving into a major organizational trap, which is how companies default to just set and forget processes, particularly when thinking about opportunities for process automation, which is something that we talk about a lot, Chris and I. Because when businesses automate existing workflows without rethinking or redesigning,

they risk cementing inefficiencies rather than unlocking the full potential of automation. So using a systems thinking lens, we're going to explore some key patterns that reveal how this issue actually manifests in the real world and actually provide some real world examples to illustrate the problems and some possible solutions. So Chris, why do so many organizations fall into this set and forget trap?

Chris (01:04.354)

Well, I think it's an interesting one. And frankly, there are probably quite a few things going on here as ever. But you know, let's, let's try and unpack some of them. I guess ultimately, if I had to wrap it up into a single conclusion, it would be that it's a mindset thing. There's a book I really like written by someone we both know, the CEO of one of our tech partners, business called Wakato.

The book is called The New Automation Mindset, which perhaps unsurprisingly, given the title, really digs into that mindset point. To be fair, wrapped with a lot of great automation practice stuff as well. But I think one of the main outtakes from that perspective, at least, is that too many organizations have what they call in the book a task mindset, meaning they spend too much time down in the weeds of the problem.

don't kind of zoom out and see the big picture. And of course, I guess therefore the big opportunities that you get by, having that sort of system view of the world. I guess to some degree, this is really just complacency. know, typically, I guess most organizations lack any real impetus for sort of genuine transformation. And I think

part of this is because there's inevitably a lot of resistance when it comes to trying to change processes. And I guess that wins out if you don't have that driving force of really needing to deliver change. And a lot of organizations talk about digital transformation, perhaps a little less so now, don't know whether that's becoming a slightly unfashionable term, but in reality, the gains that are actually being made are not.

that significant. I think we've got an interesting perspective on this actually, because we do a lot of process design and kind of business process automation work. And you would think that we would get a lot of briefs that are about like proper digital transformation. And in the main we don't, you know, not not really, they might say that at the top of the briefing document. But, you know, the main driver of process automation typically is efficiency and

Chris (03:25.076)

that efficiency is viewed, at least at the start, in a fairly sort of static perspective when it comes to the processes that are being made more efficient. And, you know, it should be that, you know, what we see as results that are kind of stated as like desirable outcomes in briefs, at least initially are about

doing the same thing faster or with less people or simply just connecting point C to point D more efficiently than it was before. And very, very few take a genuinely open-minded view of just how can you do this thing better. Which I don't know whether there is a sort of human bias piece there where people write a brief, they're just sort of compelled to do a version of whatever's there because that's what's

easiest or what's obviously apparent or it doesn't seem like a good brief if you just leave a you know, could you just do this thing better? But

Colin (04:30.821)

guess the kind of dream brief here is that they're taking a blank sheet approach. Like if we had a blank sheet of paper and designed it from the ground up, what would it actually look like? But I think in my career, I've seen very, very, very few of those. So not just the time that I've spent working with you, Chris. So maybe it is a human nature thing. But I think actually being told, right, you have a blank sheet of paper, let's reimagine how this

Chris (04:51.342)

All

Colin (05:00.335)

business work, so this set of processes works, is actually quite a challenging task that involves getting a lot of stakeholders together and having a big argument around a whiteboard for probably a very long time. So think we start to get to some of the answers as to why this mindset problem exists.

Chris (05:16.524)

Yeah, I think also indeed. Yeah. mean, I think it's most companies don't make process design or indeed automation a strategic priority. And I guess when something isn't a priority, it very often lacks ownership within the org.

kind of when it lacks that sort of portfolio responsibility of someone senior, then there isn't necessarily going to be a strategic vision for where they're trying to get to that's actually held by all that's sort of commonly sort of understood. And that's not going to be driving any sort of an agenda. So I guess you get a lot of sort of anchoring into the status quo taking place because people don't necessarily have a remit to do anything else. You know, I think another factor is probably

And you sort of alluded to it a second ago is that doing things cross-functionally, like cross-functional collaboration around complex things is not an easy thing to kind of get off the ground. We explored this in an episode recently about alignment, really just multi-team alignment. were talking about sales and marketing broadly speaking, but I think it plays out everywhere.

is that it isn't easy getting a cross-functional process improvement project off the ground when it isn't a strategic priority being driven from above. And in most cases, think in reality, it's just actually not going to happen full stop. So you get this kind of inertia to change often, you know, I guess even when a lot of people can probably quite clearly see that something is maybe not broken, but certainly not as good as it could be. And that there's going to be a really clear benefit from a change, but it just doesn't have that.

ability to gain traction in the organization as a project and things just therefore stay the same. And I think, I think that inertia, you know, what I called earlier complacency, which is perhaps slightly unfair is, is really just the driver of that sort of, you know, set and forget, like set and forget is a phrase that's almost positioned as a benefit, but in reality, it's sort of, you know, set and try not to look at. I guess I'd

Chris (07:26.968)

probably call out another couple of issues if we're doing the full kind of audit here. Yeah, well, let's do it. So I would say what's driving this kind of set and forget mindset, and maybe this one particularly applies to automation projects, but simply most organizations don't invest in discovery around processes.

Colin (07:33.167)

We are.

Chris (07:51.726)

You know, they probably maybe if they're decent have a review process and like a change log for existing processes or whatever, but, that's not discovery. you know, that's not actually doing a proper analysis and answering questions like what would happen if we just ripped this up and started again, like those sort of questions aren't in scope in a change log in a process optimization process that, that, that even a decent business is going to have in place and most probably.

even have that around a lot of processes unless they're absolutely business critical. So ultimately just no one's asking the question. In fact, actually, I saw a stat recently published in a study that suggested that 80 % of automation opportunities in most orgs remain unidentified, not undelivered, but just simply unidentified. That just no one knows they're there because they haven't gone out and engaged with the right stakeholders and actually challenged some of that.

established thinking, challenge the status quo, know, traditional ways of working, call it what you want, no one's just had the remit to go in and say, what if? And I think that's a big problem that's actually holding back a lot of organizations when it comes to, not, mean, you say process transformation, it sounds boring. I mean, to reframe process transformation, you know, they're not looking at how we can make things better for customers, better for staff, more efficient, cheaper.

less irritating to deliver. mean, the tangible benefits of getting big processes right are many and various, and yet it's just seemingly too easy to brush under the carpet, I guess.

I know. I mean, I don't know whether you sort of think, I know that, you know, from your kind of experience in big automation places, I think you see a lot of these projects too. So I just think that centralized view just doesn't really exist.

Colin (09:54.469)

No, no, there's a sort of tension between the priorities of various lines of business. I kind of view the line of business heads as being a few, it's very easy to do if you live in the West of Scotland, actually. If you imagine a landscape, which is a bunch of valleys that are connected at certain points, but mostly aren't, and the line of business heads can see everything that's going on within their valley and maybe certain interconnection points between them and the other valleys. But.

But really they have their own set of priorities and their own value or guess silos as we refer to them. And then there's maybe there's a tension between that and some centralizing drive. But I've seen very little of us either internally candidly or externally as in projects coming in when I've worked in this space, which is really about a strategic automation mindset.

tends to be about fixing things. I think in our time working together, there's one organization that we're speaking to, which had a commitment to really discovering what all the processes in their business actually were. And this was a huge and messy task and I don't think it's finished yet and it's been quite a long time.

Chris (11:05.196)

yet.

Chris (11:12.714)

Yeah, but no, that's true. And actually, I think that's sort of what some people would call process mining. I think that probably is maybe getting a bit more traction than I gave it credit for, but it's very much in the fringes still. You know, it's not a mainstream activity, but by any stretch of the imagination. think you actually raise... Yeah, I think it will. I think it will increasingly as more things become mineable, i.e. they exist in the digital domain.

Colin (11:32.272)

I think it will be.

Chris (11:42.658)

then I think it will be because simply people will be able to sell solutions rather than having to do the hard yards. And you raised a really interesting point actually, which I didn't mention, which is, you know, that sort of values analogy is a good one. And I think that automation isn't necessarily a sort of...

purchasing category that's necessarily owned by IT. So I think you get a lot of decentralization in automation purchasing, particularly as like a lot of tools, CRMs, marketing automation platforms, whatever, have automation baked into them. So you get this really sort of decentralized view where automation capabilities are actually sat in the ownership of line of business. You know, roles like marketing, think particularly probably sit on quite a lot of the automation estate and

they're either underutilizing them because they don't have the capacity, resource, ability, whatever, to use them. Or maybe they are not underutilizing them, but they're only doing that through the sort of view of the valley of the silo that they're in, rather than having this kind of interdepartmental approach. And, know, as I'm sure we'll talk about as the episode continues, that's what you really need to have to do this effectively.

Colin (12:59.919)

Yeah. So I guess moving on to what we're all about on the growth system as normal, let's set it all in a systems context. And so what's actually going on from a systems thinking point of view?

Chris (13:14.432)

Okay, so there are quite a lot of ways into this one, because systems and processes are not exactly interchangeable. But certainly, one of the fundamental kind of tenants of systems thinking theory is an entity must have a process and an operand. So it's kind of got this element of process baked into it. But

I guess the best way to get into this is to really define the underlying problem behind the kind of static nature of most organizations processes. And I think that on reflection, this is probably rooted in feedback loops. In the systems world, we talk a lot about feedback loops, which aren't actually slightly confusingly about feedback in the sort of commonly understood sense. Feedback loops, which can be balancing, they slow stuff down, reinforcing, they speed stuff up.

can really be anything that has a material impact on the function of the system in question. And whatever the feedback, the reason most processes are fairly static is that the feedback simply isn't being received and acted on. And I think this is because most organizations fail to view processes as part of a sort of broader dynamic system that when

you view things holistically, like holism, we've talked about it a few times, right, you were not just trying to deconstruct. Then there are lots and lots of feedback loops waiting to be harnessed and understood. And these could be from loads of places, you know, from customers from sales performance stats, conversion rate stats, NPS scores, you know, whatever the list, the list is long.

And that's just thinking about the growth team as we are sort of, you know, brief to do here. But I think the job of whoever is running these processes is to draw a meaningful boundary around the problem and to take into account not just the sort of direct entities involved in the process, but the system context in which they sit. And I think that's a really, really key point here is that we might look at feedback

Chris (15:37.578)

in a very, very zoomed in sense on processes, you know, is the bit of the process I own, is that doing the KPI that has been set, you know, single datum point really in terms of is this thing working?

very, very seldom does anyone zoom out and even look about the whole process in terms of it, how it works end to end, you know, think about a customer journey through a through a business. I think that's a really, really good one to think about the context, the growth team, you know, they're touching stuff out in the dark funnel, you know, how are we capturing signals on that? Where are they going? How are they traveling through our marketing estate to become a first party data capture? You know, if they're becoming an opportunity, how's that being passed to sales? What does the sales process look like? What does the, you know, lead management process

process look like? What is the handover to pre-sales? And so it goes on. They're all so tempting to view those as sort of standalone processes, but the customer perspective is I'm just traveling from I didn't know you to I'm now spending money with you.

And that is a process, you know, that's a process that we call the customer journey, right? But no one actually thinks about it as a process. So thinking about those broader set of all the feedback loops that could be in there, you know, that is the big opportunity, I think. I think another big thing going on is this concept of reductionism that I kind of mentioned before.

there is such a drive, almost a sort of cultural imperative, I think, to try and break problems down into the smallest number of parts possible. It's like a normal thing to do. I don't think people even really question it. I think they probably think of it as a smart way to address problems, which I'm not saying it's intrinsically not a smart way to address problems. But of course, when you do this, you lose sight of the big picture. You know, you don't see the forest for the trees and

Chris (17:37.814)

that's an issue when we're talking about processes, particularly larger scale processes that touch things like a customer. So, you know, this is something that we're particularly prone to in the process design world is kind of where if we focus, as I was just kind of saying on one process or even one part of one process without taking into account the reality that most processes exist upstream and downstream from other related processes.

and the opportunity here is to deliver what some people might call whole system optimization. And when you do this kind of, you know, I guess we do the reverse when you do a sort of entity level localized optimization, then you've got a huge risk factor. that in sort of sticking in systems thinking world is that you give rise to a very common systems archetype, which is described as fixes that fail.

I guess as with most of these archetypes, they're pretty self explanatory. briefly, it's the scenario where successfully, and I do stress the word successfully fixing one thing in one part of the system has the unintended consequence of breaking something somewhere else in the broader system. It's what we sometimes call a second order effect.

And that actually the net impact of fixing the one thing you were trying to fix is that you actually have a net negative impact in overall system performance. So, you know, that is something that the more zoomed in you are in your decision making, the more kind of reductionist you are in your thinking about processes, the more likely you are to break things without realizing them in the wider system context. and that is

I don't know, perhaps that's a risk factor. Maybe people intrinsically kind of inherently know this so they don't change little things. I'm not sure, but in automation, although this isn't perhaps a literal interpretation of the fixes that fail archetype, I also think you can level a sort of criticism that actually just doing small fixes and sort of ignoring this big system wide changes that are potentially available to you.

Chris (19:57.71)

you kind of get a fixes that fail from an opportunity cost perspective, because you're spending time, you know, mucking about in the weeds when you should be looking at an entirely different problem with the resource that you're spending on it. So to sum up, guess, the systems thinking point of view is that set and forget as a problem arises because organizations treat processes in isolation. They

sort of don't really consider how they fit into the larger organizational ecosystem and automating particularly in inefficient processes really compounds that you sort of entrenched the existing problems rather than using automation as an opportunity to reimagine and optimize the system as a whole. it's, it's that sort of fighting against the reductionist view, you know, taking that system wide approach. You know, that's

you know, that's the opportunity.

Colin (20:58.545)

Yeah, I guess there needs to be. Someone or a function. Within organizing, I wouldn't be surprised if we started to see that sooner or later, especially after everyone hears the growth system and it sees the light. Where we might start to develop. Roles and functions, particularly within some of these complex enterprise organizations where this is the actual holistic focus.

Chris (21:16.792)

We can but hope.

Colin (21:27.953)

I'd like to see it happen, enemy.

Chris (21:30.356)

Absolutely. I think there's an interesting question about where that should actually sit as a role. Because I think when you come to process automation, there is a dichotomy at play that because it's really tempting to put a big lumpy bit of

automation, think we're talking specifically about automation here, not just process design, which isn't necessarily the same thing. But, you know, it's really tempting to stick that big IT investment with IT, because they're the guys that theoretically know how to run these things efficiently, they know how to do the governance. They maybe know how to write a little code if that's required. So it's a tempting place to put it. I think that we certainly see that

causing backlog issues, because whilst all of those things are true, you've got two things going on, which is those people in IT are being pulled at in million different directions from, you know, requirements all over the organization, and they're not the subject matter experts. So I think that that is, you know, a recipe for bottlenecks. I think

If we were to take a unsystematic view of the problem and think, well, within the growth team, the people I would want running the automation portfolio would be the rev ops team. because theoretically, if you have a proper rev ops team, they're transcending marketing, sales and service account management, you know, quote to cash, you know, all the way really to, to revenue. So in the growth team, they are a great person to run automation, but I think I would.

sort of increasingly starting to change my perspective on this. And actually, I think the true answer to nailing this down is actually through democratization of these resources. It's actually as things become increasingly no code, low code, that actually it's about creating a center of excellence within the organization for process design and automation as a sort of byproduct of that.

Chris (23:38.754)

Because if you put the right structures in place, you put the right governance in place, you put the right release procedures in place, and we could do a whole episode on, we probably should do a whole episode actually, I think that'd be quite interesting on sort of democratization of automation and sort of citizen automation, and there's lots of phrases for it. But I think if you can nail that bit, you can move so much faster and so much further.

by just putting more hands on the pump from the people that really know those processes. But you've just got to have that governance framework so you always got the zoomed out view. So I think that's, you know, that's a really tough one is how do you, as you say, how do you actually deliver this? Who actually delivers this effectively?

Colin (24:23.697)

So in the meantime, until such roles and functions exist in this dreamy future, what can we do now to practically guard against some of these issues, which again, like everything we covered on the growth system, seem to be endemic. I don't think I've worked anywhere that this wasn't a problem. Apart from the view, obviously.

Chris (24:51.025)

I think even here we are not without guilt in this respect. But nevertheless, I think to solve this, you need to take processes as dynamic parts of a larger system. You need to kind of reframe what a process is and ensuring that process automation requirements

are aligned with the entire system's evolving needs and goals. So how do you do that? I think in reality, you need to develop a kind of continuous improvement framework that sort of recognizes the interconnectedness of processes. It sort of embraces feedback loops.

It uses automation as a tool for sort of broader system optimization rather than as simply for like efficiency gains in isolated workflows. So I think a lot of it's about a reframe of like where process design sits, even if that's just in your head rather than within the org. But yeah, broadly speaking, I would say there are six parts.

would they be? So I would say that it's about leaning into systems mapping and using that as a springboard for reimagining processes. So we have a proprietary process, which we could spend a very boring episode talking about, so we shouldn't do that. ultimately, it's kind of like taking a three step approach to system mapping. So it is understanding what is going on now.

in as broad a view of the system as is sensible to map. that is about drawing the right boundaries and potentially then drawing multiple boundaries and doing the exercise multiple times and seeing the interfaces. ultimately mapping it as it is, is really, really key because so often, I would say almost always when we do this and we do this day in day out, almost certainly weekly on projects,

Chris (27:00.31)

It's the first time I think anyone's ever written this thing down and put it on a piece of paper. And you don't have to be an automation architect or an enterprise architect or even, you know, anything other than being vaguely familiar with the system. Once you stick this thing on a piece of paper, it actually becomes pretty obvious what the problems are. You just need to sort of do the hard yards in terms of writing them down.

We then deliver what we term an opportunity impact assessment. And that is about looking at that as is mapping of the system, whatever that system is, that process, and then say, okay, well, where can we...

you know, where are the problems that need to be solved? What are the likely solutions to those problems? How much effort and time is involved in fixing those problems? How much benefit is there to the business in fixing those things? So we would typically sort of implement a sort of scoring system, a sort of index of impact, which would enable us to identify where the fixes need to be. And that would drive a 2B map, which effectively is the build brief for the next thing, the re-imagining of what you're doing.

And when you do this mapping, it's really important to not just map the entities in the system, the sort of nodes in the process, however you want to describe them, but the gold is buried in the interconnections. You know, we've said this before, I think actually the very first episode, we talked about this a little bit. And when you map interconnections, it's really important to remember that interconnections have both form and function.

And what I mean by that is form can take many forms, funny enough. you know, it could be a API connection between two systems. could be a carrier pigeon. It could be, you know, two people stood in a room talking and exchanging information once a week.

Chris (29:03.27)

all of those things interconnections. So recognizing the form of the interconnection, the way that the information actually passes from point A to point B, that's really, really key. But also the function of that interconnection, what is it actually there to do? It might seem obvious and very often it is obvious, but if there's an API connector and it moves,

five fields, know, first name, last name, email address, whatever from system A to system B. Well, why is that actually happening? And I think that's a really, really important question to ask. Like what is that facilitating? Why was it put there in the first place? Does it actually need to happen at all? You know, process design can be deconstructionist as well as constructionist. You know, it's not about, it's not always additive. It can just be about taking the dead wood out. So why are these things happening? Why is this data passing form and function?

I think another thing when you're doing the mapping exercise is to really consider dependencies within the system, contingencies, you know, what, if something happens in step 27, you know, where did the data enter the process? Yeah. We need to make sure that we are understanding that there is a contingency between step three and step 27, you know, and I think that that's really, really important because then you can then also do things like if something entered at step three, what's it doing?

for the other 20, you know, 24 steps. Why is it there? Would it be more efficient for it to go from wherever it came to straight to step 27? So I think that's the sort of foundations of re-imagining processes. I think the final thing with system mapping is really just that point about drawing boundaries. Because when we...

design a process is really tempting to draw a boundary around the process and then ignore everything outside the boundary. As we've already talked about, the context in which the process operates is often as important as the process itself. So where are those interfaces with the outside world? Sometimes very literally, you know, if you're designing a lead management process, there's probably quite a lot of interfaces with, with, you know,

Chris (31:21.346)

tech stack that exists outside the sort of, you know, the city walls of the business, whether that's something coming in from Google or some other point system or a partner or whatever, you know, there's a lot of context to consider quite often. And I said that was the final point, actually, think probably thinking about it, the one thing I would think about actually, and thinking about the opportunity impact assessment is with our systems thinking hat still on.

Colin (31:42.085)

Ha ha.

Chris (31:51.872)

understanding what the system actually is doing, not just what it was supposed to do. So this is what we would call the emergent behavior of the system, because actually conducting a kind of variance analysis between what you thought it was going to do and what it's actually doing, and taking a view of what it's actually doing to not just be a sort of percentage of the intended output, like what else is it doing?

like, is it making people unhappy? Are the people that are responsible for tech 26 thinking about leaving their jobs because they just can't be asked to do this thing every day anymore? You know, just you could go on but but actually thinking about true emergent behavior, not just what pops out the other end. You know, that's that's really critical. So step one, you know, reimagining processes through systems mapping. So I think that

That for me is definitely a big part of this, is getting that initial focus on what's going on. Another sort of the next step, I guess, in this process, I'm starting to wish I hadn't started out by numbering because I'm trying to struggle to remember exactly what I was going to say here. But I would say information access. I was very enthusiastic five minutes ago.

Colin (33:06.513)

You were very self-emphatic about how many there were and everything I thought. He's really got it mapped out in his head here. Now you've led yourself on a merry dance.

Chris (33:18.67)

I sure have. Let's see how I do. can see how close I get to six. So information access, think, is another really big one in terms of building this kind of improvement framework, number two. continuous improvement is really a key objective of good kind of process improvement activities. And it would be really tempting, I think, to say that having switched on real-time data

Colin (33:25.841)

us too.

Chris (33:48.66)

that's going to be the facilitator of lots of continuous improvement. Continuous improvement implies we are going to continually be changing stuff that absolutely should not be the case. Making lots of small changes very quickly is typically a dreadful idea. It sounds like a great idea, know, we're always on the front foot, we're always optimizing, but experience tells us that the emergent behavior of systems is obviously often very delayed.

you it only actually reveals itself over time and that emergent behavior can be positive behaviors or it can be negative behaviors. And, and you kind of need to let the edge cases reveal themselves. we talk about this a lot in kind of automation architecture of not just designing for the happy past, you know, when everything goes right, you know, when every API call is returned and every field was filled in in the right formatting, it's, know, what happens when, you know, someone

wrote it all lowercase and backwards and didn't fill in this field and whatever else has happened. You you need to give it time to break almost so you can really understand the true performance. another thing, and it's not that we've talked about a lot before, but there's this concept of oscillation in systems that relates to delays. And the more quickly you change stuff,

the more likely you are to create oscillation. And oscillation typically is sort of negative in the sense that we just get this sort of bounce back effect. You we make a little change like the butterfly effect and, you know, a storm starts somewhere else. Well, it's kind of the same, I think, with process design. And we need to not, you know, do many two flaps of the wings before we really see what's happening in the system. I think another thing with this sort of

path to sort of continuous improvement is actually just never assuming anything's ever going to work as you intended it to. I think it always good, really is a good mindset to be in. It sounds flippant, you know, absolutely I say this frequently, speaking as a card carrying pessimist. I mean, the always monitoring that sort of broadest view of the system that you can sensibly track.

Colin (35:56.529)

pessimists never disappointed.

Chris (36:07.782)

and just looking for where it's going wrong. mean, ultimately, I think that's why we provide a lot of value to our customers is probably because we take that view of the world and therefore things that we build typically, I'm actually not going to say that, you know, things tend to work because you're putting the hard yards in. So let's try number three. I think I'm on track now. Number point three in kind of building this framework of how we do it properly is

Focusing on whole system optimization. I mentioned it earlier You know try not to have that task mindset Have a system mindset have a process mindset growth mindset people call it different things, but but ultimately have a mindset where you think about the system as a whole and Your intention when you start playing with the processes is to optimize the performance of the big system

not the small part of it or the bit where you see the problem. And that is, you know, I mentioned it earlier, I think it's really true. It's just like the change doesn't need to happen necessarily in the orgs doesn't need to be a role for this needs to change the mindset, like you need to change how you're thinking about solving problems. If step three and four are manual, don't just plug it with an automation. Or if you do just plug it with an automation, make sure you've zoomed right out and thought about what that means.

and crucially what it could mean and what was the opportunity cost of only thinking small. If we're taking that resource out, could we use that as an opportunity for a wider re-imagining? And being aware of those kind of second order effects. So having a broad view of measurement and collaborating with a lot of stakeholders system-wide when you're making changes, because ultimately that's gonna add insight and it's gonna remove risk because you're just gonna know more about what could happen and what has happened after you've done it.

So I think instead of sort of looking at automation as a means for improving individual tasks or processes, know, a systems thinking approach is thinking about that broad system view and looking kind of beyond the immediate games of fixing the little thing and thinking about fixing the big thing. Next up, I would go with sort of making sure that we build flexibility.

Chris (38:31.488)

into the processes that we are automating. Now this is so much easier than it used to be. But you know, a good, systems thinking first solution, I guess, is one that has a lot of flexibility for optimization. You know, it allows processes to be easily adjusted and kind of reconfigure as business needs evolve, as you learn more, as those second order effects kind of present themselves. So not so very long ago. I mean, you and I both remember it well.

Things like iPaaS tools where you just, you know, clicked some buttons and two systems connected to each other. That was fantasy land. Like there were, there were people that were hard to talk to that you had to explain what you wanted and why you wanted. And then code had to be written and deployed and hosted somewhere and tested and

Colin (39:16.923)

Probably had to hire the team to build the integration first and then wait a few months.

Chris (39:20.702)

Exactly that. Exactly that. and that created a lot of like rigid structures. created a lot of fragility in, the practices. It also created a massive disincentive to ever changing stuff. but, but nowadays by implementing, so we mentioned Wakato earlier, you we love Wakato. implementing a really good iPaaS tool, having a somewhat democratized use of it.

having that sort of system wide view means that straight away you can, not necessarily should, but you can go and change things really easily. You can really understand how it's working. You can debug them really easily. And taking that kind of agile view of how you fix processes, particularly with an automation lens on that problem, you know, that's a really, really important point. And I guess as a sort of extension of that point, I'm going to call this point five. I think that

It's really important to kind of identify the leverage points when you're building automation. You know, when you're actually doing that architecture at the start that we need to look at not before the architecture problem. You you think about how is system, you know, the data in system A going to end up in systems ed and what steps is it going to go through? It's actually thinking about the business problem that's trying to be solved.

and understanding the leverage points available to you within the systems landscape that are gonna most easily solve that problem. instead of kind of automating or designing processes indiscriminately, focus on the high leverage point areas where automation can produce the greatest impact on overall system performance and use that as the sort of foundational blocks of your enterprise architecture, of your solution architecture. Because...

Ultimately, you're going to get closer to those business goals faster if you take that view, not just on the data movement, but on the business impact. kind of having that holistic understanding of how processes are interconnected in a way which creates business value is where you're going to lead to those big improvements. also, and we've talked about this quite often, know, fixing systems is about identifying leverage points.

Chris (41:43.148)

If you identify those leverage points against the business requirements first, you know the levers to pull doesn't necessarily mean you're going to know which direction to pull the levers in any better straight away, but you certainly know where they are. You you've got the control panel and, taking that sort of improvement view that continuous improvement view, you know, you don't have to think about the problem too much at that point. You know, you can, you can start thinking about what the test program is going to be almost at the start.

And I think that's a really good way to kind of unlock positive emergent benefit.

Colin (42:17.969)

think if you do that, was going to, to interrupt because I was just thinking that if you follow this systems thinking approach, identifying the high leverage points and you execute on that well, presumably that's going to create a sort of virtuous circle where future holistic strategic automation efforts are going to be much easier to get stakeholders to buy into and the process keeps improving there.

Chris (42:20.714)

different.

Chris (42:47.426)

Yeah, thank you. Thank you for that because you've actually reminded me of what the point six was. So I've done it.

Colin (42:53.649)

I wouldn't be surprised if you decide that there's seven and that you actually called it wrong at the start. Well done, you've got to six.

Chris (42:57.742)

I think I'm out time now at this point. Yes, this was probably ill advised. You can tell that this is clearly isn't rehearsed as a podcast. So I think the final one is that stakeholder piece that you mentioned. It's involving those cross-functional teams to be part of that process re-imagination point. At the start, it's to have those people around the table when you identify the levers we were just talking about.

Colin (43:08.187)

Ha ha.

Chris (43:26.754)

because you're going to identify them so much quicker, you're going to get that sort of buy-in from cross-functional collaboration. You you're doing something not because of a top-down directive, but you're doing something in a way that genuinely involves those stakeholders because they're there in the architecture. You might not call it architecture because they're probably a line of business people that that's not going to be a meeting they're going to want to turn up to, but actually treating it from the perspective of problem solving, treating it

perspective of the levers, you know, that's a great way to, kind of view the world and view the problem solving process. And it's going to give you that best understanding of the system in its entirety, you know, the process in its entirety, the up and downstream effects, call them what you will. And it's going to help you identify the inefficiencies, you know, I talked in point one about the opportunity impact assessment. Well, the as is mapping is driven by a great conversation.

which gives you the leverage points to then talk about the opportunity impact assessment. Having that cross-functional view of that process is something that is going to give you a fantastic starting point to start doing your process design from, doing your automation design from. And I think perhaps as a final point, systems thinking teaches us that problems typically arise in silos. They arise when you allow

silos to exist. And, you know, you've got to get away from you've got to get out the silo, you know, you've got to get into that world of cross functional collaboration, you've got to get into that world of, you know, mapping and driving understanding and understanding where the levers are to really efficiently start delivering, you know, change, you know, meaningful change within the organization. And, and by having that human view, by having that collaborative view,

I think you can actually remove the inertia to change because you're not thinking about an SOP or a fragile set of automations that's got to be fixed. It sounds like a pain. sounds like an IT challenge. You're thinking about business value. You're thinking about where to pull the levers. And I think that's a much greater impetus for change because you are writing the business case in conversation.

Chris (45:47.522)

to go do it. And I think that's how you create a culture of transformation within the organization. So there we go.

Colin (45:54.129)

And you're confident still that there's six, yeah? Yeah, you don't want to add in another one or anything. So you're just telling me that you had that cold from the beginning. OK, and it amazes me that you managed to get through that last point without using the word alignment.

Chris (45:57.803)

I'd appreciate it.

No.

Chris (46:09.388)

I did, didn't I? Yes. Yeah, and there's always going to be some angry people out there if they printed out the bingo cards we talked about.

Colin (46:11.644)

This is a first.

Well, I've said it now, so the bingo card can be marked. We are actually close enough to time that I'm going to call it, unless you think that there is another, if there is a seventh, no, you're confident in sixth. I think we're to call it on time here and go to kind of final thoughts. I think you could probably do with a break after your six points there.

Chris (46:30.252)

Next.

Chris (46:39.106)

Mm-hmm.

Colin (46:43.082)

the risk of getting ideas above my station or maybe kind of go to my outtakes.

The big one for me that I think just not thought about enough, like all great ideas, seems really obvious when somebody says it to you, is that people aren't utilizing this tool of systems mapping. I think one of the things that really hit the nail on the head for me was when you said the problems, it becomes obvious what the problem is, diagnosis becomes very easy generally when we actually map out the system to understand the interconnections.

and we realize where the gold is. I by really thoroughly mapping out how the processes interact within the whole organization and not just within a silo, within your valley, I think we can really identify these leverage points, the best leverage point to have the most impact and kind of avoid that unintended consequences, butterfly effect from isolated changes.

Chris (47:46.562)

Mm-hmm.

Colin (47:47.169)

And that's a really interesting topic in itself to dive into. And I guess if you have that in line with a mentality that is about recognizing in advance the risks of automation without redesigning, like virtually every automation or probably more so integration projects, which are sometimes misnamed as automation projects.

It's very much in the kind of opposite mindset to this where like we have a process just now is manual, it's annoying. I feel like the pain enough to do something about it. So let's just automate that process. And then you lock in the inefficiency and possibly even sort of have a negative effect. So I think it's really important to kind of, again, it brings us back to this whole system optimization point that you were making.

And that, guess, brings me to something that you mentioned earlier on, which is about adopting the strategic approach to automation procurement. So just try to centralize or at least make it a cross-functional initiative to actually not have siloed solution. And you're right, I'm going to call it marketers here as well, or marketing departments here for having

endless sort of stream of technical debt built up from point-to-point connections that I've seen in the past. I don't always just have to get a dig in at marketers before I finish off. But yeah, I'm going to leave my final thoughts for there. Curious to know what your outtakes from this were.

Chris (49:20.418)

Yeah.

Chris (49:28.99)

Well, I just did a fairly long list, so I think perhaps I won't subject the listeners to another long list, but I would say just two general outtakes, which is when you are thinking about solving a process problem or process or doing a process improvement project, zoom out as far as makes sense and think about

what role does this process play in the broader stack of processes and what is the actual business purpose that is trying to be achieved there, particularly if that touches a customer, know, what is the customer imperative here and, you know, let that guide the process. And as a sort of related point is

Don't think about it as a technology or even a, you know, we are just purely talking about human processes here. You know, I do this, then I do that, which is, which is still absolutely fine. Automation is not the answer to everything. Then still absolutely think about it from a people and business problems perspective first and leave the, you know, sticks and boxes to somewhat further down the process. when you've really, really understood the problem at hand.

the benefits that are in prospect and use that as the jumping off point for starting to do that sort of mapping exercise that we discussed.

Colin (50:56.529)

Yeah, I think rather than simplifying things by being too reductionist, that type of mentality actually does kind of cut through the noise quite nicely. Well, I think we are just about at time. We are indeed. I'm going to call it the I think it's been a really rich topic. But for me, once again, it's really just opened up a whole bunch of other potential topics that we're going to have to dive into.

Chris (51:11.288)

Mm-hmm.

Colin (51:24.203)

on future sessions and in some cases maybe even get a guest or two on to chat about who knows.

Chris (51:30.936)

I hope you're taking notes of these extra things because I know I'm not.

Colin (51:36.017)

Yeah, yes. Well, that's pretty much all we've got time for for this week. The growth system is brought to you by RevSpace, an applied growth consultancy that connects B2B organizations with the future of growth, offering consultancy, education and applied delivery services. Don't forget to follow and rate the podcast. It really helps us to bring the content to wider audience. And we'd really appreciate a moment of your time to tell us what you think.

Thanks very much. See you again next week.

Chris (52:07.598)

Thanks for listening.