Colin (00:01.725)

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

Chris (00:09.184)

I'm Chris Bayless.

Colin (00:11.229)

Today, we're going to cover a topic that I think sometimes we shy away from a little bit on the growth system, Chris. And that's, I guess, what we call in the growth team operating system infrastructure. But I guess it's best understood as sort of how we architect the technology stack, platforms, integrations, software, tools.

that actually underpins what the growth team do. And I wonder if the reason why we sometimes shy away from doing that is that it brings some ambiguity as to the meaning of the word systems here. I guess in a lot of organizations when people talk about systems or the systems manager or someone will be effectively the sort of IT manager effectively. That's not necessarily just, it's not what we're talking about when we're talking about systems thinking.

Chris (00:46.008)

Mm-hmm.

Colin (01:04.541)

But in this case, I guess that kind of is what we're talking about,

Chris (01:08.974)

Absolutely. I think you're right. think this is, despite the fact it's quite a big part of probably what we do every day at RevSpace. I think this might only be the second podcast episode where we've actually really talked about Tech Stack.

But you know, I'm excited. I love talking about tech stack, but I think you're right. We do sometimes perhaps swerve that a little bit, you know, less not to reinforce the confusion about systems and systems.

Colin (01:26.547)

you

Colin (01:43.217)

Yeah, don't confuse systems with systems.

Chris (01:45.134)

Yeah. Speaking of confusion, I just made up a word there. Confusement. That's a, that's a new one.

Colin (01:50.225)

Yeah, we can try and trademark it. So I guess what would be useful to kick off with is what is this of systems view or what is the systems view on what sort of infrastructure as we are defining it is.

Chris (01:54.53)

Yeah

Chris (02:10.146)

Well, I I think you could probably describe infrastructure as something like the nervous system of the organization. It's the mechanism by which a good deal of the data gets carried around the org.

And, you know, when we talk about infrastructure, I think maybe it's probably worth defining what we mean by that beyond just the sort of tech stack, because actually there's a lot in there. You know, there is the sort of inevitable SaaS, you know, the sort of tech stack, as most people think of it, the SaaS applications we subscribe to or pay for. But also we're thinking about the sort of data repositories and particularly we're thinking about the sort of integrations architecture and how all of this stuff is stuck together.

And together, the sort of composite of those really, in most orgs, does a good or sometimes not such a good job as sort of relaying the signals around, you know, the different parts of the org, and whether we're defining those parts as departments or indeed people. But ultimately, it's about information flows. And if we

think about the sort of growth system design methodology which we run to, know, infrastructure very much sits across the sort of the information and the elements, the information flows and the elements. It's the sometimes the software can be considered elements themselves and then the integrations in some ways how that data flows between them. So we're of straddling two parts of that sort of system description of interconnected elements united by purpose.

And I think when, I guess if we're really going to make more of a sort systems thinking view, I also think that there is a, an interesting way of perhaps viewing the technology within our organization, the tech stack as a sort of feedback amplifier or certainly as a feedback mechanism.

Chris (04:16.922)

When we just talk about feedback in systems, ultimately, we often think about loops. We think about how things are either balancing or reinforcing the things that we are doing, whatever that thing is, sort of flowing through the system in question. And the tech stack in most organizations actually is really one of the mechanisms that we use to

those feedback loops in place and sort of in use, guess. So I know a sort of quite granular example might be sort of dashboards and data. You know, actually they are in many ways the ultimate kind of feedback loop. Are we on track to whatever that goal is, whether it is revenue or conversion rate or impressions or, you know, website visits or, you know, any manner of metrics, you know.

Infrastructure can be an amplifier of that feedback when done well. know, dashboards alerts, you know, all of that allows us to speed up the iteration, I guess, of, and you know, speed up our response time, but equally poor infrastructure is, can distort feedback and delay feedback and slow us down, can let the sort of system drift away from its intended course for longer or drift further.

So, you know, we have those sort of data silos, inaccuracy, whatever it might be. Disconnected systems, ultimately, in the technical sense, create ineffective systems in the sort of systems thinking sense. So I think that sort of role of infrastructure as a sort of feedback loop mechanism as an amplifier of feedback, I also think is is quite a key point. And actually, in many ways, that that sort of

amplification of feedback loops is one of the ways that we drive additional ROI into organizations by ensuring that the tech stack is architected right. Because if you can kind of sense and respond quickly and the tech is an enabler of that, then ultimately you probably have a better performing, more efficient organization. So

Chris (06:33.804)

I think there's a lot going on there and I think we'll probably unpack a lot of that as we go and particularly around the sort of interconnections piece, the integrations piece.

Colin (06:44.049)

Yeah, I like the idea of using the analogy of a biological system and or like infrastructure being like the nervous system. You know, I've had nerve problems before, in my my arms and a part of my legs just from sort of old injuries and actually it actually genuinely does leave me more vulnerable to further injuries because the literally the feedback system, I.E.

by which you can tell that something is wrong in your muscles or your joints or something like that isn't there and so that you know injuries I've had have actually got worse because of the nerve damage effect of the infrastructure. It wasn't fit for purpose. In this case of course it's entirely my fault for not investing enough time in my fitness but rather than not investing enough in my technology.

Chris (07:35.042)

Yeah.

Chris (07:39.758)

I think that there's an interesting kind of parallel in that we sort of, I think it was the last episode we closed off by saying, you we should talk about anti-fragility as a topic on a future podcast. And I think actually that tech stack fragility, you know, there is a lot of sort of...

