Colin (00:01.576)

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

Chris (00:08.514)

I'm Chris Bayless.

Colin (00:11.308)

And today we're going to move on with our exploration of the growth team operating system and the different dimensions. And today really getting into, I think, the practical backbone of how we get work done, the daily routines and processes that sort of keep your growth system engine humming along. And that's what we call workflows. Chris.

I think we all really know it probably goes without saying that sort of having getting this right workflows or you might say processes is important. I think typically at RevSpace when we start to work with organizations, it's hard to think of any that really in a good place. I think not just in my experience at RevSpace, but I think throughout my career, it's hard to think of an organization I've gone into where workflows are essentially in a good

when it comes to being well documented and well embedded and guess working as a whole system across the whole enterprise. Why is that do you think?

Chris (01:16.634)

Yeah, I think it's a great question because when we talk about processes not being in a great place or documentation not being in a good place, certainly.

In reality, that doesn't necessarily mean that there aren't documented processes. It just certainly means that the majority of the time they don't actually represent the reality of how work gets done. And the reasons for this, I think you could probably view in systems thinking terms because workflows can be viewed as what we might call the sort of socio-technical fabric of the business. And what I mean by that is they are

the intersection point of kind of human interaction, technology, and to a significant extent, organizational culture woven together into, you know, how we do things around here, how this thing happens within the organization. So they're sort of an intertwined ecosystem of daily operations. And

to work effectively, all of these elements have to be well aligned. So people need to understand their roles, the tech stack needs to be integrated, the culture needs to sort of support.

not just something like continuous learning, but but actually needs to support even having a culture that follows processes that doesn't cut corners that, you know, depends on documentation, actually that that sort of cultural view of actually how we do things is key. And

Chris (02:48.994)

when you do get it right, you get a sort of self reinforcing cycle of efficiency, you know, collaboration, maybe, but in reality, documenting all of those things is bloody difficult.

you're not likely to get that in a nice AI process flow of how to do this thing. And to be fair, neither do you have to have help culture support the processes, the market process documentation. That would be somewhat overblown. But actually, the fact that

it exists and it is a component there means that it has a significant bias on how things actually get done. So that is the problem that we see is that someone might put a process in a draw if it's a key thing and no one will reference it and the culture probably isn't that we have to be, you know, that specific, you know, we're perhaps not in a regulatory environment and therefore things just evolve and they adapt and

you could say to a certain extent, so should they, but then this doesn't get reflected back and therefore you don't have this ability to transfer the knowledge, know, things get learned by rote. And that is problematic. Certainly it's problematic from the view of the system designer. So yeah, I think really in a nutshell, there is a complexity in how you actually document something that is that multifaceted.

And I think the sort of related issue, if you like, is that it's really, easy to see workflow design, process designs, and static exercise. systems are really just, well, one of the definitions of a system is a process and an operand. So processes really are integral to systems. And as we've talked about many, many times before, businesses are complex adaptive systems.

Chris (04:43.93)

So they respond and change over time to signals, they change to feedback, they change to system constraints, and they form their own sort of patterns of emergent behavior, something we've talked about a lot, of emergence. And again, this sort of adaptive nature, combined with the sort of multifaceted nature of what they are in the first place means that they are inherently kind of organic, they don't really lend themselves to being written down.

So there is a sort of paradox, I guess, with processes that mean that something that really needs to be written down is almost impossible to do so in an up-to-the-minute way. Which maybe we could just end the episode there, yeah.

Colin (05:26.094)

Short episode this week, So I guess then we have to sort of think about where we, as you seem to say every day, think about where we draw the system boundary to make sure that we kind of are at least giving some shape to the problem, something so we know where to start effectively.

Chris (05:41.041)

Yeah.

Chris (05:53.618)

Yeah, absolutely. think the sort of local to global relationship of kind of processes is integral to the work that we do. Because if we have a sales process, probably the most common process that's in any organization and almost every organization will have their sales process written down in some way, shape or form.

but it is inherently something with like a sales process and inherently have a very, very tight boundary. How do sellers use the CRM to document and manage how they engage with prospects and turn them into customers? And for anyone that's read the sales process, that feels probably complex enough just to get that right.

