Colin (00:04.378)

Stripe found that 33 % of the developer time was being consumed by technical debt. But here's what's worse. Every fast growing company has a similar problem hiding in their operations. And it's not just a code. So today on how to build a growth system, we're going to break down why growth debt might be costing you 20 to 30 % of your revenue and what to do about it.

So as always, I'm joined by Chris Bayless. I'm Colin Shakespeare, of course. Chris, there's a paradox I keep seeing, or it looks like a paradox on the surface. So companies I've worked for, companies I've worked with and spoken to, they're getting to that stage where they're hitting product market fit. They scale like crazy revenues up and to the right as they like to see it. And then something breaks and it's not the product and it's not the market. The company itself seems to be kind of...

rounding to a halt or maybe not a halt but things can't move at the speed that they need to move anymore. So what's actually happening there?

Chris (01:12.942)

I think the interesting thing is, I don't think you even have to be scaling like crazy to run into this problem. You just have to be trying to do something that you haven't done before, whether that's a pivot or a big crazy target.

Every time you need to motivate a team to go and achieve something new, you can run into that feeling of seeming to slow down just as you try to go faster. You've got teams complaining that they're working harder than ever, but never actually getting anything done or certainly getting less done. Everyone's doing their job, but the system's failing. And that's what I would describe as growth debt, growth debt in action, in fact.

Colin (01:52.524)

Yeah, so is this sort of being a victim of your own ambition if you're in this position?

Chris (01:59.98)

Yeah, exactly. mean, picture this. You're scaling fast, so you patch your CRM instead of properly integrating it or properly deploying a new process. You hire really quickly without updating your onboarding processes. You add a new tool every time that there's a problem. Every decision is sort of rational and sensible in isolation because you're optimizing for speed.

Colin (02:25.639)

that old move fast and break things saying that's what that looks like in action,

Chris (02:34.348)

Yes, apparently so. mean, what nobody talks about is that those series of decisions, those sort of seemingly sensible, rational, you know, we're doing it for the investors, we're doing everything as fast as we can, we're optimizing for speed, kind of create this kind of compound interest when things break, as they will when you do things at that speed. And McKinsey,

did a study that found that companies scaling rapidly without what they described as integrating core systems, but fundamentally aligning those kind of operational bits of their tech stack and the surrounding processes experienced 40 % higher operational inefficiencies within five years. So as you kind of said at the opening with Stripe, it's very much like that kind of technical debt metaphor, but applied to the entire organization.

Colin (03:28.74)

So it's kind of like technical debts evil twin.

Chris (03:32.142)

Well, I think calling it a twin.

Colin (03:35.684)

Sorry, I have a six year old, so this is how I think about things now.

Chris (03:39.31)

I think it's an interesting metaphor, calling it a twin implies that it's of a similar sort of scale and importance to technical debt. I guess to extend that, guess growth debt is more like a sort of evil mayor running the town that technical debt lives in.

Steve Blank called it organizational debt and really it compromises the entire organization and

You know, when you make decisions to just get stuff done, you just have this compounding issue that goes much, further than the tech stack. you know, technical debt, that just lives in the code base. Growth debt spreads across people, it spreads across processes, it spreads across the tech stack, of course, but also about culture as well, which can be the most painful and difficult to unpick. It's a sort of systemic, systematic problem.

Colin (04:37.882)

I think what might help to define what growth debt is, what we're talking about here is if we look into a concrete example, what does that actually look like from experience day to day?

Chris (04:51.854)

Well, I think about a mid-size SAS we worked with a year or so ago.

The company, as most of these companies are, was under pressure from investors to sell more. And what they identified is that their sales cycle was longer than the competition. Effectively, they were doing less deals in a year because they were just dragging their feet, also the investors thought. So they bought in a sales consultancy, so external organization.

focused just on the sales org and they decided to re-engineer all of their sales processes and build those out within Salesforce. And they got pushed to do that within four weeks. So they built a bunch of new processes. They implemented those in the system. They built the automation, you know, the workflows and