parallels to what you were just saying, because lots of kind of infrastructure can be quite brittle, you know, you can exacerbate the pain by not kind of building flexibility into into the infrastructure. So I think that's sort of like organic systems. analogy, you know, really reads across very well in terms of not just what the system is, but actually how effective systems are put together. I think there's a lot to learn from

you know, from that sort organic organism view.

Colin (08:33.541)

I what that brings us onto is the importance of finding that right sort of balance point between standardization and flexibility within the tech stack. I mean, I think we've all seen this recurring tension of deciding how much to standardize versus allowing sort of local teams to freedom to pick best in class tools or maybe not, or perhaps, you know, separate business units that have

slightly different needs. And I think I've seen it go both ways where a part of an organization is moving off perhaps what would be sort of the best fit tool for them because the larger organization they're part of is going through a sort standardization initiative. And an actual fact that that's in some cases, I've seen that kind of go too far towards the centralization and indeed in just as many cases of

that have been involved in projects and things where there is a centralization would be a more centralization would be a desirable thing, especially companies that have grown in organically with lots of acquisitions, for example, where the tech stack is extremely misaligned.

Chris (09:44.183)

Yeah

Chris (09:49.302)

Yeah, it's something we come up against so much and I think it's, you know, as you were talking there, I was thinking actually the

Chris (10:01.802)

the.

Chris (10:07.214)

I think if we could just pause there and hopefully Dominique can stitch this together because I have just realised that Christina is messaging me and is locked out of the house. So hopefully we have a seamless cut here. should be back in 30 seconds.

Colin (10:18.567)

Yes.

Chris (11:08.076)

Right, time, seamless cut time. What should we do? Should we go back to the top of? No, I'll just go.

Colin (11:15.507)

Nah, just kind of 5, 4, 3, 2, 1 and then carry on.

Colin (11:25.605)

about centralisation versus local autonomy.

Chris (11:28.391)

Yeah

So I think that this is a really, really interesting point. as you were talking there, I was almost thinking, I think my view on this is actually evolving because we come from a sort of rev ops background. I mean, certainly there's a big rev ops expertise inside the business and the sort of initial dream of rev ops was, let's remove.

silos. Let's, you know, rather than having a sales op functioning and a marketing ops function and a CS ops function, you know, let's harmonize that. Let's bring that kind of ownership of the infrastructure into a single team within the organization. And ultimately, you know, let's, let's pursue a sort of centralization path. You know, let's, let's put everything into one place.

and let's manage it centrally to ensure that all of the stuff we're alluding to, you know, kind of at the top of the episode, about kind of integration and data flows and high quality feedback loops that come from everything being stitched together and unsyled, know, the benefits are massive to that. But I think it's fair to say that

whilst that sort of utopian ideal of, you know, highly effective centralization does work in a lot of companies, there are certainly plenty that are resource constrained in that area where perhaps it doesn't work as well as you would want it to. And I think there is a general trend towards the sort of citizen view in IT.

Chris (13:18.998)

and actually creating some sort of structured autonomy within Teams. So, you know, previously, know, pre-rev ops, would have had a lot of...

functional autonomy around technology decisions, only the really, really big tech decisions would get made by IT. And then typically, most departments get to be able to procure their own tech and work with IT to integrate it to whatever degree, depending on the organisational maturity. I think this sort of then was like a sort of rollback to centralisation. Well, I think it's probably a trend over time, isn't it? Because probably originally you were in a pure centralisation, centralised IT, monolithic systems view and, you know, SAS, think, broke that.

And I think rev ops kind of pulls it back together. And I do wonder whether we are now moving into a sort of citizen developer, citizen automator view of the world that is slightly more autonomous. And I think what's really interesting is how you embrace that.

as a sort of functional concept because it could be a disaster. I'm sure in a great many organisations it is a disaster, you know, that's where the phrase shadow IT comes from, isn't it, and it's very much perceived as a negative.

because it's around people getting around IT and doing their own thing. And of course that has a load of security risks. It has process risk. There's just a lot to not recommend with that.

Colin (14:58.131)

At the same time, think it shows that people will be pragmatic in order to get the job done. And if they can kind of pull out a credit card and get some sort of tool that perhaps the central IT department thinks, this is shadow IT. But at the end of the day, it's actually an important piece of the infrastructure that is getting the job done in the time and at the quality it's done. And I think this has reared its head.

in a much bigger way now that we are well and truly into the era of Gen.AI. I think, I almost think that shadow IT or even shadow AI, you might call it, is pretty much ubiquitous across most industries, I would say.

Chris (15:33.878)

Yep.

Chris (15:40.718)

Thank

Chris (15:46.07)

Yeah, absolutely. mean, with our sort of automation practice, you know, we talk a lot about sort of centralization versus decentralization of automation. And I think that what we observe there is that it actually exists in a continuum. When you first onboard a new iPads tool, our case, something like Wakato,

it does tend to be sort of 80 90 % IT driven at the start or certainly owned by an individual business unit. And then actually what we tend to see over time is that the percentage of automation is being made within kind of line of business roles just gets higher and higher and higher until you're probably three years in and you're biased towards you know, users making their own automations. And I think that

sometimes that scares organizations. And the answer to that, in our opinion, is to kind of create a center of excellence around that is to actually embrace the fact that people are going to do that, and create governance and create support and create, you know, the right kind of security rationale operating procedures around using that rather than just banning it. And I think that that

Colin (17:06.13)