But of course that that very local view that tight system boundary has a huge global impact across the organization. There are so many interfacing teams that kind of touch a sales process or are impacted by a sales process. You know how marketing handoff leads, you know, that is a sort of interface point, I guess, with a different set of processes.

But more so than just the interface, what is coming through that interface? Does that actually support the sales process? Is sales getting what they need from marketing?

How are we onboarding? How are we giving visibility to delivery teams? How are we engaging pre-sales if you have that? How are we scheduling resource downstream? Are we actually getting the right fit customers through that don't churn, that don't impact our numbers later? I could go on and on and on, but fundamentally the sales process is the linchpin to a great many things, and yet it's inherently a very local process. So I think recognizing that kind of...

Chris (07:52.504)

upstream and downstream effects. You know, that's a really, really critical component of effective kind of workflow design.

Colin (08:02.222)

I've noticed in particularly in sort of early stage, sort of SaaS startups that I've been involved with where in that early kind of grow at all costs, that they grow rapidly phase, the sales process or sales processes even tend to kind of bend around whatever it takes to secure the account that you want.

Chris (08:17.074)

You

Colin (08:31.148)

And what you end up as you get to that point where the organization is trying to scale is that you have lot of various disjointed processes that are essentially unique to each account. And that's of grown out of essentially some fairly ad hoc sales processes at the kind of start of the company. And this is having this ripple effect that essentially is a problem that needs to be solved before the organization can.

can really scale effectively. So it's something that I've, I guess, kind of seen firsthand. I'm also thinking about, well, I'm kind of understanding the big picture here, but I'm thinking, this is me at my own company. And I was thinking, I was listening to this and thinking, great. My next question would be, where do I actually start? Like, where do you sort of identify or how do you identify the biggest sort of friction point?

Chris (09:06.31)

Hmm.

Colin (09:29.166)

that prevent that sort of alignment of daily workflows between, say for example, different teams. Like in my experience, the friction points have been around the sales process, but maybe when it comes to handing over to success or account management teams, or actually when there's been some internal churn, like an account manager is changing or something like that as well. But yeah, where do you see these sort of friction points and

Chris (09:52.955)

Mm-hmm.

Colin (09:59.02)

sort of ways to diagnose, I guess, the problems and where to start.

Chris (10:04.594)

Well, think it wasn't what I was planning to say, you just sort of say, when an account manager leaves and, my God, is that when you know how good your processes are, when you have that sort of linchpin person in one team or one part of the organization leaves and everything, you know, is humming around them properly. You don't think about that part of the org, they're high performing and then suddenly one person leaves and the whole house of cards falls over. that's when you know when you've got it wrong.

because it was just all, you just had a single point of failure within the organization and that all of that sort of inherent understanding of how to get things done leaves with the individual. And that's obviously a disaster, that's a risk factor that needs to be identified. And it's a really key thing, think, in understanding, okay, well, how do you do things properly?

But ultimately, guess more broadly, and that's probably to more specifically answer your question. The one big pitfall that we always see is that even in organizations that consider themselves to be quite good at processes, standard operating procedures, whatever they might want to call them, they get created in silos. know, silos, silos, silos. We bang on about it all the time.

But of course, it's just pervasive. If you have an organization that promotes silos, everything is in silos. Technology is in silos, processes are in silos, targets and goals are in silos, all the stuff we talk about. And you feel it because everybody does a good job at doing what they think is right within the walls of their own castle.

It's only when you look at processes that have global effect, like anything that touches a customer, which, in, you know, certainly for the listeners of this podcast will be almost everything.

Chris (12:07.122)

Yeah, that's when you have problems because you're not designing interfaces. You don't have that 360 understanding of what else is going on. don't know what data is being captured. And sure, you might have an alignment meeting, or you might talk about a handoff, or you might spend an hour working out who needs what from where. But that's not the same as having a truly

unified understanding of the customer experience and actually designing an end-to-end process. And that is really our rallying cry always is just, you know, break down the walls because everything good comes when you do that.

Colin (12:52.366)