funny enough, when they were pushed on timing and presumably screwed down on price as well, they skipped all the diagnostic phases. They didn't do any consultation with marketing and they didn't speak to customer success. They just deployed a bunch of automation within the system without really documenting it in any meaningful way. Crucially, they integrated a new CPQ tool that was parallel to the CRM and all the data sat outside it, had different permissions and so on. The short

result was actually that sales did see a bump in their sort speed to proposal and they sort of accelerated that part of the sales cycle. So you know that that was positive great you know consultancy gets paid they go off down the road everyone's happy for a bit and and this is

Colin (06:32.91)

got an ominous sense though that the long-term impact was somewhat undesirable.

Chris (06:39.008)

Yes, indeed it was. And actually the long-term impact ultimately was organisational debt in action. It compounded over time. It took a while to reveal itself. And really where they started to kind of see the cracks was because they hadn't done this broader sort of organisational consultation.

they realized that customer success didn't actually have any access to what had been sold. So previously they had visibility of proposals, they were doing the sort of quoting inside Salesforce so that everyone had 360 visibility of what had been sold and why it had been sold and know, to all the notes and all of that stuff. because they moved the proposal process and the quoting process into the CPQ tool with like the z-sign thing that they had attached to it, suddenly customers

couldn't actually see what had been sold, so they had to rely on handover and we all kind of know how that goes. What they also realized pretty quickly but saw the impact of longer term is that

marketing had a fairly complicated lead scoring system which sort of still worked but actually didn't because it had lost a bunch of the sort of behavioral signals and they also were ramping bits of the sales team at the same time and of course they hadn't updated any of the training materials, none of the onboarding processes had changed so they were sort of...

Colin (07:55.418)

I can just imagine being in that position. It's like, you do all this onboarding? But by the way, none of these documents are up to date and we do something else now. But you actually have to tick this box in your onboarding. And we've got nothing else for you to do yet. So you will be doing it.

Chris (08:15.714)

Yeah, exactly.

Chris (08:22.016)

So yeah, funny enough, things started to go a bit south at that point.

And they also realized that there were a bunch of like downstream ripple effects and all the automation changes. And fundamentally, instead of speeding everything up as it did in the short term, the actual entire customer journey, not just became slower, but pipeline dried up, customer satisfaction dropped because onboardings were long and rubbish because they kept having to re-ask all the same questions that had been asked in the sales process. And we got asked to come in about six months later when they finally admitted defeat and realized this whole thing had been a disaster.

This was sort of a little microcosm where one, to be fair, reasonably big change that actually achieved its initial objective created all of this growth debt within the organization that had to then be fixed and what the sort of hot fix became a hot mess, if you like.

Colin (09:19.876)

and then they finally pick up the phone to you.

Chris (09:24.526)

Yes, if only they'd done that in the first place, that'd be a lesson to everyone,

Colin (09:24.858)

When it's all broken, they're calling the growth doctor. We did all these silly things Chris, you were right. Please come and help. Okay, I think that's a fairly, I love that example. And I actually do remember talking about it at the time. And it's quite an illustrative example of how this happens with the best of intentions.

sort of across the industry. companies are accumulating this growth debt, as we call it, or organizational debt to give it another name. But how do you measure growth debt? I think that's partly why we talk more about technical debt, isn't it? Because it's kind of maybe not totally easy to measure, but certainly relatively easy to measure compared to something that's spread across systems, processes.

people, culture, etc. Is there a mechanism for spotting growth that you might not realise was accumulating? At least with technical debt you can literally point to legacy code.

Chris (10:43.628)

Yeah, absolutely. I think this is where it gets interesting because if you could really nail the answer to that question, then not only would you most likely not have the debt because you'd be able to see it, it's like the sort of electricity meters example we've talked about before, but you'd also have a business case for fixing it. So I think it's such a great question, not just, you know, can we see it, but can we measure it? And

Practically speaking, it's pretty difficult as you would imagine, but the symptoms are everywhere and lots of people have done a pretty good job of putting some numbers on some of the symptoms. I mean, some that immediately come to mind is around kind of context switching particularly.