Banning it's simply not going to work, it? This is already part of your growth system, like it or not. How do you embrace what's going on? What is going to go on anyway? You can ban it all you like, but people are going to use whatever tools that they can find to get the job done, aren't they? And I guess this applies to life in general,

Chris (17:22.05)

people can use it.

Yay.

Exactly. I really think it does. you know, when it comes to AI, I think that is inevitable when it becomes to automation, I think it is probably desirable, just simply because IT never has enough capacity to do all of the little jobs, and indeed to understand the use cases well enough. So I think that really where the sort of decentralization view falls down for me actually is in the world of applications.

And something that we observe a lot is feature overlap, lots of teams and data silos.

teams procuring their own tools, trying to fix a particular use case by procuring tech, not integrating that into the rest of the stack, having an island of Unator that's a system that's only used by a few people, perhaps underutilization of license, overlap with features, with other tools. And as we talked about this before, but...

Chris (18:31.182)

I think the world of SaaS is starting to implode slowly because there are just simply too many vendors out there right now. And I think that we're going to see a big shift or we have been seeing a big shift over the last couple of years where

Everyone's trying to put AI into their product. Everyone's trying to launch as many features as possible to, you know, be everything to everyone to try and make the product sticky. And actually they're making the product more expensive in the process as they're putting more stuff into it. And I think that, you know, that it creates a really, really,

difficult market for consumers to make sense of. And I think that you do need some degree of centralization in that kind of IT purchasing role to ensure that you're not just burning budget left, right and center and kind of creating data silos. So I think it's.

Colin (19:28.883)

You're creating opportunities for misalignment, aren't you? When you've got, you know, the sales team are using, you know, whatever piece of your tool stack and then the marketing team are using or success are using essentially the same functionality on one of the other platforms that you have. And then you have a misalignment problem that someone needs to fix, but probably won't.

Chris (19:32.353)

Exactly.

Chris (19:51.968)

Exactly. mean, the obviously it all depends on all sides, but you know, how many organizations do we see where they've got Salesforce and HubSpot, you know, it's such a classic one. And they've probably got one sales or admin and they're paying 30, 40 grand a year Salesforce. they're probably paying, you know, 15 grand a year to HubSpot.

if they're using the HubSpot, you know, marketing services, which typically they are, they're using kind of marketing hub pro or marketing hub enterprise, they've got a CRM already, you know, they are, they do have a CRM. That's the way the data exists within marketing hub is in the CRM. And it's, it's, know, it's just duplication of efforts, duplication of functionality. And, know, often you extend that to CS and you know, someone's using Zendesk as well, and they're integrating that with

Yeah, with something as well. And you think, well, why? Because each any one of those tools, Zendesk, perhaps accepted might do all three quite comfortably. And I think that's where the organization does lose out when you have that kind of local autonomy to procure tools. And the argument, of course, is probably that, you know, people think they're getting best in class, but I don't really buy it.

to be honest. And as I know, we've sort of, you know, thinking about or planning to talk about later on, the big shift, I think, comes as you kind of alluded to, with the sort of AI revolution, I think that's gonna have a huge impact on how tools get built and how functionality gets, you know, utilized. I mean, as a...

I was telling you actually when we were waiting to start recording, I'd just been mucking around with something this morning and built an AI agent to do lead enrichment. And we have a product that we sell, which is based in lot of automation technology that's a composable architecture and is very clever.

Chris (21:54.028)

but depends on a few different applications in that composable architectures to the enrichment. And I've built an agentic solution that actually just uses AI to do the enrichment rather than a service. So it's not perfect, but it definitely.

indicates to me there's a direction of travel where actually a lot of the SaaS market is going to fundamentally change because people can build their own applications using AI and kind of agentic interfaces. So I think we've maybe gone down a bit of rabbit hole there, but I do think that the, you know, the tide is turning and the organizations that will win in this sort of standardization versus flexibility, centralization versus local autonomy argument will be the ones that

embrace the best of both with really strong governance.

Colin (22:43.899)

Yeah, all about the skills kind of in finding that balancing point. So you've got me thinking there about emergent capabilities. I think a lot of people maybe didn't really. I think a lot of people thought about Gen.ai is a bit gimmicky and something that would maybe replace how-to books, like how to take up fly fishing or something like that, how to make a lasagna. And now you just you might just ask AI for that. But actually.

Chris (22:52.354)

Yeah.

Colin (23:11.239)

building services and functionality that you might otherwise have to procure maybe a bit more SaaS than what you needed is kind of an emerging capability of AI. Just at this early stage at the moment, it gets me thinking about, we're talking about how to design a growth system and specifically the technology side of that.

Chris (23:20.43)

Mm.

Colin (23:33.779)

And we've talked a lot about change and how the SaaS market is changing or how the technology markets are changing. So I guess that a system approach really has to anticipate sort of emergent needs in a technology stack.

Chris (23:52.172)

Yeah, it's such an interesting point that because I think viewing the sort of, viewing the sort of emergent needs point through the lens of architecture, not the buildings, but of systems, different architecture styles are inherently more

well suited to having kind of to anticipate emergent need as you put it. Using something that is modular, using something that is kind of API first, using something that, you know, for the techies out there uses sort of microservices architecture style.

that is inherently much less fragile, much more scalable, because it is a sort of decentralized architecture. So what do we mean by that? For anyone that's, you know, not a not a dev or not a techie anyway? Well, ultimately, it's thinking about the way that we compose our tech stack as not being