Yeah, so what I was hoping to get into in a little bit, I think I perhaps derailed us a little bit there, but what I was kind of hoping to get into is about more about the sort of diagnosis area. how do we know where these friction points are and where we have and identify and prioritize leverage points where we can actually do something about this? Presuming we're not just

Chris (13:19.794)

Okay.

Colin (13:21.876)

starting up a greenfield startup where we can design this from the ground up. Typically we're going into an organization where the situation as you described is the norm.

Chris (13:33.626)

Yeah, well, I mean, that's really when we get into the type of stuff that we spend a lot of our days doing. And the first step, I think, in discovery, certainly when it comes to workflow design, but I think more broadly speaking, everything.

that relates to the sort of formation of a system and ultimately therefore the optimization of a system is what we call as is mapping, as I'm sure most people call as is mapping. And really that is the Ron seal of project stage names. It is getting in and just working out what's going on now. And in most cases,

putting it down on a piece of paper for the first time. And that's a really, really interesting part of the journey because it is at that point when actually you don't need us. don't need some hot shot consultancy to tell you what's going wrong. You just stick it down a big bit of paper and you're like, well that doesn't work, it? And it's pretty bleedingly obvious that...

that when you've done these five steps and actually they don't line up at all and you're asking different things to the same people, or worse, you're asking the same thing to the same people over and over again, or you're not capturing key bits of information, or you're making assumptions based on something that could have been declared earlier on.

And it's all just fairly obvious at that point, not always and not always in its entirety. And what to do about it is something else. But actually the problems tend to present themselves quite clearly when you get into that sort of putting it down that has his mapping phase. And what is really key in that particular phase is not putting on a big chart what is

Chris (15:33.238)

on the random bits of paper and in the files and folders that bats fly out of when you open them. It is understanding what is actually going on in the organization. is mapping the real on the ground reality of how that process happens within the organization. So we do that.

by interviewing individual sort of teams, small teams of the org, kind of collecting that together and going through an exercise and really drilling down and making them tell you what happens, not refer you to a document and actually mapping that in front of them and doing that on a board or on a wall or whatever, a mirror increasingly these days. And, you know, that's really interesting typically because you tend to then see, as I say, what's going on.

in a way that has not been seen by anyone in that organization before felt, yes, you know, everyone puts it down there. yeah, well, that's why that's always difficult. That's why that always takes an age or whatever it might be. But you undercover the real process and you do that and through my interviewing frontline employees, you know, if necessary shadowing them, not something that we tend to do a lot, but I can certainly see scenarios where that might be the most appropriate way of doing it.

And you can at that point do an alignment check, you know, how many of those bits were documented and how far off the existing documentation that the business thought it was running to, know, what is the sort of divergence from that? And you can then see, as I said, the main friction points pretty clearly. You know, you can see that is marketing handing stuff over, you know, that it thinks is qualified, that's actually nothing of the sort, you know.

Is there a huge backlogs building up in kind of, know, MQL processing in sales? You know, is stuff when that's handed over to delivery, you know, are they having to basically go through an onboarding questionnaire that re asks every single thing that they've already told the, you know, the AE during the sales process, because it wasn't adequately written down anywhere, or it wasn't integrated from CRM into the, you know, job management system or whatever it is that you're doing and whatever your business is. And

Chris (17:53.586)

I guess really the of the key insight here is that undocumented processes learned by rote transferred imperfectly from person to person are tend to be the root, you know, the small signal, the quiet signal that ripples outwards to create misalignment. And you tend to be able to spot it in that as is phase. And

What you also observe doing that time and time again is that no one wants it to be like that. No one thought it was like that. Everyone thought it was fine. Everyone thought that we were okay. We thought we had good processes. But actually when you work out what's really happening in the organization, very often it's quite far from that accepted truth. And getting people to get into that process is often the trick because they don't, what do they say in Alcoholics Anonymous? The first step is admitting you've got a problem.

I think that's often true when it comes to process design.

Colin (18:54.606)

think that's one of the hard things as well for me trying to open up conversations with revenue leaders about this sort of area as it's something they don't really want to generally admit that they have a problem with even though literally all of them do. Perhaps we should just have a support group or maybe that's what we're doing now. So something that came out when you were speaking there Chris, I was thinking about, know, still thinking about this question of how do we