There was a study that suggested that 69 % of knowledge workers and organizations spend 60 minutes every day just switching between applications. And the average worker switches tasks within those kind of tech stack of applications that we use in our business day around 300 times each day. And

It's sort of tempting to think that that is a technology problem, but actually it's a sort of measure of organizational entropy. And I think that's quite an interesting way of sort of framing the problem.

Colin (12:03.746)

Yeah, entropy as in decay and things naturally falling apart.

Chris (12:11.938)

Yeah, kind of. think I'm no physicist. think in physics, I think there is a sort of decay figure there. In systems theory, we tend to kind of think about entropy as being the number of ways that system can be configured or structured or ultimately a sort of measure of complexity within the system. And there tends to be a sort of

a causal relationship, certainly a link between complexity and disorder. And ultimately, the higher the entropy in the system is, the higher the dysfunction in the system is typically. So the more complicated you make something, the more times you have to context switch, the more systems you have in there, the higher the sort of entropy is within the system. And as organizations scale and...

fix stuff and they patch things, they're adding complexity all the time, that they're ultimately making that kind of system diagram of how stuff gets done more and more complex.

and without continually kind of putting the energy and the input into maintenance integration and simplification and documentation and enablement and all that good stuff then everything does trend downwards towards chaos and guess that's that sort of like decay figure almost that you referenced because I mean ultimately

This podcast is about growth and the faster you grow, typically the faster you add complexity and therefore the faster you add dysfunction into your system.

Colin (13:44.386)

Yeah, this is almost counterintuitive there. This got me thinking as well of like, if your company was investing lots of time and money and resources and essentially gambling their future racing against one of the universal laws of physics or maths, for example, then probably your investors would say, is going to be a disaster very obviously sort of thing because these laws are...

pretty much fixed and govern the universe. And yet it seems like in these particularly early stage growth, that sort of hyper growth phase, people are trying to race against systems theory.

Chris (14:30.39)

Yeah, I think so. And it's so tempting, maybe even necessary to sort of turn a blind eye to that accumulation of growth debt as you're in that phase, but it will come back to bite you. And it will bite you in a way that you can measure on the bottom line. And you look at some of the data, particularly in startups,

around things like new hires. I think that's always quite an interesting one because that tends to be one of the biggest costs within most organizations. And whilst we all think, yeah, it takes about three months to ramp someone, sounds like a long time.

I think the realistic figure is five or six. Some studies say eight to 10 months to actually get a new hire to be productive. That's the majority of the financial year where you've got someone below their peak operating capacity. That's because they've been dropped into a system that is dysfunctional, that is disconnected, that is undocumented. It's the same stuff with the tech stack.

to ask AI at one point how many different figures we had used over the course of the last three seasons for the number of applications and organisation uses, but I think that it's a three figure number and I keep seeing different ones written down, but you know it's over a hundred in most organisations and yet only 30 % of employees feel like their tech actually helps them perform better and

Colin (15:57.146)

you

Chris (16:11.956)

That again is like the people cost, know, software cost is a huge line item, you know, in the overhead. And we've got all these unproductive employees unproductively using systems that don't really add. And that really is measurable. You know, that, that, that has a sort of pounds and dollars or, know, choose your currency costs that you can really measure. And I think that that sort of

Relationship to systems theory is really just thinking about measures of complexity. How complicated are we making it for everyone? The more complicated it is, the less well documented, the less people are easy to ramp, the less they understand what this giant text next to it, the less productive they're going to be and the less money they're going to make you. It's a fairly logical progression, I'd say.

Colin (17:01.05)

Hmm. I guess as we sort of hurtle towards the halfway point, or probably a little bit over it here, it's probably quite important to think about how to help leaders spot growth debt, essentially. mean, every company's got onboarding challenges and tool proliferation and context switching challenges and all this stuff. How do you know when it's crossed from

whatever you want to call it, growing pains or teething trouble or all these little euphemisms that we use to like, we have a growth debt crisis. Like how do you actually start to spot that diagnosis?