what monolithic solutions are we going to buy? You know, are we going to buy Salesforce, then we're going to buy every module in Salesforce, and we're going to build everything on top of that. And actually having a sort of API first architecture means that we can buy lots of little things and stitch them together. So people talk about that as being kind of composable architecture being about sort of composability. So

I mentioned a second ago a product we had for our lead management accelerator and that uses about six different applications stitched together and you interact with them all through Slack. So it's a really interesting view because when you have a sort of modular architecture when you're using something like an iPaaS tool

Chris (25:55.702)

to stitch everything together, then actually your ability to add things in is much greater, your ability to take stuff out, to swap things out, you can surface all of the information that you need through the architectural pattern that you're using. And I think that that point about data is really, really key when we're talking about planning for emergent need because

I guess going back to AI, I think there is a rapidly coming kind of truism that you can't have a good AI strategy without a good data strategy. the more data you can centralize, i.e. have accessible in every place, the better you can leverage AI, the better you can...

Colin (26:42.035)

Thank

Chris (26:50.422)

enable future use cases by ensuring that you're kind of harmonising all of that data and also that you're putting a thought into the number of data points that you need to collect and you're concerned about granularity. I think that historically

when people have built point to point integrations, they've just thought about, what data do I need for the use case I'm building now? And let's only take that. And I think that you, you know, with that sort of emergence kind of mindset that you mentioned, actually, the gold standard is probably having a sort of...

having that sort of data centralization point, you know, building in kind of data extensibility so that we can have lots of data flowing into lots of places, either into kind of a central data repository or actually just that we're building that into the way that we view our architecture patterns or the way that we're building and architecting integrations. Because ultimately, if you can make all of the data accessible everywhere, then

you'd have no limitations on what you can then do with it. Because ultimately, data is what we're talking about here. What is running through your SAS tool? What is running through your integration platforms? What you are feeding into your AI tools? It's all data. Data is everything. So having a forward-looking data strategy and ensuring that you've got

everything available everywhere enables you to, you know, is enabled by having a sort of microcyber style architecture where you've got everything stitched together, you know, in integration platforms. think having that sort of integration first mindset is the best way to kind of plan and sort of future proof the org, because it means that you're never cutting off a path and you're never becoming too dependent on a single vendor.

Chris (28:53.684)

and therefore you are in charge of your own future. You you're kind of in control of your own destiny, if you like, in terms of how you're managing those, you know, those kind of infrastructure questions in a way that if you've hitched your wagon just to a Salesforce or just to a HubSpot.

you're invariably not or at least not unless you're willing to pay, you know, the next large amount of money for whatever the upgrade is that gets you the one feature that buys you the thing you want to do, which is historically been the case. So sorry, that was probably a bit of a rangy answer to a simple question.

Colin (29:29.101)

Hahaha, yeah!

be thinking about a few things that got me, that kind of led to me thinking about sort of collaborative ownership of infrastructure decisions. Like first of all, it's all kind of very well thinking about, we need to capture granular data points. But I think if that's left up to a specific, just a data team or an IT team or something like that, they don't necessarily have the sort of domain knowledge of the line of business. And so they need to be involved in kind of

a game of predicting what data may become useful further down the line. And that brings you back to sort of questions about governance and structure relating back to last week's episode and kind of collaborative ownership. And then also another thing that kind of reinforced that for me is as you were talking about, you know, if you've hitched your wagon to one particular vendor, blah, blah, blah, right. So sorry, I don't mean to make you sound like blah, blah, blah to me, know, like Charlie Brown's teacher.

Chris (30:31.288)

There was definitely a bit of blah blah blah in that.

Colin (30:33.043)

Yeah, but often it's one department or one function with an organization wants to hitch its wagon to say HubSpot and another wants to his wagon to Salesforce or, you know, one development manager who really, really wants to keep hold of integration, even though that costs his team loads of time and money. But, you know, everyone else in the business wants to have an iPaaS tool, such as you talked about, which would kind of

know, free up the developers time. I've seen all that out there. I guess there are this kind of I guess it can turn into competition between different parts of the business over who gets the sort of technology that they want. And so I guess something that you need to build into your structure and into your system is really that infrastructure decisions can't infrastructure as we are defining it can't really be left to.

to IT or one department alone. Like really, if you want synergy across B2B growth initiatives, then sort of collaborative ownership is really the way to go. I think I've done it as well, like going on too long about that bit.

Chris (31:44.515)

Yeah.

Chris (31:48.586)

I mean, governance is inherently not very sexy, is it? But you know, and but I think that governance can evolve in terms of how we view it. think infrastructure governance, IT governance, you know, historically has been the sort of IT

you know, computer says no fun prevention place of the business. Exactly, exactly that. And actually, I think we need to change the way that we view governance as a topic. Now,

Colin (32:19.965)

The Ministry of New.

Chris (32:32.538)

I think that you could say that having some sort of cross-functional ownership where everyone has a seat at the table to make technology decisions sounds like a good idea. For me, I don't really buy that because most people in line of business roles, okay, they've got domain expertise and that needs to be listened to, but they definitely don't have IT expertise. And therefore they will typically default to things that they've used in the past.

or distract themselves from whatever they're supposed to be doing, going and shopping the market. And I don't think either of those is particularly desirable. My view, and I do have a slightly biased view, it has to be said, that rev ops is the answer to this. rev ops having some sort of, know, rev ops should not become the new IT team.