Chris (19:12.496)

Yeah.

Colin (19:24.622)

prioritize? How do we figure out where the opportunities are, where the potential leverage points are, where we can make changes and positively affect things? And something that came out from what you were saying was, see if you agree with this, it tends to be around the interconnections in the system. Like my example where it's a handover to an account manager or success or something like that. So first

Kind of two part question, guess, like, do you agree is that what you see as well? And second of all, once we've kind of identified and sort of pinpointed those areas for those leverage points that would be good, you know, particularly impactful to try and affect, how do we actually translate that into sort of well designed embedded holistic workflows that...

will actually be sort of adopted and owned and positively impact things.

Yeah, yeah, should have broken that down actually.

Chris (20:39.802)

I think that the first part, absolutely. The, the interconnections tend to be where the problems are deepest and darkest because they are undocumented. the documented process, the things that people do every day, there can be problems with them. You know, you can have that key team and believe in it all falls over, but fundamentally work is getting done. But those processes efficiently or inefficiently are getting the organization more or less where

to go most of the time when viewed in that very local, you know, through that very local lens, through that very tight system boundary. It is only when you zoom out and see the interfaces between processes, which often are the interfaces between teams, where you realise that things are not as rosy as you would like them to be. And that is, yeah, it's such...

a huge issue because it's not just about how efficiently something's making it from team A to team B or from process A to process B. The inefficiency and the friction created in those interfaces are like tectonic plates. They rub and they rub and they rub and then they blow up and they deepen the silos because they drive

sort of factions within the organization. This isn't working because of them. We do a great job and we throw it into the abyss and when it comes out the other side, they just mess it up. And I think that that is so common that these kind of small points of friction can explode into far bigger issues that have go far beyond the measured efficiency of one data point, whether that is a customer or a

you know, whatever traveling from process A to process B. So, so definitely interfaces, interconnections are the problem in a great many cases. What do we do about that? I think was probably the second part of question. You know, that that's an interesting one. You know, when we see inefficiencies,

Colin (22:44.216)

Yeah, yeah, yeah.

Chris (22:55.898)

You know, the sort of impulse that you've got is then to just immediately plug them and to do things like Chuck automation at them or, to build integrations. and I get it, you know, we have an automation and practice within our organization. am a great believer in integration and automation, and the sort of democratization of those tools within the org.

However, the problem of just doing that is that you tend to just mechanize an inefficient process. when you look at, and I sort of perhaps talk about this more broadly than just process design and actually talk about automation design is,

it's really, easy to say, okay, well, actually, everything works fine up to point C, and then, you know, something goes wrong between C and D, or a person is manually doing something between C and D. So let's just integrate point C and D, and then everything will be great. And, and actually, you then lose the opportunity to optimize the entire process to, to actually look at the underlying

structure of the process itself and understand what is broken, what is unnecessary, you know, what is a symptom of a system we had 10 years ago and actually don't have anymore but we still do things in that way or whatever silly thing it is that tends to just happen because no one's documented it so no one's really thought about it. So you really risk scaling the dysfunction, you you add a point of failure, sort of

We've talked a lot about fragility in the last couple of episodes. And if you do that, you just kind of bridge the gap, then you just entrench the problem and you make it harder to fix later because there's a perception that it has been fixed and therefore the budget and the time and the effort is not released by the organisation again to relook at it.

Chris (24:55.73)

So I think that my generic answer, and I think we'll go into some more detailed answers as we go, is actually to look at the whole thing holistically and to not have anything off the table when it comes to how you might reinvent it.

Colin (25:13.806)

wonder to what extent you think that this phase where we're sort of designing the 2B state, where there is a risk of

planning something that's maybe unachievable. There's a potential for a gap between strategy and reality effectively. It might be worth saying a bit about how we manage that and minimize that gap, I guess.

Chris (25:48.944)

Yeah, that's a really, really interesting point because when you get into an exercise like this, the temptation is to want the best possible workflow that is possible to imagine. And very often that's not as simple as just saying, okay, well, you know, we're going to put something in a process flow and these 14 members are going to follow it. It typically means we're going to embed