Chris (17:41.582)

Well, as with anything in systems, there are loads of signs, but I'd kind of wrap it into, I don't know, maybe four really significant red flags that you can see go up when you kind of have this problem looming or indeed existing there in the background. And actually we're talking about dysfunction here. We're talking about inefficiency. It kind of stands to reason that you're going to be able to see that as an erosion of financial performance.

Now, typically as systems become more dysfunctional, they become less efficient and you can usually measure that on the P &L or at the very least in the sort of leading indicators of financial performance, like maybe pipeline value or even performance versus target, you know, in individual quarters. I think secondly, you can really...

seek growth debt in the effectiveness or indeed lack of effectiveness in which you can deploy new strategy effectively across the organization. I think if you've got a sense that no matter how well you explain things in inverted commas, it just isn't coming to life across the business and that for me is a really significant red flag. And actually to sort of briefly alight on that point, I do think that that is one of the key areas

that really leaders need to stop and think about is there's always some new strategy, whether it's greater or lesser. And there is always a sort of strategy to execution gap. And your ability to identify growth debt is directly impact on your ability to close that sort of execution gap versus strategy. And I think that the more ineffective you're feeling that that is, larger you're seeing that gap to be or perceiving it to be.

the more likely is you've got a problem under the surface, which is pretty significant. Something that sits more in the sunshine zone, in the visible layer, I think, is actually where you can see a dissonance or a gap between your process documentation and how work actually gets done.

Chris (19:49.068)

I know it's possibly not, you know, it's not there out in the open, but actually it does link to documentation. think if you can do an audit and you can see what actually we've got these poor processes and they're in a drawer gathering dust and they've got no relation whatsoever to how work actually gets done, then that is definitely a significant marker of growth debt, organisational debt.

And, you know, last but very much not least, I think employee churn can actually be a really good marker of organizational debt. Or even sort of just before this, if you've got a general sense of unhappiness and unease and discontent in the team, then you've probably got some underlying systemic structural issues driving that.

people as a rule don't like being pushed to achieve something. They don't feel like they've got the tools or the ability to actually deliver on. And when you kind of see these patterns, you're approaching, and I think this is probably a fairly serious point that we talked about the impact of growth debt. Well, actually,

All of those, you get reduction in financial performance, get an inability to deliver on strategy, you have a dissonance in how work gets done, you have employee churn rates. These are all significant problems. You're approaching what can become, in systems what we would call a runaway feedback loop. The worse it gets, the worse the financial performance can get, the more erratic the strategy can become.

as leaders are trying to course correct against that erosion in financial performance, the less able the team are to deliver on it, the more likely they are to leave until you can actually really get some quite significant kind of runaway clap scenarios that come from this.

Colin (21:30.714)

Runaway collapse is pretty scary. mean, at the top of the pod, we were talking about growth debt potentially impacting revenue by 30%. And that kind of gets the attention that people would maybe think we're being hyperbolic when we say it could actually be an existential threat to your business.

Chris (21:54.134)

Yeah, right. mean, ultimately...

This is a leading indicator of how those organizations actually die. They take a series of decisions that compound into an inability for the human beings in the system, in the business, to actually come back from them, to drive recovery, to take it back from the precipice. And there's all of those small decisions which we tend to shine the light on, they made this silly decision, they made an investment into something. Well, actually, that's a strategic endeavor. That is a deployment of capital, that is a deployment of human resource.

Now that is a lack of ability to deliver on the promise. All of that is fundamentally an accumulation of organisational debt because you didn't fix the things that would have allowed you to get to where you wanted to go.

Colin (22:49.12)

So this is obviously, to put it mildly, a big issue. What? I guess it's a good time. Really concisely and succinctly put by our standards of the how to diagnose part. I guess it's a good time to really move on to the what can I do about it? Because I think we probably succeeded in scaring people. Now let's sue them.

and tell them what they can do before this gets out of control because I'd be very surprised if anyone listening didn't at least recognize some of these leading indicators in their own organization. So let's help them.

Chris (23:32.441)