you know, it needs to act in a different way. It needs to incorporate that domain expertise and the people employed within that rev ops team need to themselves have the domain expertise. And I think that is the, that is the sort of the rev ops dream really is that you've got people that have typically come out of those line of business roles or come out of those sort of sales and marketing ops roles where they do have a deep understanding of what happens.

within the functional areas and they do have the expertise of what they're doing, they're doing. But it does still give you the central ownership view. And the one thing I would say here, particularly or stress here is rev ops can't just be sales ops that someone's just rebranded rev ops and they still report to, you know, the head of sales that

that's not what rev ops is. Rev ops, I think needs to have a seat or needs to report into a part of the organisation that transcends the entire growth team. Now, if you're in a fairly forward thinking B2B organisation and you've already have a united growth team, which is both sales and marketing together and they're reporting into a chief growth officer, then great, rev ops should report to them.

Chris (34:49.07)

if your organization isn't there yet or has no wish to be there for whatever reason, I would say rev ops needs to report into operations or it needs to have representation.

at near board level, because it needs to have the power to make decisions and not be, you know, bullied into particular agendas by by functional teams, but equally needs to be listening to those functional teams. So it's something that, you know, whether you call it rev ops or not, everything I've just said there, I think ultimately is the is part of the answer to that sort of collaborative ownership of IT decisions in growth.

I think the other point, you know, I mentioned governance at the start of what I was saying there, you know, there is no inherent sort of governance in centralization. But actually, I would kind of go back to the point I made earlier around sort of democratization of some of the things that you do with IT. Now, I think that the purchasing decisions, probably it's best if they are centralized, particularly when it comes to applications.

but automation, know, AI agents, just to a certain extent. I think all of that needs to.

be democratized within the organization. I think you can move further and you can move faster. And the governance for that needs to evolve to this new reality that we currently live in. And I really like the sort of center of excellence view of the world where, you know, create champions within the org. You know, we have

Chris (36:34.19)

subject matter experts, all kind of domain experts for particular things like automation. We do training, we certify internal developers. I've seen lots of different views or ways of going about that kind of center of excellence piece. But ultimately, I think we need to embrace democratization within kind of the growth team, IT, growth team infrastructure, because it allows us to move faster.

And I think that when you do that, you also get another self-selection. know, the people that are inherently quite well suited to that are the ones that go the distance in terms of doing that. Everyone might want the keys to the automation tool, but maybe, you know, don't actually go the distance in terms of, you know, developing that expertise and utilizing it and maintaining it.

But if you kind of build the framework to ensure that you allow people to have their hands on the tools, but you make sure that they are properly certified to use them in the first place, then I think you can, you then you've got the most robust approach to kind of infrastructure governance and kind of collaboration of purchasing and decisions and sort of ownership and use. So I think there's...

I think there's a lot of change coming in this area and we see organizations embracing that at different speeds inevitably, but I do think the sort of picture I've just painted, certainly in the mid-market and below, is what good looks like to my mind.

Colin (38:01.619)

So interesting, a lot of what you were saying there got me thinking about sort of how we can use technology to empower individuals and groups within the organization. But then it got me thinking about some of the kind of half-baked realities of this that have been involved in where as employees we're maybe given really powerful tools and this kind of sense that we're sort of being allowed a little bit more ownership and sort of

creative license, I guess, as to what we can do with them. then typically training and support might lag or we are just overwhelmed with like, you know, another couple of new tools every couple of months. I know, I guess there's a kind of a missing link in that we are never really, and this is an experience I've had a few times, we've never really been enabled to kind of integrate

the tools that we now have greater autonomy over into some new way of working effectively, which is a shame because of course adopting new tools can really sort of genuinely shape culture and work habits and sort of flatten hierarchies and all the breakdown silos and all these things that we talk about. But I have of course seen it go the other way as well.

Colin (39:48.955)

Sorry Chris, you've been on mute since I started talking. I this is one we'll need to edit.

Chris (39:53.966)

I've been coughing away. I think that whilst I have no evidence whatsoever to support this point of view, I suspect I'm probably right in saying that in the last 10 to 15 years, the skills required to be good at business, particularly to be good at sales and marketing have fundamentally changed. And the reason they have changed is because of the pluripotency.

proliferation of kind of different tools and applications that have been bought into the day to day of being a seller or a marketer. And, you know, I, I really like the sort of Scott Brinker kind of Martek map things and, you know, that I think I used to know these numbers off the top of my head. I don't anymore, but I'm pretty sure that in 2010, when he first started doing that, those maps,

there was something like 110 tools in the sales and marketing category. And last time I looked at one, there were over 14,000. And sometimes we go into organizations and it appears that they've bought all 14,000 and they're people to be able to use them effectively and to get value from them and to generate an ROI. And as human beings, I just don't think we are really equipped to do that.

Colin (40:57.989)

Yeah.

Chris (41:11.086)

And, you know, that, that for me is a really big issue because when we, um, you know, have such a large amount of tech that lives in our day to day, you just overload employees. And I think whether you've provided great training or not, I don't think the brain, you know, that is actually, um, equipped to just continually switch between different applications and expect to be great at using them and get value from them.

In fact, I think there's quite a lot of research about context switching. I can't remember what the number is. might, Colin, I'm sure we've talked about this before, but is it 20 minutes? the average time to regain focus after switching it?

Colin (41:53.779)

I'm sure I saw something like 21 or 23 minutes or some awkward sounding number like that. I'm sure it takes me longer anyway. I'm sure it comes as no surprise to you. Any excuse to to of fragment my attention and it's kind of sucked me into something else. But yeah, I said this is something I struggled with enormously. Like I remember sort of like trying to build a workflow and a previous job where I realized there's kind of context switching between like...