some tooling, we're going to buy some software, we're going to integrate that software better, we're going to onboard an ipad tool to stitch it all together, we're going to drive automation, we're going to do whatever it is, essentially these of projects tend to have a sort of technical component to them.

then you are at risk of getting that sort of aspiration to reality gap showing itself because it's easy if you're not careful to build something that is over engineered, is unmaintainable, that is not understood by the people on the ground, that creates a sort of black box even if you build the box.

it often depends a lot on engineering resource and therefore it really really depends on having established a really deep understanding of the problem at a sort of domain expertise level to then bake something in. If you haven't done that then what you can do is spend a lot of time and money baking in a process that's no good, that no one knows how to change or to fix because you spend a lot of money with engineering consultancy. So I think that really the first step is making sure that you are

really, really clear on what you are trying to achieve. And crucially, not just what you're trying to achieve at a local level, but what you're trying to achieve at a global level. So, you know, we believe is certainly in kind of trying to align everything we're doing around system design to the sort of purpose of the organization and to those sort of North Star metric or metrics that you might have established as part of the overall project flow.

Chris (27:59.634)

And if you are prioritizing a certain number of, let's say meetings booked within a quarter and you're looking at the sales process maybe, then you're gonna want to make sure that whatever you build,

is actually going to align to that objective. So you need to be looking more broadly about how is data flowing into the system? How much in the way of content follow ups and sort of ebook downloads is the sales team having to do? What are the processes for doing that? How much of that is automated? What messaging are we using? How are we asking people to do stuff? Do we have multiple workflows happening at the same time where we've got maybe

an inbound stream but we've also got a higher intent stream, we've maybe got an outbound stream, we've got an abm focus stream, whatever it might be, but you how are you prioritizing, is that actually getting you where you need to go, if we're building a sort of process for growth.

if you like, we're building a sort of strategy, which has a lot of processes wrapped up into it, you know, how are we managing inbound leads, how are we managing the SDR team, how are we remunerating them, etc, etc, etc. Does that actually get us where we need to go? And it's very, very difficult to

sometimes when you're down in the weeds of trying to build processes to actually pop up and helicopter out and say, are we actually still traveling in the right direction? So aligning things to the sort of North Star of what the organization's actually trying to achieve is really key when we're getting into that sort of 2B piece. Is this actually serving the purpose that we intended it to serve? And I think that when we're kind of looking at particularly sort of bridging that sort of strategy to reality gap,

Chris (29:57.098)

feasibility of course is a big part of that. So once we've orientated it towards is it going where we actually want it to go, then are we actually designing something? Are we building something someone can actually drive? So getting in that sort of marketing automation process design example I was sort of laboring for a moment ago, well,

Actually, if we're like, okay, well, to enable us to do that, then we need to get an intent tool in and maybe we were going to buy Bombora and we need a LinkedIn automation tool and we need that to integrate with our CRM and we've got HubSpot sales enterprise. So we've got our sequence automation in there and we're using Cognizm for our data. then, you know, and actually at this point, well, A, can we afford all these many pieces of SaaS?

Do we actually have the capability to effectively integrate them? Do we have a well enough optimized view of how we're actually winning? And what I mean by that is it's all well and good sticking something down on paper about what your process is gonna be. But if you don't know it's actually gonna work then.

don't spend a whole bunch of time and money automating that to death and getting everything stitched together only to realize that actually it was a stupid plan in the first place. So, you know, are we actually building something that is already proven to work? And, you know, I think that sort of resource reality, technology, staff skill sets, budgets, you know, whatever they might be, you know, does that actually work? A big one that actually I haven't mentioned, which I would say is the

most overlooked and most impactful sort of strategy to reality gap is do we actually have time to do this thing that we've designed? Because and and therefore have you actually told everyone that was already really busy before you've built this thing what they're not going to be doing anymore? Because if you haven't...

Colin (32:00.43)

Well, this is what we're going to get to. The actual people who execute, you know, I've more often been on the side where, you know, everyone's executing the particular processes every day at work, right? Like everyone, I've been more involved in that actual daily execution than the process design phase. And I've seen some initiatives around designing new processes that are very well-intentioned fail because there's just not the buy-in from