So I think there are lots of answers to that question, but maybe let's go with a practical one for once rather than a theoretical one. I think you can actually learn a lot from the practices of dev teams in managing technical debt, because often...

they'll have a bunch of fairly well established practices that kind of sit within the operational rhythms of the team for managing that problem. Whether that's things like kind of peer code reviews or monthly feedback sessions or kind of operational retros or whatever it might be, even kind of listeners and stuff that they build as technical solutions. I think you can kind of take the concept of what happens in the management of technical debt and apply that to the sort of field of organizational growth debt.

And something that I think is underutilized is actually the sort of network effect of the people in the organization. Whenever you're doing any kind of change management or kind of transformation, process redesign even, you actually need to understand what's happening on the ground.

things are manifesting themselves. So I'd advocate for some sort of kind of organisational debt sort of pulse survey, you might want to pick a better name than that, but actually being able to sort of just do a sort of, I don't know, five, six question survey.

How strongly do you agree with these statements every month, every quarter? You know, stick a comment box in to dig into low scores and just ask people about things like clarity of direction. You know, do they actually understand the company's priorities and how their work actually contributes to them? Do they know where we're going and how they're

Chris (25:20.31)

sort of contributing to helping the company get there. If they strongly disagree that they do, or rather that they do not believe that they understand that, that's a big issue. Things like decision-making transparency or indeed devolved decision-making capability, do they actually know who's accountable for key decisions?

Do they understand how those decisions are made? Do they understand things like kind of role and responsibility alignment? So are there responsibilities as an individual contributor or is it even as a director, as a head of department? Are they clearly defined? And do they actually match the expectations set out in your job description at the start? I think that sort of variance in the swim lanes that we all sort of exist in is a really big marker of sort of all that.

Process efficiency is a really obvious one. Can I actually do what I'm supposed to do every day without repeatedly running into bottlenecks and constraints and approval loops where things never get approved and things that just stretch out into the future because no one owns them?

Information, think is another really key one that's a marker here. Can they actually get the information they need from other teams? Can they do so in a way that's actually timely and consistent and collaborative? Is it like getting blood out of the stone? Do they have to go fishing around in SharePoint or whatever awful system they're using for information, knowledge management to go and get this stuff? Or can they just go and work with another team?

I think workarounds is probably quite a good one to measure as well. Yeah.

Colin (27:08.474)

kind of leads us all to what people actually do as a tactical based on the we do workarounds and really that's the kind of shadow growth system that you actually that exists in reality not what's in your dusty old SOPs in a virtual drawer somewhere.

Chris (27:14.86)

Yeah.

Chris (27:24.648)

Exactly. Yeah, exactly that. You know, how often do they actually have to create a temporary fix or a manual workaround because there is no process or, or, you know, how fragile are those processes? Cause actually there's, you know, there's one person in the team that actually knows how something gets done properly. I think you actually just go and do that pulse and just say, score that one to five, anything you get three or lower. What's the key issue causing it? if you that across your organization every month or every quarter.

and you incentivize the participation in that somehow. We talk about psychological safety. mean, it anonymous, you know what? And then just listen, actually listen, don't make excuses. Use that sort of free text prompt a bit like a bug report, you know, in a bit of software.

Colin (28:09.368)

Mm.

Chris (28:18.517)

And if users keep saying the same thing, that it manifests in the same way or in the same condition, then go hunt that down. And I think that just activating the people on the ground that are actually experiencing the problem day to day and having to manage it is a far better way to get to the problem than hiring some sort of transformation consultancy to go and do this for you.

Colin (28:45.381)

Indeed. So unfortunately, really this is something I want to ask you that I think we maybe don't have as much time as we'd hoped to dive into, but it's kind of a burning question for me. So I'd appreciate it if could at least spend a couple of minutes on it. Like you've identified the problem really well, sort of solved the problem for us of how to measure it, how to spot it. Maybe what we can do about it. But here's the thing that I keep thinking about. Most leaders, I don't think I speak to any