Chris (42:05.154)

But it.

Colin (42:23.951)

like seven different applications and tools just to do a simple workflow. And some of these are things like, know, something might be something simple as like at the time it would maybe outlook or something. And of course, a context switch into that and, someone sent me an urgent email. This probably says more about me and my lack of ability to focus. But you know, director sent me an important email or something. And I might just open that quickly just while I'm in the middle of this.

Chris (42:27.266)

Mm.

Chris (42:40.782)

Thank

Colin (42:50.191)

It might not be that, but there are any number of reasons why. To be honest with you, I think in fact, just switching to a different user interface can be quite disruptive, actually, like cognitively. Like it's not very well having a laugh at me, not getting distracted, but I think there's...

Chris (42:59.81)

Yeah.

Absolutely.

But it's there, you know, it wasn't just you that participated in the study with both red. So I think I think you are clearly not alone there. mean, but it's, you know, it's systemic, because if you think about if it takes, you know, if it takes 20 minutes, I mean, if it takes 10 minutes, and I think what we're talking about there is not like you can't do anything for 10 minutes, but just actually to regain deep focus after you've switched from one tool to another and actually like

Colin (43:11.229)

Mm.

It made me feel sad.

Chris (43:34.126)

reorientate your brain to the new task. I see so many stats and I don't think I've ever seen two studies that have had the same number. But I think what we can say is the average tech stack in a mid-sized business is massive. 75 to like 120, 130 applications I've seen in different studies. I enterprise often use over 200 bits of tech managed by IT.

And okay, not all of these are available in every team, but I think that a great many of them, I think, think sales and marketing particularly have very bloated text acts these days. And if you're taking 10 minutes, even minimum, you know, to, sort of switch focus and you're surfing between, you know, 20 to 30 tools, perhaps in the go-to-market team. And I think that's, don't know, maybe that's conservative. I mean, like it sounds like loads, but then you think, you know, I just in my

Google Chrome, like just in Google services, you know, I'm between sheets and pages and slides and my calendar and my inbox. you know, that's, that's just like every hour of every day. And that's five. And that's before I get into, you know, using HubSpot, using Slack, you know, use it just like, if you start thinking about it, you're like, yeah, 20 to 30 is easy.

Colin (44:40.955)

yeah good point

Chris (44:59.742)

easily 20 to 30. You know, there are eight hours in the day, takes me 10 minutes to kind of, you know, regain focus when I switch between them. When I'm doing deep work anyway, okay, you're not doing deep work in all of those tools. But you can see actually the impact on productivity is gonna be massive, absolutely massive, you know, times that across an organization with 500 people, 1000 people in it, know, that over a country, I mean, just like how much downtime is is the proliferation of SaaS causing? And

I think that it creates a sort of mental load. You know, we talk a lot about mental load, don't we, in the modern world. And I think it is down to this sort of context switching, the sort of decision fatigue that we get from just having to do so many things in so many places. And the human brain is like, I know this is not strictly on topic, but someone was telling me about kids TV.

And apparently, probably when when many, many years ago when you and I were were were children and watching our own kids TV rather than our kids kids TV. The time between frames was apparently about 10 times longer than it is on modern kids TV shows. Now, really rapid cuts on everything and it it it causes children supposedly not to be able to focus, you know, it does something actually chemically to their brain that

that kind of leads to lack of attention, lack of focus. And it seems like the same in growth teams. Coming back with the link, if we were switching between 20 to 30 tools, we're rapidly cutting between all the different frames on our screen, or in my case, three screens that I've got on my desk.

Colin (46:45.725)

Yeah, I've got two of them. We've got five screens between us with all different things on and different tools on it right now. Yeah.

Chris (46:53.01)

Yeah, exactly. In fact, I can just see on my toolbar, I've got one, two, three, four, five, six, seven, eight, nine, 10, 11, 12, 13, 14 things open just on my task bar. And that's, that's accepting the, you know, my usual 300 times I've got open. So yeah, it does, it's got to do something to the brain. It certainly does something in terms of kind of creating a massive cognitive load and

I think that that's a really big human problem that we have within growth teams that's caused by infrastructure fundamentally bringing it back into the episode.

Colin (47:29.809)

Yeah, I mean, I'm going to take it slightly away in the way that I usually do, again, where this stuff about cognitive load and effectively decision fatigue, i.e. the consequences of overwhelming cognitive load, is fair enough. It may affect your bottom line if this is your growth team we're talking about. But this is a really big sort of serious area of study, for example, and it won't surprise you to learn I'm going to say in the military.

If you look at how military units are structured and the various responsibilities are divided up, one of the key guiding principles is to not overwhelm the individual's cognitive load. And don't get me wrong, very experienced officers and things are expected to be able to handle egregative cognitive load. But that's effectively why these things are structured the way they are. And because this is a life or death problem now.

Chris (47:55.263)

Yeah.

Colin (48:25.531)

OK, we maybe we're only talking about the life or death or the health of your business. But just in case anyone thinks this is a thing that we and some systems thinkers just like made up because it sounds good talking about business growth. No, this is a sort of serious science that sort of lives depend on. And we should we should take it seriously. And I think there really isn't enough focus on this area called cognitive load and decision fatigue. And it kind of brings me back a little bit to what we were saying about structure.

last week but then also super relevant is this infrastructure area.

Chris (49:00.396)