the stakeholders, the people who actually execute the process daily, you just hear on the grapevine that we're doing things a different way and everyone's got a different sort of, there's an inconsistency in the messaging. Like nobody's quite sure how we do the new process or exactly what it is that we don't do anymore. you know, it's not really been, we haven't had that sort of collaborative workshop part of the process, I guess, where we're sort of...

Chris (32:47.121)

Yeah.

Colin (32:59.95)

all agreeing on who's responsible for what now and what's going to change and crucially what we're not going to do. And I think that's the biggest source of friction and finger pointing and general failure of these sorts of initiatives that I've seen.

Chris (33:16.816)

Yes, absolutely. I saw a really good one quite recently. It was with a customer, but I won't name any names. They developed a new onboarding program for their customers and they really wanted to prioritize.

sort of, essentially, they were trying to get great reviews, they were trying to build advocacy within their customers, they really want to take care of people through the onboarding process to their product. And it was all made so much sense on paper. And they put together this kind of intensive 30 bay plan where, you know, essentially, someone was going to have their hand held through the entire onboarding process. And then at the end, they were like, okay,

to say how many new customers are we onboarding? How many hours is that going to be every week? And they hadn't actually quite figured out that the one person they had working in success wasn't actually going to be able to do this. you were like, okay, so, you know, great idea.

great execution to the extent that it was a beautifully put together plan, know, on point in terms of the alignment to their North Star metric and wanting to deliver incredible customer experiences and get people to get value from their product really quickly and get really fast time to first value. Failed at the last hurdle, which is they couldn't actually roll it out until they hired some people.

And, you know, that therefore that sort of quite boring resource alignment piece we were just talking about strategy to reality gap. You know, it's out there in real life and it's waiting to bite you if you don't get it right.

Colin (35:07.246)

So I think there's a tension here as well, just to kind of, I think we could probably get bogged down in amusing anecdotes about, or perhaps not so amusing anecdotes about this going wrong, Now, I think there's a tension between the taking a holistic view, which of course the systems think as we obviously have to do, that sort of comes with the territory and the fact that we maybe can't,

transform every process across the whole enterprise in one goal. We have to zoom in on an area, create a sort of controlled group, if you like, to focus on a specific product line or function or a specific region and kind of sort of test and learn from what we're doing there. I've also seen efforts at sort of big bang transformation, which again,

typically, perhaps less often, but typically sort of failing and perhaps there's an issue of the scale and scope. So there's a sort of tension between being holistic and yet needing to find a specific area to focus on really to make it achievable and deliverable and something that you can actually give yourself time to analyse and learn from.

Chris (36:24.891)

Yeah.

Chris (36:31.842)

Absolutely. think this kind of is such a sort of cautionary tale really, because it's so tempting when you've designed the shiny new thing, you just want everyone to use it straight away and like, why are we doing the old thing? You know, bang, let's just get everyone going. And I remember speaking to someone that actually runs another consultancy, and they had a very, very large

technology client, you know, sort of well, maybe not a household name, but certainly if you work in the tech industry, someone you would instantly have heard of. And they were telling me that they designed a new ABM program for them. In they had designed an ABM program. They weren't currently using ABM. And they had something like, I can't remember, it's probably not important for the story, but they had a couple of hundred key accounts. And they had, I think, 100 AEs.

maybe a little less, but they're each running a couple of heads. They're all big seven figure accounts. And they decided, okay, bang. And then they just decided, okay, like next Monday, we're switching ABM on and we're rolling out across all 200 accounts, all 100 AEs and it's just switching on. And unbelievably, they did actually make it work and well done to my...

know, acquaintance there for actually making that happen. I think it took about 10 years off their life making it work. but you know, that is the absolute archetypal kind of example where doing a pilot is absolutely the right way to go, you know, stick it into one team, one little pod, one cluster of people, you know, a couple of accounts.

debug the process, make it work for your organization, get the comparative metrics, know, take it as the opportunity to build a business case, doing it the new way, you know, achieves X when continually doing it the old way only achieves Y. You know, give yourself the head of steam that you need to then do the bigger bang rollout comes easier to embed. And I think that that is really the key here.