leader in this field that doesn't already know they have these issues and inefficiencies, why don't they fix it? And I appreciate that this is a big topic and we maybe only have a couple of minutes to go into it, so sorry for throwing that at you.

Chris (29:30.799)

I think that ultimately they're busy and they can't put a number on it so they can't build a business case for it or more likely they do actually try and fix it but they fix it in the wrong way.

I like bit of Danella Meadows. I'm sure we've used that name lots and lots of times on the podcast. think her systems thinking, I it's called a primer, is one of the sort of seminal intro texts to systems thinking. And there's a framework in the back of that around system leverage. It's like 12 things that you can use to change the direction of the system, know, levers that you can pull.

And I think most organizations try and fix these kind of growth debt problems by trying to apply some of the levers that have the least amount of leverage. And often what they try and change is what's, I think, the lowest leverage one in the framework of memory serves me correctly, which is parameters, you know, whether that's budget or people or tools or just they just try and throw more things at the problem.

Colin (30:45.17)

So like more budget, more people, more tools and essentially the ad complexity to solve complexity, right?

Chris (30:55.823)

Yeah, exactly that. They actually...

increase that kind of system entropy by just chucking more stuff into the mix, you know, that it's like a big sort of cauldron and they just keep putting more ingredients in and hoping the sort of the soup tastes better. And of course it's most likely not going to and actually the highest leverage point on that particular framework is sounds pretty fluffy but it's changing the paradigm that the organization exists within, it's changing that core belief about how

should actually work about what you can do to actually fix problems. mean ultimately it's about changing the belief that you need to be able to see the whole rather than just the parts, you know, you need to be able to see the forest for the trees to use a sort of common expression.

Colin (31:47.422)

Indeed. So...

Founders listening to this and growth leaders listening to this will be nodding their heads and recognizing the problems. And they're probably doing two things at once right now. And I essentially feel like they're running at 200 miles per hour. How do they start to apply these lessons? on Monday morning...

How do they come in and start to apply these lessons and start to steer the ship away from these sort of growth debt icebergs?

Chris (32:30.159)

think it's really tempting to say, you know, just just slow the F down. It's, it's difficult, but ultimately, it comes from ruthless prioritization. I think if we put a name to this problem, and we put a value to this problem, then we can make it a priority.

And I think that the issue with all systems issues that exist below the surface, you know, that they are outside of the sort of visible zone most of the time, are really, really easy to ignore when, you know, everyone's banging your door down trying to, you know, get little things solved, that actually solving big things is just hard.

But we talked about J Galbraith, I think, last week and that sort of cost of coordination and the fact that that sort of rises in an exponential fashion. I think that, yeah, the answer to that, or Ash, for anyone that didn't listen to the episode, that essentially says that if you double the amount of people, you triple the complexity of the interactions between those people. It's pretty much mathematical.

So I think the question for leaders has to become how am I not going to let my organization get into this state in the first place? How can I design my organization to minimize the cost of coordination, to minimize complexity, to minimize entropy?

And I think that having that forward thinking view of, let's structure for growth. Let's actually solve these problems now before they come home to roost. I think that is a way that you can make this a strategic priority that you can get the investors on board with, that you can paint as a narrative and a language that is going to be impactful while actually solving the big issue.

Colin (34:32.953)

Yeah, I guess being strategic about where you slow down, right? It's just a kind of different sort of leadership from the instinctive move fast and break things. It's just speed up, speed up, speed up. need to, as I say, need to be sort of strategic and make big decisions about where to slow down. Maybe a day of mapping your value streams could save you six months of inefficiency.

one week redesigning decision rights could prevent a year of pointless meetings. So I guess this would be a good point, I would say, as we're hitting about 35 minutes into the pod. It would be good to just simplify down to some steps that a growth stage revenue leader can really

Chris (35:05.923)

Yeah. Yes, absolutely that.

Colin (35:27.642)

take, you know, let's say I'm a growth stage revenue leader and I recognise these patterns, what steps can I actually take next week to sort of tear the plaster off here and try to do something about this before it gets really bad?

Chris (35:49.241)