Yeah, 100%. And I think that, you know, we talk about if, if the growth systems are all really fundamentally about creating a more efficient growth team, a more efficient organization, the less time your sellers and marketers can spend managing technology, rather than actually creating value with it, clearly the better. And I think that

the changing kind of nature of IT is starting to present some options there.

Colin (49:39.569)

So something I thought we might just slip back to just very briefly was that you were kind of talking about how different teams will sort of gravitate towards their preferred tools. The classic example, SalesLives and Salesforce Marketing and HubSpot or Marketo, for example. And we start, maybe the data becomes siloed or doesn't agree. And we start to see organizations, they don't really use the same vocabulary to describe what they're doing. And we see this kind of

this divergent alignment or the creation of misalignment, what called tool tribalism where collaboration becomes harder and actually shared understanding becomes reduced. I think that obviously has an enormous impact downstream on sales cycles and handoffs and any kind of friction point that

I guess affects the buyer's experience and ultimately is going to affect your bottom line.

Chris (50:42.529)

Yeah.

Yeah, absolutely. mean, the amount of times during a week that I have to sort of mentally switch between using the phrase companies or accounts, just speaking to different ones of our customers, depending on what their tech stack is, is quite considerable. know, it's having a cognitive effect on me. But yeah, that I think is really the argument for

degree of centralization is that this sort of, you know, tribalism, as you put it, doesn't do anybody any good. but I suspect it's also a sort of a sort of human response to the stuff we were just talking about, like, I can only deal with so many apps, you have any deal with so much context, which is I'm actually just going to put my arms around these ones, I understand, and I'm just going to try and do everything in there.

so I think that maybe that's quite a sort of human protective kind of reaction to this problem. And rather than it being about, you know, being territorial, but, I think we could probably all agree that the less of that stuff that has to happen and the more time we can spend creating value for the organization and for its customers and prospects, the better. I think infrastructure needs to be an enabler of that, not a, you know, not a detractor.

Colin (52:09.285)

Indeed. guess that brings us on. We're running out of time a little bit, but I guess we need to have a think and a chat about how we actually solve for things like context switching issues, text act fragmentation, tool tribalism and all that bad stuff.

Chris (52:24.558)

Yeah, yeah, I mean, if we were having this conversation today, two or three years ago, then then this would be a slightly shorter conversation, because I'd really just be talking about the quality of integration and kind of data harmonization and data centralization that

And that is still absolutely the case, you know, the more information you can surface in the tools where people spend the most time, the better. And I think that a really good example of that is CRM being the sort of

cornerstone of the sales and marketing org. know, it is the place where we keep all the information about the people that we have sold and would like to sell things to. So the more work you can do in that system to optimize it for the job at hand, and the more information you can surface within the sort of contacting company records within that system, the better because the less people have to go looking for stuff in other places. And I think crucially, and it's a real sort of, you

hobby horse of mine at the moment is the role of signals data. The more stuff we can put into the center, whether that is ad interactions or intent or website de-anonymization or any number of things that exist out in these hundred plus applications that we're all using, the more we can put that together and start

deriving intent and propensity to buy from the overlaps in that data the better and the only way you're to do that is by centralizing that data. So I think that, you the first route is get everything in the CRM and get people interacting with the information and deriving value from the information in the place where they spend the most time, which inevitably is the CRM.

Chris (54:37.198)

What is now I think increasingly possible is the sort of, I don't know what to really call it, the sort of single interface view. It's something that we spend a lot of time thinking about and building solutions for is being able to actually, slightly contrary to what I've just said, but being able to integrate, sorry, being able to interact with things like CRM through Slack or through Teams, know, being able to surface leads.

or surface signals information in a Slack channel and then being able to interact with that.

You know, this person's just filled in a form, you know, I've gone and enriched it. You know, do you want to excels accept this? Yes. Just click a button in Slack and it puts it into CRM and it changes the life cycle stage and it appends bunch of information. You know, would you like to send them an email? Would you like me to write you one? Okay. Let's go send some APIs off to, you know, chat GPT or whatever. And, and, you know, let's, let's go access our, you know, custom GPT for writing sales emails in our style. And, and, you know, post that back to CRM.

to send or indeed just send straight out if that's what you want to do. Increasingly, the single interface view is enabling more and more interaction without context switching. I think that is quite an exciting area, at least in my particular opinion.

Colin (56:04.467)

It's like adding one more tool in to do the context switching for you.

Chris (56:09.294)

Yeah, exactly that. It's sort of, yeah, one tool to rule them all. I think that there's a lot of value to be derived in doing that. But inevitably, if you start doing that, you have to make sure you're doing it well. And because a lot of that sort of rich information, a lot of that contextual information,

bit like what the point I made about, you know, pull when people build point to point integrations, they only sort of pick the things they need for the the particular use case. If you surface information in chat, for instance,

and only bring in the very, few things and they're going to lose context. They're going to lose kind of the ability to see what else is going on. Do we have service tickets open with that customer already? You know, do they have deals open with other departments, all that sort of stuff that you see if you're in a sort of CRM view, for instance. So definitely there's huge amounts of value there, but it needs to be done and conceived right. increasingly, I think that the

the of the rise of the AI agent. It's probably a title of some of the book, isn't it? But I think that is is changing the game. Yeah, it's probably one we've written, but it's something that I think is going to change the game again. And we sort of alluded to this earlier on in the show that

Colin (57:20.787)

Probably is already.

Chris (57:36.746)