Chris (38:36.046)

is it's not about how good your process is and it's not about how much money you've got. It's actually these things live and die in your ability to actually take the human beings in your organization along with you and get them to adopt it and to, you know, really.

embed it into their day-to-day, to put it in part of their sort mental model of how we do work. And that is the big thing. And that sort of change in adoption process, training and reinforcement, it what you will, that is the true battleground in embedding new processes and designing to the 2B system.

Colin (39:21.688)

So just.

I'm thinking about my experiences of some very well-intentioned initiatives around this in organizations I've worked for. not naming any names. It's no point in naming names because it's actually ubiquitous as far as I can see where we... A new process is kind of made official. Maybe there's some documentation. We have a training session, possibly more than one training session, possibly something recurring until everyone realizes there's not...

having the effect and gradually gets out of it. But there tends to be a culture of resistance to process adoption rather than a culture of positive new process adoption. a lot of organizations have been in, particularly this is probably biased towards sales. Sorry guys, nobody likes to talk about this. where the sales...

The sales process or processes that salespeople have to engage with are seen as a hindrance, almost like it's part of the game, like a blocker in your way to getting done what you need to do, i.e. selling and generating revenues. It's just like, this almost like it would be easier if it wasn't for the process as it is. You know, if you have some sort of like quality control that determines whether or not

a particular sales opportunity, a deal you're working on, is the right fit for the organization, which I guess in thinking about the whole system as a system, that makes sense. But to the salesperson, of course, they nicknamed that department, you know, the sales prevention unit or something like that. Right. Where do you do you work in sales prevention? might say sometimes it might be sales ops, someone like that deals with that.

Chris (40:55.42)

So.

Chris (41:06.044)

Good job.

Colin (41:13.92)

So there's this view of kind of like almost like the official process is kind of like the bad guy, the man, something that you just need to work around as an unfortunate fact of life rather than the sales process having the potential to be something which is a great enabler of getting done what you need to do. And I think that creating that cultural shift is quite a challenge in itself in a lot of organizations.

Chris (41:30.052)

Chris (41:39.698)

Definitely. And, you know, as you were saying, now I just Googled something because it's like getting people to break a habit. So I just Googled it. How long does it actually take to break a habit? Apparently according to Gemini 18 to 254 days, but an average of 66. But I would say that roughly accords to

to kind of my experience, is the first 90 days of rolling out something big or critical, because the first 90 days is when you get that sort of drift back happening, you get that resistance, you get that organisational inertia, and you've got to overcome it, and you've got to nail it down, you've got to do it right. And if you get through that first 90 days and people are still towing the line, the chances are you're going to get that to work properly.

But if you let it drift in the first 90 days, then the chance of it going up in flames are fairly considerable. And I think that's.

Colin (42:32.152)

sustained the course for that 90 days that's the challenge though isn't it because I've certainly been in organizations where there's this there's a quiet conspiracy I would say in some cases to just like if we ignore this for long enough it will go away and I think you know sorry everyone for busting out that secret nobody really talks about it but that's effectively what's

Chris (42:36.859)

Exactly.

Chris (42:50.054)

Thanks,

Chris (42:58.482)

Absolutely. Now we've got about five minutes left, maybe six if we're generous, because we promised we would come in on time to this week. So where are we going to go from here?

Colin (43:11.576)

think it would be good to have a talk about, and I know I keep coming back to this and trying to draw a system boundary. I think it's, I'm thinking about first of all, how do we diagnose, you know, and select the rights of leverage points where we can positively affect things.

Chris (43:19.378)

You

Colin (43:35.224)

Do you think we've said enough about automation and sort of how to strategically select targets for automation? I think you've said a little bit about what to not do around automation. Maybe we should say a bit about what to do. And then that's probably all I've got time for. And we should probably wrap up the general theme of workflows.

Chris (43:55.34)

Sounds good to me. I also suspect we probably do a second episode on this and and still carry on talking about stuff. I know maybe we should take that offline. Maybe we should do a two-parter but let's talk about automation, one of my favorite topics. Automation can be a great way of adding huge amounts of value into an organization but