Well, I think like all systems problems, it pays to draw a boundary in the right place. I think if we try and fix the entire organization on Monday morning, that's probably not going to end well. Certainly not from a sort of outcomes and productivity perspective.

So I'd really think about, okay, well, what part of the sort of interconnected system? And I think that is purposely, you know, stated as the interconnected system. We do need to draw a reasonably wide boundary to see system effect, but ultimately, I think starting with a bit of an audit of how you actually got there, you know, when did stuff change? Because I think that can be quite a good diagnostic tool.

of actually putting some major milestones in place and starting to really feel how the organization started to sort of move in a direction that you perhaps weren't quite as happy with. You know, what tools were adopted, what organizational structure changes happened, you know, what hiring tranches happened. I think they'll start to show you when debt started to accumulate and what areas it possibly accumulated in fastest. And

I then really get into those areas and start talking to frontline teams about what's actually going on. You could use the survey I mentioned earlier. You could really just go in and ask the question of where do things break down here? What's going on? Where are you doing these hotfixes and workarounds? Because I think you'll start to find the patterns there quite quickly. And I think the key thing, and it was the thing that you mentioned earlier, is...

we need to quantify the cost of the problem because if we can actually put a figure on that and we can say that actually our engineers are spending 30 % of their time on workarounds or.

Chris (37:44.073)

when we're onboarding a new hire, it takes six months instead of three, then that's measurable and that's a problem that you can take to the board, you can take to the sort of, you know, the people that hold the purse strings and say this is something we actually need to stop and fix. And I think that take those first couple of steps of just, you know, identifying the area, discussing with the people on the ground, what's actually going on and putting some numbers around that.

really gives you a great framework to kind of make the invisible visible.

Colin (38:25.902)

Yeah, I think a lot of leaders maybe, like I was saying, they'll feel the pain and they'll empathize with what you're saying, but being able to actually articulate the cost, I think, is what makes the difference here. That's the leap we're trying to enable, right?

Chris (38:39.663)

Yeah, absolutely. And I think when we can zero in and we can get the focus and attention of the organization when they're really running fast, then we've actually got to get into the sort of nitty gritty of it. And for me, as a systems person, that's really about surfacing those kind of hidden dependencies.

Most inefficiency, most dysfunction within the organization stems from the sort of invisible connections between the nodes and the system. It's the way that the system is structured, not the elements within the system itself typically. So using some kind of basic, you know, back of a fact packet systems mapping, know, stick it on a whiteboard.

how does the decisions actually get made? How does data flow? What things does it touch? Who does it go through? Not just saying, well, that's the org chart. So that's how decisions get made. But actually kind of zeroing into those areas where you've spotted the dysfunction and you've kind of discussed the issues and start doing that sort of, whether it's a value stream exercise or whether it's an information flow exercise, just how does it actually work? What are the dependencies? And.

If you then know what the dependencies are, you know what the structural issues are, then you can really start to prioritize where the fixes get made. And then I think it's about thinking about, okay, what are the levers we need to pull to fix that?

Colin (40:01.464)

Okay.

Chris (40:10.191)

Ultimately, doing things like changing a collaboration rhythm or redesigning the decision rights and how people are empowered to make decisions makes a somewhat larger difference than just giving them a new bit of sass to record the dysfunction that they already experience within. I think also the point that

that I made a second ago about kind of building for the future is a really, really key thing. you know, lifting your eyes up, not just from the problem right in front of you, but towards the horizon. And if we actually fix the solution, we're building an organization that will still work when it's 10 times bigger, then we're putting in a lot of resilience into those structures. You know, of course you're not going to go say, okay, well actually you intend when we're 10 times the size,

going to need a huge IT system or we're going to need all these people. You want to implement it incrementally but we need to actually define the end game and then work back to meet us where we are but ultimately do a solution that can scale to that point and I think particularly if you have huge scaling ambitions, you're VC backed, PE backed, whatever, then build the structures that work when you get to where you want to go not just the ones that work right now.

because if you don't do that, then you're just kicking the problem down the tracks to another day and you're going to slow down and ultimately you're probably not going get to where you wanted to go. But I think sort of finally, the one that is...