I think that we're going to see a falling away in the number of applications that need to be in the stack as AI and kind of agentic sort of applications, if you want to call them that, become more and more advanced, become more and more adopted by organizations.

if you can just build a load of agents running in the background that then just surface stuff in Slack or do the things in CRM, then actually the requirement for context switching is less and less. I think it's kind of integration plus, rather than having to architect static integrations, we're gonna be able to start, can indeed already have, are able to start having kind of natural language.

sort of having a conversational relationship with the technology where you say, well, actually, well, I'd like to know this or I want you to do this and then it being done and not then having to go to an interface will learn a new thing. So I think if you're in niche SaaS, that's probably quite scary. I think if you're in a sales team and switching between 30 applications every day, I think that is entirely good news. So yeah.

Colin (58:49.295)

light at the end of the tunnel. So are we past peak context switching then do you think?

Chris (58:57.166)

I think we're past peak sacks, so I think we must be past peak context switching. But there's obviously going to be a fairly long tail on on you know, the way that the market right sizes itself as you know, AI energetic adoption.

increases over the next kind of, you know, one to five years. I'm not sure really whether it's going to be one or five years. I mean, typically, you would say that these things have a reasonably long pattern. I think increasingly, the rate of AI adoption is probably surprising even people in, you know, in the center of the AI industry. So yeah, we will see.

Colin (59:36.691)

I think a whole other topic, and I don't know whether or not it would be appropriate for the growth system is that we don't actually know the level of AI adoption within sort B2B or within business because a lot of it is effectively shadow AI, people putting out content which is written using Gen.AI. I heard a story about a government minister asking the...

like chat GBT for like policy advice, which is just terrifying. Even if he was just, you know, even if that story's blown out of proportion, that's very worrying.

Chris (01:00:07.47)

You

Chris (01:00:18.678)

Yes, yes well I'll be setting the policies anyway so it's probably you know just a shortcut.

Colin (01:00:29.137)

Yeah, well, I for one, welcome our new robot masters. Just saying that as a disclaimer, to be honest. Chris, unfortunately, this is quite a deep talk. Maybe this is why we sometimes shy away from the technology side of things, because it is a bit of a rabbit hole. We're past the hour mark, and we do really need to wrap up. As I say, this is really a...

Chris (01:00:36.942)

Yes, I'd like it to in the minutes.

Chris (01:00:49.102)

Hmm.

Colin (01:00:56.881)

you could go down a rabbit hole on this one. think what was really interesting for me was thinking about this from a systems view as more than it. I guess in much of my career, was typically talk about the IT stack and that kind of, that makes you envision something that's quite static rather than as this sort of adaptive core. I really like just a biological analogy earlier of the,

Chris (01:01:16.728)

Mm-hmm.

Colin (01:01:26.035)

the nervous system, something that can adapt and change over time, like a living ecosystem effectively, and that kind of changes the way we think about it. But yeah, I wondered if you had any more specific than my sort general rambling final thoughts on that.

Chris (01:01:43.022)

I think that we need to start viewing growth team IT, know, the tech stack in a different way. I think that attitudes to technology and the human relationship with technology needs to be top of mind when architecting the future of the tech stack within the growth team.

And I think all too, for too long, the people who have actually got to use the tech have been too marginalized in the decisions to purchase it. think that in many ways, one of the things that got me really thinking about systems thinking way back when was, was just the fact that so many growth team, senior growth team people tried to solve problems by buying tech. And

they weren't thinking about the system. And in many ways that was really the genesis of where we are now in terms of how I think about the world, how we think about the world as an organization. And with the rise of AI, the entire tech landscape is already changing and it's changing rapidly. And I think that we need to let go of the way that we built tech stacks before.

the way that we just acquired tooling for everything. I think we need to kind of rethink with the human in the center and we need to have a, you know, a sort of process automation mindset to the way that we go about enabling the human beings in our business to be successful with technology. So.

Chris (01:03:32.268)

Maybe that's a bit of a sort of philosophical endpoint rather than one about sort system adaptability. But I do think that prioritizing the human in the system is the key to creating successful infrastructure.

Colin (01:03:46.673)

Hmm. I guess understanding the organization as a system and how the humans in the system interconnect with everything else is super important. And you're right. think that that's the lack of taking that sort of viewpoint that's probably led to this, let's just buy another tool to solve the problem kind of mentality, which is created as of probably not being too dramatic to say, mess.

Chris (01:04:13.027)

Yeah.

Colin (01:04:15.601)

that we are.

Chris (01:04:17.654)

Yes, it certainly made a lot of people in the systems integration, you know, in the sort of global SI space, you know, a lot of money, but sadly, for them, I think that needs to stop.

Colin (01:04:30.139)

Yeah, yeah, they need to find a new racket. No offense to all the many people I know who that's what they do for a living. So next week we're sort of diving into I think the last of the kind of operations sort of a line section of the the G-TOS dimensions that we're going into sort of more into that sort of rubber meets the road side of the operating system into kind of processes and

Chris (01:04:36.75)

Thank you.

Colin (01:04:59.507)

I guess what we call workflows. So looking forward to getting into a bit of that with you. But I think that's definitely all we have time for for this week. So all that's left is to say the growth system is brought to you by us. That's RevSpace. We're a growth systems consultancy. We connect B2B organizations with the future of growth. So we 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 we'd really appreciate your moment, a moment of your time as always to give us your feedback, tell us what you think. That's all we've got time for this week though. Thanks very much. Bye bye.

Chris (01:05:41.454)

Thanks for listening.