As you say, you've got to work out where best to sort of apply the medicine, because just automating things that were rubbish in the first place and just making them, you know, rubbish, but difficult to change, that is not a value add. So you've got to really consider, you know, where it's going to be a multiplier. And for me, there are a few things that you've got to look at.

The first and most obvious ones, I think we have to mention, albeit I'm not actually the greatest advocate of these. So what everyone tends to look at is where do humans add the least value?

I for which typically read where is there a human being that is typing something from one screen into another screen? You know, where is there a piece of data that is terminating that it would nice to be if it was somewhere else? You know, those are all good. They are often really good candidates for automation.

But very, very often, if the process was that rubbish in the first place that you have got someone that's typing something from one screen into another screen, the whole process is probably ripe for reinvention. And that, think, is a great truism that if you've got a 10-step process and you're trying to link step seven and eight,

Chris (45:51.012)

you need to be thinking about it like the space-time continuum. You need to be thinking about processes as being bendy rather than linear. So what I mean by that is, actually, if you looked at the whole thing, and rather than going from step one to step two to step three to step four to step five to step six, and then getting stuck, and then having someone having to get it to step seven and on it continues, can you actually just get it from step one to step two and then straight to step 10?

because actually you can redesign the process in such a way and leverage different tooling, leverage automation in a different way that you can actually reimagine the process, not just automate the process. And I think that's a really, really key thing for me. So checking if the underlying process is poorly defined is absolutely the first thing to look at when someone says, can we just do this thing where someone's typing something in or we've just got this kind of point of human

intervention that shouldn't be there. So I think that is absolutely a way of looking at it. The next thing that generally comes to us as a need for automation, and this one typically is quite a good use case, is where have we got something that's very, very high frequency, repetitive, happening that's prone to human error. So this is typically

a very high value leverage point when you've got this going on. And actually not due to the high frequency and repetitive bit is the human error bit. we built a billing process for a customer a couple of years ago. And straight away, their billings went up by about 20 to 30 grand a month.

And they were like, Ooh, there must be something wrong with it. Like we're over billing people. And actually what it turned out was because they had a manual step before they had a line item for account management that was on some contracts and not on others. And, when, and they had their AM team do the billing and they basically just never added that that was in the contract to anyone's bill.

Colin (47:41.55)

You

Colin (47:58.446)

So this is just revenue just leaking.

Chris (48:00.386)

just and for years and years and years and their problem was then actually then going back to the end users saying we just haven't actually built you this for the last you know two years but but we you did sign the contract and that is the thing but that you know that was that was a different problem but but you know straight away that that human error element because processes learned by rote let's say two things going on there

Colin (48:15.886)

Hmm.

Chris (48:25.828)

Someone probably made an error right at the start where they hadn't read the documentation properly of however their manual process worked. And then they hadn't added the line and then they just done it from memory every month since then. So actually even.

Colin (48:39.64)

So there's a great case for automation. Yeah, the human in the loop is the problem there. So I guess you need to see where do humans add the least value or where do humans potentially subtract value? I mean, in this case, really from the bottom line. And I guess another way to think about it is where do we really need humans in the loop? That's where we don't automate.

Chris (48:58.064)

Yeah, absolutely.

Yes, absolutely that. So I think that probably is about all we've got time for. I think if any of any of any episode ever deserved a two part or it's possibly this one. So, you know, we'll chat about that. But maybe back with more workflows next week, maybe in a future episode, we'll work it out.

Colin (49:19.438)

Yeah, I've got no doubt that we will certainly return to automation. Unfortunately, that is all we have time for. We're on a tight schedule this week, folks. So thanks very much for listening. If indeed you have listened this far, the Growth System is brought to you by RevSpace. That's us. We're a growth systems consultancy. We connect B2B organizations with the future of growth and offer consultancy, education, and applied delivery services.

Please don't forget to follow and rate the podcast. It really helps us to bring the content to a wider audience. And as always, we'd really appreciate a moment of your time to tell us what you think. Thanks very much. See you next week.

Chris (49:59.378)

Thanks for listening.

Chris (50:04.924)

Cool, I have to jump straight off, but I will leave this open.

Colin (50:06.21)

You have to jump.