probably the most impactful in terms of steps you can stake is actually around empowerment. You know, we talk about self-organization a lot on this podcast, but if you actually empower your team to identify and fix and sort of propose solutions to problems, then...

Colin (42:02.714)

you

Chris (42:05.223)

you suddenly extend the workforce of the sort of guardians of the process, the sort of defenders against organizational debt become a lot more than just the management team. So actually putting in place where you've got monetary retrospectives, you've got kind of...

whether it's kind of real-time feedback channels or you kind of just embed the process for analysis into the teams, you allow them to detect organizational debt before it compounds. And if you actually give them the people that are actually experiencing the problems, the power to discuss and propose solutions and give them the time to do that and the permission to do that.

and make that part of the operating rhythm of the business, then you've ultimately going to build a very, very resilient organization that can learn and adapt as it grows. And I think if you can do that while planning for scale and putting names to problems and really thinking about system leverage, then you can really build an organization that's going to be very, very good at continually adapting and not allowing organizational debt to accumulate.

Colin (43:19.934)

Nice. Chris, we have got lots more that we could talk about on this subject, and I'm afraid I'm going to have to tap my watch here and say that we're going to have to unfortunately wrap it up and maybe have to either return to

Chris (43:32.555)

A shock. Us over time. Who would have thought?

Colin (43:33.858)

return to this topic in writing or perhaps on another episode. We do tend to generate other episodes just by having these little wrap up discussions. I guess one thing I would think as a final thought is it almost seems counter intuitive or it'll get growth leaders backs up when we're asking them to slow down and map processes and things like that when they're fighting for their survival. We've got investors.

Chris (43:46.063)

You

Colin (44:02.938)

breathing down their neck for growth, not operational excellence. And we've got to sell, let's fix our systems when obviously all these stakeholders are screaming, move faster. But I guess what you're saying is it's kind of a, it's not a choice between growth and getting the system right. It's the choice between sustainable growth and growth that's eventually just going to collapse under its own weight, right?

Chris (44:27.887)

Absolutely.

Colin (44:31.924)

Any other final thoughts before we wrap up Chris?

Chris (44:32.707)

So.

Chris (44:36.999)

I think that if you did one thing from listening to this podcast, you know, we've proposed many things you could think about, I if you did one thing, I would go and ask your teams.

a simple question, which was what would break if we doubled in size tomorrow? Because that's likely to be the thing that's most visible, that's most top of mind, that has the highest cost and is the sort of, you know, the trap waiting to be to fall into. So, you know, go and identify.

Go and leverage your teams and just start much like technical debt, start building the backlog and do that as directly as you can.

Colin (45:25.376)

Yeah, it's funny. There's so much focus at the sort of start of the year and we're planning saying, well, we're going to set this really super ambitious target to double in the next financial year. And we don't tend to have this discussion about what would happen to the organization if we didn't do that. It's like, too much focus on, what would happen if we fail? God, what if we succeed?

Chris (45:55.299)

Yep, absolutely.

Colin (45:55.385)

We might break the organization Okay. Well, I'm gonna have to Call a halt to this. Unfortunately, we have run out of time today Chris But as I said, there's lots more to this topic that no doubt we'll delve into later Please if you listen, don't forget to follow and rate the podcast It really helps us to bring the content to a wider audience and we really appreciate a moment of your time to just

Tell us what you think and what you'd like to hear more of on the show. How to build a growth system, as always, is brought to you by RevSpace. RevSpace is a growth systems consultancy, connects B2B organizations with the future of growth, offers account-based growth, managed services, go-to-market engineering projects. And of course, you get to hear more of Chris's voice into the bargain.

If you want to speak to if you want to speak to round space.

Chris (46:53.593)

That's a dubious benefit that one.

Colin (46:56.474)

Yeah, but at least it's not time limited. It doesn't have me tapping the watch there, Chris. But that's really, really all we've got time for today. Thanks very much and we'll see you again next week.

Chris (47:10.735)

See you next week.