Colin (00:01.496)

Hello and welcome back to The Growth System, the podcast where we view B2B growth through a systems thinking lens. Today we're going to focus on collaboration, the 10th dimension of the growth team operating system. So we're going to explore what collaboration actually means in a growth context and why it's the key interconnection in a growth system and how we can future proof this vital part of the system.

We'll explore operational rhythms, cross-functional teaming, is a subject we've kind of delved into through various dimensions as we've gone through this, most of them I think, and even the impact of AI agents on collaboration. So stick around for that hot topic. For our purposes, I think we should really define what we mean by collaboration.

how and when people come together to coordinate daily activity and share information. it's fairly simple definition. It might be short daily stand-ups or water cooler conversations, Slack interactions, strategic summits, really anything in between. And it's the quality of this collaboration that can drastically shape a company's ability to grow. So it's worth emphasizing that collaboration is not just about

meetings, as we always say, is about structured interactions that lead to concrete and meaningful outputs and decisions. So Chris, collaboration can sometimes feel like a buzzword. I know I've been at companies where I'm sure being collaborative was one of the stated values, which and the values, but essentially like a poster on the wall. So what do we actually mean by collaboration in a systems thinking context?

Chris (01:53.789)

Yeah, well, think collaboration is not quite as bad as the word system, but I think it is a word that's being somewhat appropriated by the software market with, you know, teams and, you know, Slack and stuff being collaboration software and that being a whole category. But, but yeah, absolutely. In a systems thinking context, it's really, as you kind of said in the intro, you know, it's a key interconnection in a system.

So a system, as we know, as we've talked about many times before, is composed of purpose, elements, and interconnections. And collaboration really sits firmly in that sort of interconnections category. And a business is, of course, a system.

And the flow of information around that business is predominantly, although absolutely not exclusively, through people. And collaboration really is the kind of catchall that we use for that sort of flow of information around the organization. And of course, high quality collaboration, high quality interconnection of information has emergent benefits. And for me, I think the...

The interesting thing, I think, when we get into interconnections is that they are in many ways the least obvious, but most important part of the system. And that's because when we think about systems in general, when we think about the structure of systems, we talk about emergence as something that's being more than the sum of its parts. And really, the way that emergent benefit arrives is through the structure of the system and what

in many ways defines the structure of the system is how it's all stitched together, what those kind of, you know, I'd say those kind of points are between the different elements. And collaboration is really one of the things that can be a massive value accelerator within businesses, within systems. And for me, as we think about that sort of conduit where information flows around the organization, then

Chris (03:55.869)

With collaboration, we've got a really strong causal relationship with emergent value, which is a slightly complicated way of saying the better we collaborate, the better the organization works, the more value we create for customers, for shareholders, because that lifeblood the organization information is flowing around and creating actions, creating downstream effect more readily and at higher quality. yeah, in a nutshell, it's a super, super important topic we're covering today.

And I think when we kind of go a little bit deeper, one of the reasons that it's so important is that collaboration as a sort of catchall for the sort of human connections in the system forms a really strong reinforcing loop. So ultimately, the more effectively you coordinate, the better the results you get.

the more your team is motivated to kind of keep collaborating, keep coordinating information. So you have this kind of reinforcing loops that, you know, when it works well, you know, like all human connections, great human connections, great human relationships, if we want to call them that, foster stronger relationships, you know, you have this kind of human incentive to keep doing it, to keep doing it better because it's being productive. It has this kind of immediate reward effect that's quite clear.

But also actually on the flip side of that, it can also trigger balancing loops. So as we'll try to talk about, collaboration is not just a casual for meetings. But if we do zoom in on meetings, I think we all can have experienced too many meetings is not good either. So, you know, we shouldn't kind of create collaboration as just being a byword for meetings, but ultimately too much time talking and not enough time doing is

arrests value creation. It's something that holds the organization back. So whilst it's there as a massively strong reinforcing loop, it needs to be done right to create that value. And we can't just tie people in knots talking to each other and sharing information. So really, that's the kind of crux of the episode today. What does good look like? know, if we know that inherently, we all know, you know, collaboration is a good thing. I don't think there's really going to be anyone out there arguing with that. But there are pitfalls.

Chris (06:18.735)

And that's, think, what we're going to explore a little bit today and explore a little bit how to perhaps look after those, sort of look out for those and work around those. And I guess probably just one thing to add to that sort of human-centric, maybe meeting-centric view we've painted is that technology has a big part, as we sort of alluded to in the intro, has a big part to play in how collaboration works. So Slack teams.

dare I say, email, and plenty more things besides these days, all have a role in how we share information across the organization, both synchronously and asynchronously, as we'll talk about in a little bit. So it's a fairly rich topic. It has always with us touches on a bunch of other topics. But it's a massive value accelerator if you get it right. So it's a good episode today.

Colin (07:11.854)

Yeah, Chris, we often talk about sort of organizational inertia, like a systems resistance to change. I guess if you're I think we've probably all seen this. If your collaboration channels, Slack, email, face to face, too many meetings, it's kind of clogged or misused. You're kind of intensifying that inertia. And I think conversely, you use this.

one I think conversely good collaboration is essentially like oil in the machine, like it keeps knowledge flowing swiftly and actually reduces friction as does oil in the machine. It's sort of allowing the organization to adapt more readily. I really like that visual as the oil in the machine. thinking about

the system is a machine that can break down. What are some sort of real world connections that, sorry, real world signs that interconnections aren't working?

Chris (08:16.265)

Well, I think a strong indicator when things aren't working is ultimately things just taking too long. Action not happening. Now, you don't want to be hasty, but ultimately, organizations where simple tasks, approvals get stuck for days, weeks, particularly when you're looking at kind of...

multi-departmental workflows, that kind of have multiple stakeholders, things that get kind of ping-ponged around where you haven't got that sort of ownership. I think that is a really sort of strong marker that you've got a sort of collaboration issue, you've got a structure of collaboration issue. I think that something that also I think manifests itself is kind of through inconsistency of information.

something that we don't see quite so much anymore, but sort of historically, you would see different departments with different versions of the truth, different reports, because they've got a report happening in their silo, and that clearly information wasn't flowing freely or wasn't up to date in different areas. So you would see kind of misinformation, incorrect information kind of flowing around.

think we already alluded probably to a big one is actually kind of excessive meetings without purpose, without resolution. You know, I think if you've ever sat in a meeting and thought, why the hell am I here? And indeed, why is anybody here talking about something that's not going anywhere? You know, that is that is the reddest of red flags. I think that you've got a serious problem because not only are you ineffectively communicating, but you're also wasting time that you could be spending doing other things. I think all of this kind of acts in

In a system concept in the sort of limits to growth archetype, you know, when you kind of got stuff like this happening, you can sort of see that and the sort of organization might have hit some sort of growth ceiling, you're struggling to get to the next level, you're struggling to kind of reinvent to kind of move past a plateau, then actually you've probably got quite a lot of internal friction. And whilst that's not all about collaboration, it's generally a good marker because

Chris (10:34.929)

If nothing else, collaboration is how you get to a future state within the organization because you've got to collaborate to enact change. So, you know, I think there's a whole bunch of stuff there, but ultimately, what's the phrase? know, when you know, you know, I don't think you need to necessarily spot the markers. You just sort of inherently know if your organization is not very good at that.

Colin (10:57.56)

think another one that we've probably all experienced, can think of a few examples, is the surprise crisis. if something suddenly goes badly wrong or last minute changes are needed and someone, like a key stakeholder says, I had no idea this was happening, that's probably a pretty clear warning that collaboration is failing,

Chris (11:21.589)

Yeah, I think it's a good point actually, because collaboration is easy to kind of think of collaboration as being horizontal. You know, people in the team talking to each other, but actually collaboration is vertical as well. Yeah. How are we working up and down the organization? How are we reporting information up to the leadership team? You know, what is throttling that information? You know, I think that's actually a really good point you raised there.

Colin (11:48.256)

So that's kind of what bad looks like. And as you see, it's one of those things. You kind of know it when you see it in any case. But I think less obvious is what good looks like in this case. So what does good collaboration look like? I guess it's a good time to go into the sort of what we see as best practices for collaboration in the growth team.

Chris (12:11.379)

Yeah, I think it's really tempting when you talk about what does good collaboration look like to start talking about, you know, how that manifests itself, what good meetings look like, you know, what good flow of information look like. But actually, for me, I think it starts way before the operhythm and how we actually come together and exchange information. It is actually

as we've talked about quite a lot kind of in the deep structuring principles of the organization and something that is a, you know, sort of pet hate of ours, a pet project, if you like, is actually the sort of sales and marketing alignment piece. And ultimately that is a byword for talking about collaboration.

So actually all the stuff that we talk about when we talk about alignment, see we hit the word alignment much earlier than this in this episode. Yeah, everyone drink. The way that we orientate around goals is a really, really big part of that because collaboration has to be meaningful. And, you know, I think when we define collaboration, I mean, ultimately, I think we probably miss something from the definition. It's not something I

Colin (13:04.046)

Hahaha!

Chris (13:24.469)

my brain at five o'clock after having been at a conference all day is very readily able to come up with a sort of pithy sort of form of words for. ultimately, collaboration isn't just talking. We've all kind of been in a talking shop. Collaboration is not just two sets of people sat at a meeting table reporting on what they've been up to and going away. Again, collaboration has to have purpose. Like all systems have to have purpose.

Shared purpose is ultimately the cornerstone of collaboration because if we're not all trying to achieve the same thing, you can talk all you like, nobody is going to get you where you want to go. kind of having a shared view of the metrics, having a shared North Star, having kind of cross departmental KPIs that ladder up to the same thing, having shared measures between the sort of people who are.

collaborating on a particular project or whatever it might be a particular function. You know, that is a really, really good start because if we've got a shared version of vision of success, then ultimately we will intrinsically and inherently collaborate better because we are all aligned on where we are trying to go. We are not negotiating. We are not a committee. We are a team. And I think that's really, really important. I think there's an element around and

I don't know, it sounds fluffy, but you might call it kind of rituals, know, actually being in that kind of... No, mean, well, whatever works. I mean, I'm not, you know, I'm not blocked by that, but I think it really is down to kind of like having a process or having a sort of culture where, you know, you do get together.

Colin (14:56.492)

Not sacrificing anyone, are we?

Chris (15:17.557)

You kind of have a sort of collaboration layer, much like a piece of software does within the organization, where you prioritize it. You have a sort of structure for it. You have a sort of, I say this kind of like ritual where you have a culture of collaboration that exists within the organization and you're something you do regularly and it's just baked into the day to day of how you actually go about doing business.

And a lot of that, think, comes down to sort of openness and transparency around data, which I know is sort of a weird segue, but ultimately, you know, if you have shared goals and you have a shared view of the data and you have a sort of ritual or a culture of communication that happens within the organization, then data doesn't become currency in the same way as it can within many organizations. think data is often weaponized.

in some organisations, it's a mechanism for proving that our silo is better than your silo, that we're pulling our weight and you're not. It's a of a protectionist measure, it's a sort of defensive, you know, curtain around the org. And then when it becomes a currency, you know, there is no transparency. So if you have that culture and you have that shared view of success, then ultimately data sharing is something which is naturally part of that. And it

Colin (16:18.104)

point here.

Chris (16:41.853)

And ultimately it kind of fosters a proactive rather than reactive approach to collaboration because much like our example of the, I can't remember where it is, Benelux somewhere, know, the sort of electricity meters in the hallway rather than in the basement. You know, when we're all looking at the same data, when we have a culture that works there, ultimately we can, we naturally collaborate. don't have to force, you know, you don't have to force the issue. Like everyone's seeing the same thing, everyone going to the same place.

know, cross-functional teaming collaboration just happens naturally. So I think that you kind of, you know, you remove the friction zones from the sort of process of collaborating from the reality of collaborating. And, you you kind of, don't make it complicated, you make it natural. I think that the...

The thing that as well, I think I'd probably note here as being part of that kind of like deep structure of collaboration as well is kind of role clarity being something that's dynamic. You know, we've done a bit of talking about racy and a bit of racy bashing before, careful how you say that. But you think about kind of dynamic role clarity as...

as something that's quite difficult to achieve. But because when you have a framework like a RACI, then you inherently set the sort of mechanism for collaboration, the roles that everyone plays and how they collaborate around a topic in stone. And once it's committed to his paper, and generally that piece of paper takes a really long time for everyone to agree on, it's really hard to change. And I think that's one of the reasons that I don't like it and we'll talk about it.

I think a little bit later if everything runs to plan, which it really does, but we'll see. And I think when you of adopt a framework like that, you have static roles. And in modern organizations, agile organizations, you need to think dynamically about the roles people play on individual projects, even at different phases of different projects, the same project. And I think that that's something that if you kind of have that kind of agile mindset built into how you kind of drive governance.

Chris (19:04.437)

in getting decisions made ultimately to simplify, then I think you're a lot better prepared for adapting to kind of market shifts. So if anyone could hear the banging, am in the, I'm right next to a building site and I've no idea what they're doing, but it's quite noisy.

Colin (19:23.118)

Yep, classic giga, I think you've got a nice apartment in southern Europe.

Chris (19:29.245)

Yeah, I came back all the way from the conference centre to be in a quiet place and I've, yeah, I've rushed back to an even noisier place.

Colin (19:37.262)

Yes, it's some interesting sound effects going on there in the background, to be fair. So, and I guess if we've got the deep structure right and everyone's pulling towards the same goals and the same metrics, then ultimately that promotes that more dynamic view of role.

clarity of specific what a specific role is. It's no longer static and I guess that that in itself kind of reduces the friction as one's role sort of ebbs and flows or one's level of responsibility and accountability within you know a specific project or program that you're working on right.

Chris (20:24.597)

Absolutely, yeah, if you get the deep structure right, everything else, you know, works a hell of a lot better. And I think that's, know, when you've got that right, that's no easy thing. It's a lot easier to talk about apocryphal than it is to do in reality, but, you know, no less important to try. Then you can start building an effective operative on top of that. So that kind of operating rhythm, operational rhythm, call it what you will within the business, is in a nutshell, essentially the cadence.

at which kind of teams converge to share information and make decisions. And, you know, it could be daily stand-ups, weekly planning sessions, monthly or project retrospectives. Ultimately, we're talking about the scheduled touch points where the system can self-correct. And that's a really, really important point. You know, this is not about talking. It is about sharing information, but not...

just for the sake of sharing information, this is not a broadcast. Anything that's in the operative needs to have really clearly defined purpose. So it's not enough just to have said we're going to have a daily stand up and we're going to have a weekly training meeting and we're going to have a monthly and we're going to have a quarterly offsite and whatever. If you don't really define the expectations and the purpose of each one of those meetings, then you might...

might as well not do them is probably a bit extreme. But ultimately, you really, really need to understand why we are coming together, what we are talking about, what decisions we are trying to make, what goals we have set, how we track those over time. The op rhythm is there to support the broader decision making and target setting of the organization. And it's there to kind of make sure that everyone is

doing what they're supposed to be doing and have what they need to have to get that thing done. So that's a really, really key thing. And I think a lot of people talk about that. Sorry, go for it.

Colin (22:28.45)

Is it fair to say that op rhythm or designing a sort of optimal op rhythm is at least as much of an art as a science, that you can't copy and paste the operational rhythm from another team or force something, a structure on a team that doesn't need it because it just simply won't work.

Chris (22:53.075)

Yeah, absolutely. That's a really, really good point. mean, lots of people talk about this kind of like three tier system, you know, daily, weekly, monthly. And there's a lot to be said for that. But, know, as you rightly say, as the banging starts again, that it is not a copy and paste job. You know, if something worked in one organization or in one team,

Colin (23:07.886)

Hahaha!

Chris (23:18.081)

or even just on the last project doesn't necessarily mean it's gonna work on this one. Now that's not to say that everything should be anarchy and you should throw the cards up in the air every time. But if you are in a really, really fast moving environment like a B2B tech startup, or you work in the London Stock Exchange last week, I think you probably want a daily standup to kind of...

ensure that you are orientated and aligned every single day. If you are working in a large legacy enterprise organization and you're working on a project that's got a three-year lifespan or you're doing something like implementing SAP, which might be a 25-year project or however long that takes these days, you probably don't need a daily stand-up, in all honesty. You just need to have really clearly defined roles and you probably need to get together every week.

ultimately start by understanding what is critical, know, where coordination really needs and is required, who is required for that coordination of activity, then actually when it occurs will probably be emergent from the understanding of, you know, who and what. So yeah, absolutely think, you know, good idea thinking, you know, daily seeks, weekly, monthly planning, annual and quarterly off sites, you know, all great stuff.

but you need to design a rhythm that works for your organization. And in addition, I think that that's also taking a very like synchronous collaboration centric, that's what I'm also the sentence, view of the world and actually asynchronous communication needs to be baked into that hop rhythm. And I think that's where...

the sort of relationship with the tech stack comes in and you need to again use your systems thinking mindset. know, there are lots of different parts to this. How do they all stitch together to achieve our purpose? But if you start with purpose, you're probably going to do all right here.

Colin (25:21.878)

Yeah, I think we should dig into the asynchronous communication, is our collaboration. I guess we should say in this episode because quite simply it's not sort of talked about and acknowledged enough, almost like that's just what goes on round about the synchronous communication. But I think before we do, it might be worth diving into the tools and tech just for a minute or so.

I think there's a tendency to think, we use Slack or we use Teams or we use Trello, you name it, like technology that can help you sort of streamline the operational rhythm and indeed collaborate. I think it's just worth pointing out that tools, the fact that you've bought the tool and people now know how to use it is not going to, you know,

unmuddy the waters of who's accountable for what or fix a dysfunctional team culture. should, the tools are there to sort of support the established rhythm, not dictate it. And I think sometimes we've seen that kind of the wrong way round.

Chris (26:33.455)

Mm-hmm. Yes, indeed. There's quite a lot to unpack there, isn't there? But I mean, ultimately, it's a two-way street, I think. There have been many times, I'm sure, where people have been in a meeting and thought this meeting needed to be a Slack message because it has so little content. But there's, I think, also plenty of times...

Colin (26:51.34)

Yeah

Chris (26:58.225)

so it's like for my own personal brain, but when you open Teams, you're like, there are 47,000 Teams channels in here and people are just broadcasting stuff into all of them. And actually that's an absolute nightmare because you've got to then go and, you know, trawl through all this stuff and work out whether there's actually anything of value in there that you need to respond to. And I think this really comes a little bit down to culture.

and a little bit down to kind of defining the parameters for collaboration in the organization, because I have certainly experienced scenarios where people think that having broadcast some information is the same as having collaborated. You know, it's the same as having communicated it. And for communication to work, of course, it needs to have a sender and a receiver. So just pumping stuff out into the... I think it's very easy for people to go, well, I...

put it in Teams three months ago on this, know, 4,000 people are on that no one looks at. So I'm all right. I communicated. Well, no, you didn't.

Colin (27:57.966)

Yeah, yeah.

Colin (28:05.974)

Yeah, that's not communicating at all. That's almost like if I was going to be really critical of that attitude, which I think we've all seen, I say it's pretty much magical thinking, you think because you put it on one of the 4,000 Slack channels that magically people have read and understood that before we next speak face to face.

Chris (28:23.433)

Yeah, it is the talking heads approach to communication. I've said something once, why say it again?

Colin (28:31.726)

Great reference.

Chris (28:34.773)

So, but yeah, mean, asynchronous communication, whilst it is certainly not a replacement for synchronous communication, does absolutely have its benefits. And I think it is ultimately the tool in which we're used to keep the balance right. And sometimes it's super important. mean, in today's world where, you know, even in our

pretty small business in the grand scheme of businesses. We've got team in three time zones now and asynchronous communication is really, really important because when we've got overlap, mean, we've got clients where we've got an eight hour time difference at the meeting tomorrow morning with a client that's in Australia.

asynchronous communication in those scenarios is absolutely critical. Effective asynchronous communication is really critical because when you're trying to coordinate things, you can't expect to do all of that synchronously because the overlap is so small often with those things that you've got to really build a good asynchronous communication framework. So I think that that's something that...

is going back to what we were saying about when you design an operative, it's got to work for the situation that you're in. But I think the really big thing, the thing that resonates with everyone with asynchronous communication is ultimately it reduces that kind of meeting overload of everyone's here just for the opening of an envelope. And that is a big, problem in a lot of big organizations. Meetings are a replacement for work.

and no one gets work done and all the work happens after office hours once the meetings are done. That is, as we said earlier, the reddest of red flags in terms of communication. So being able to push stuff asynchronously, being able to review and update stuff is something that is essential, I think. And there are a lot of organisations pivoting momentarily away from talking purely about asynchronous communication that

Chris (30:46.609)

actually recognize there's such a problem with the kind of meeting sprawl that they introduce, I think this is an Amazon thing where the first 10 minutes of a meeting with Jeff Bezos, everyone just gets to be silent and read the papers of what's going to you know, what everyone was supposed to know coming into the meeting.

And I think there's, whilst it sounds weird, I think there's something in that. I believe actually the bit of the story that I missed out there and I may be misrepresenting Geoff's view on this. If you're listening, Geoff, my apologies. But I think that what he asked people to do is basically submit meeting papers, you know, to do a write up of the thing that they want to talk about and then submit that to the group. And that's what they read at the start of the meeting. Now, I don't think that's something that's going to work for everyone, but it does speak to a discipline in actually having thought about why you want to be there.

And actually the meeting being important enough that you're to spend some time writing all of that down and equipping everybody with the facts ahead of the meeting so you can have a conversation about the decision, not about the learning, the information that you need to then make the decision. I think there's something quite important and quite meaningful and valuable in that as much as, you know, 10 minutes of silent meeting sounds kind of weird.

So that sort of pre-meeting information, I think, is a big part of the discipline of effective collaboration.

Colin (32:02.798)

Yeah.

Colin (32:09.454)

Yeah, we've always done it, you and I really, in this sort of asynchronous collaboration. And then when we actually get on to a sort of face-to-face conversation like this, or maybe sort of off air, then it's more, as you say, it's more about the decisions. We've both learned asynchronously everything that we need to learn. And then it's about making decisions or where do we actually disagree about this or something like that. And we don't actually need the...

10 minutes at the start to read what we were supposed to have read in the last week. So it's something definitely personal experience that's an experience of rev space that's sort of I would say best practice.

Chris (32:40.191)

Yeah.

Chris (32:48.839)

It just leads to higher quality kind of input, doesn't it? know, when everyone actually knows why they're there and they all kind of understand that, then you come into the valuable time where you're actually spending face to face, whether that's virtually or not equipped to make decisions equipped to.

ask questions to clarify understanding, not to get understanding. So I think that that's quite a key thing. I guess flipping back to kind of this sort of async piece, something that

I think is really, really valuable with asynchronous communication. It's something that we do with a lot of our client accounts in the sort of delivery part of the business is that a lot of that kind of collaboration with client partners is done asynchronously through our sort of PM, you know, client collaboration tool through kind of comments and sort of chat messages. And what is great about that is that

It kind of creates documentation by default. So everyone's got a record of the conversation, of the discussion, of the rationale.

it can be picked up by anyone in the team. you know, synchronous face-to-face communication, even when, you know, these days you join a meeting and there is as many note takers as there are people. And I'm quite a fan of the note taker. I've got no particular issue with that. And I think it gets us closer towards that sort of documentation through asynchronous communication. But there's nothing quite like

Colin (34:06.83)

That's a really good point.

Chris (34:31.517)

just seeing it written down somewhere that's accessible and not having to go into a link and not having to consume the meeting notes and not having seen a version of the truth that's been decided by someone's prompt engineering to a greater or lesser quality. So I think that that's quite a key thing because it gives lots of people access to information about a decision rather than just the people that turned up to the meeting and paid attention. And it kind of leads to this sort of

self-service culture, dare I say. It means that if you've got a good sort of asynchronous repository of information about a project, then people, you can see people sort of self-regulate, they train and go and look there for that information rather than scheduling a meeting with you to kind of talk about that. So I think that that plays a really, really important role when done correctly and when managed correctly. So it goes back to that

sort of engineering the op rhythm. You know, when's it important to come together? What should be synchronous? What should be asynchronous? What is the sort of parameters in which we communicate? And I think then kind of creating that sort of hybrid op rhythm that's sort of sync and async is to my mind when coupled with all the deep structure stuff, what good looks like.

Colin (35:56.032)

So in your experience, how do we actually, because it's all very well as saying, you need to achieve this balance.

Colin (36:09.407)

that's quite challenging.

Colin (36:14.699)

functional. So how do we calibrate that cadence as you put it so that that doesn't happen?

Chris (36:24.615)

I think.

When you're thinking about kind of particularly cross-functional teaming, then, yeah.

really, this is the growth system, we talk about growth teams, we are inherently working in a cross-functional environment to a greater or lesser extent. mean, you know, whether we are on the growth system, big advocates of bringing sales and marketing together, particularly in kind of complex B2B organizations. But ultimately, sales and marketing are two different skill sets. And whether they've got two different lines of leadership up to the board or one, it kind of doesn't matter, you are still cross-functional almost by default. And that

means that, you know, sort of synergistic relationships between those two functions are the key to achieving strong outcomes. So how do you kind of dial everyone in without getting everybody around a table all the time or having the channel where everybody sees everything and therefore ends up seeing nothing? And I think that's the danger with that kind of that you can end up over communicating and therefore

Chris (37:33.811)

Of course, the answer is at a 50,000 foot level, well, you define, you know, who needs to be on what, you know, who needs to know things, who needs to make decisions about things. And then of course we bump into our old mate, Racy, and you know, the like in terms of kind of having frameworks for defining how we collaborate and how we get work done.

inherently, I don't have a problem with that. I think that it's in everybody's interest to have a structure for who needs to be on what. But I just think that a static framework is not the right answer to that. And for a lot of the reasons that we mentioned earlier, but

you know, whilst well intentioned, that sort of static view of the world is problematic because as projects evolve, as phases, you know, change in different projects and there are going to be different roles to different people. Inevitably, you don't write a new racy for every project phase. so you kind of have that issue of, of it being static. I think the other really big problem with these frameworks, I think it's, to me, it's the overriding problem is that

Everybody spends a hell of a lot of time often thinking about whose name should be in what box, but they actually spend almost no time in my experience thinking about how you define the things at the top of each column. So what does responsible actually mean?

Does it mean that it's just your fault if it goes wrong? Does mean that you're the one that gets carried around on a chair if it all goes right and everyone celebrates how great you are because you're the responsible party? What does accountable mean? What does consulted mean? What does it mean to inform someone? Is it just because I post something in a Teams channel? Have you been informed then?

Colin (39:13.934)

Hmm.

Chris (39:36.329)

does informed mean like, it's all going great, or does it mean here's the 74,000 page technical documentation I need you to consume so you've been informed? That is very, very rarely defined. And when you don't define something like that, it doesn't tend to work very well, is of course the natural kind of emergent reality of that. And so I guess the question is then what would you do instead?

There are other frameworks that possibly work a little bit better. There is stuff like daisy, which is kind of a little bit more dynamic, a bit more fluid, maybe. You have who's the project driver, who's the approver, who are the contributors and who are informed. Now, it's a little bit more...

clear cut, think in some cases what those things mean, but it's only incrementally better, in my opinion. There are other, a phrase I actually learned the other day on someone else's podcast, having a spower, a specific person

Colin (40:49.495)

I don't know this one.

Chris (40:50.663)

of accountability on a project. So like basically it all comes back to one person. You know, that you have the sort of project captain and they dynamically allocate everything. So it's kind of all on them. I might have misrepresented that slightly, but you know, I think that's quite an interesting idea that you do have a sort of, you know, a leader effectively that has the authority to pull people in where required and not where they're not. And I think that's something that

is quite tempting because it feels a bit more agile. I think inevitably in reality that's going to depend on the quality of our person as to how well that thing goes and how naturally they communicate. I don't think I'd be very good at that. I wouldn't tell anyone anything, any better. So that would probably be a problem for me. I think that ultimately it's

It's a good idea to document what the expectations are going into a project, but I don't think you necessarily need to go to the extent of creating an entire framework. And I think it's not just about what people do, it's actually as much about what you are doing, it's coming back to those deep structuring principles we talked before. If you have...

we talked about this a little bit in the authority episode as well, which is if you have a clearly defined purpose for the team, for the project, for the mission-based team, for whatever it is, then you'll inherently have an element of alignment. If you understand the escalation pathways out of that team, then you know what to do when stuff goes wrong. If you implement the threshold view,

of you can spend up to this amount, you can make decisions up to this magnitude, whatever it might be, before you then go up your escalation path that's being predefined. I think all of that is a really good step in the right direction because you manage the error handling almost, like you manage the edge cases, you manage what happens when you stray off the happy path of things just working nicely, which in a way, Racy doesn't do at all. So I think that's certainly something that for me is positive.

Chris (43:13.813)

And I think that the trouble you can often get into, with cross-functional teams, is that hierarchies don't work anymore. You you can have two leaders on the same team because they're representing two different functions. So your kind of typical org chart doesn't really define who's got veto power on a decision. So in that case, and when you have got things like that going on, then potentially having that sort of

specific person of accountability having, dare I say, the sort of, you know, the A in RACI defined or the R in A or RACI defined. think that probably does have value at that point. But the point is taking an agile view, starting with purpose, you know, defining escalation pathways and ultimately focusing on the deep structuring principles of why is everybody here and what are we trying to do and what is everyone supposed to bring to the party?

can create those kind of spheres of control. And I think that that's something that is situational. And I think if you treat it as situational and don't use a static framework, but you do think about the problem. Not using a static framework doesn't mean don't use anything. I think that's the key thing, but just honestly keep a fluidity so that you're not constrained by the structure too much.

Colin (44:35.958)

Yeah, do you know, there's probably a lot more we could say about this, but I do want to give you some time to talk about something which I'm sure you must be dying to talk about. think we could probably have ended the episode there if this was three or four years ago, maybe even two years ago, right? But now when we're thinking about collaboration, we need to think about AI and AI agents.

the future in a different way to what we previously did. It's almost like a cliche now, literally everyone is saying this. I know that you are currently at a conference where no doubt this is exactly what's been the sort of topic of every keynote. it'd be great if we could spend some time before we run out of diving into that area.

Chris (45:28.627)

Yeah, mean, ultimately, yeah, this is why I'm in next to a noisy business next to a noisy building site in Lisbon is yes, I am at a conference that is talking about exactly this. And it's been a big topic of conversation in our organization for

about a year, I would say we've been talking about this quite deeply and building solutions in this space, both internally and for customers. And it's something that I'm becoming increasingly, I don't know what the right word is, passionate, I was gonna say obsessed, that sounds a bit weird. But I think that it's occupying a lot of my mind right now. Yes, it probably does mean obsessed.

Colin (46:09.576)

He means obsessed.

Chris (46:13.639)

It's because ultimately what we are seeing with the agentic revolution is ultimately, I think other people think someone from Deloitte said to me this morning, the biggest change in business since the advent of electricity. And I think that's a high bar.

And therefore, think we've got to talk about this on a collaboration episode because collaboration, of course, used to mean human to human by default. It's not something we didn't have to define. was obvious. That's what we were talking about when we were talking about collaboration, but no longer because AI agents, maybe actually let's let's start with what the hell are we talking about there? What is an AI agent? And that's probably a good place to start. Well, one AI agent isn't is a chatbot.

know, chat bots have been around with us for a long time. Anyone who's had an infuriating conversation with a sort of IVR phone system or someone's customer service bot knows that whilst some are better than others and they do have a purpose. And I think that nature of things like chat bots will inevitably change very soon with the sort of advent of AI agents. They are predominantly informational.

you you ask something and then they give you a contextual response that says, usually, have you looked at this health centre article, which of course you've already looked at, otherwise you wouldn't be on the, you know, on the chat desperately trying to speak to a human being. You know, that's not what an agent is. An agent is an AI function that can actually do something. And that's the really, really important point here. So an AI agent will...

take contextual information in it like a question, like a query from a user. And it could be via chat into this or by Slack or Teams or, you know, through some sort of a co-pilot. But the point is once it's processed that information and maybe had a conversation with you about that information, it will then go take some downstream actions. And that could be, you know, if we're building a sales agent, it could be, you know, changing something to sales accepted in CRM. It could be going and fetching some...

Chris (48:32.529)

content for an email that you're going to send out and sending it. It could be if you are doing a sort of like CPQ agent, it could go and generate a quote for you and it can, they can go and take lots and lots of information sources. So we can pull in our pricing book, can pull in the website, we can pull in, you know, case studies or whatever it might be if we're to be configuring that quote. So you can also then essentially build something which is going to

augment your human workforce. And that's what's really, really exciting about them. you know, now we can't just think in terms of, you know, sort of human resource, human capital, we need to think about the sort of total intellectual capital within the organization and agents and co-pilots are increasingly going to become very, very prevalent in a great many organizations. So how do we collaborate with them? I think that's a question that

maybe not that many people are asking right now. So we thought we'd have a bash at it at the end of the podcast. And yeah, exactly. We're going to nail it in the last 10 minutes and everyone will be fine. No, that's probably not going to happen. But certainly I think we've got an opinion here that comes from actually having probably interacted with more of these things and built more of these things than the majority of people, if you don't work outside an AI business at least. And ultimately the system's thinking

Colin (49:36.526)

We've solved the problem everyone, can stop worrying.

Chris (50:01.351)

approach that we take extends easily, become new elements in the system. They have capacity, they have constraints, information flows through them. For all intents and purposes, they act in exactly the same way as a human working in your organization. The difference is that their purpose is probably a bit more narrowly defined right now. know, creating quotes, processing invoices, you know, checking for

fraud in your kind of, you know, procure to pay. It could be, I don't know, like I just doing admin within your CRM. They tend to be quite narrowly defined, but whilst AI-based automation can be processing all the time in the background, one of the defining points of many AI agents is that they work hand in hand with a human worker. They extend the capability.

of human workers. And that means, of course, that we are collaborating with them. We are sharing a task during our day. So, you know, that's the big thing. An agent is able to actually orchestrate actions in the wider tech stack. And therefore, when we're collaborating with that, we've got to make sure that it's going to do the right thing. And some of that is down to design and architectural patterns and stuff that lives in the realm of IT.

and other stuff's actually down to that kind of human AI interaction. And I think that's probably the first thing that we wanted to talk about a little bit, that actually this acceleration of capability within your human workforce, which ultimately will also lead to an acceleration of profit margins, which is somewhat an exciting thing for most businesses because you can do more with the same people. But ultimately, also, you

requires the human to have different skills in terms of how they're going about that job. you don't just need to know how you did it, you need to know how to interact with the thing that is now doing it in the agent. So how we brief the AI is a big part of that. So how we manage prompts, how we kind of talk conversationally, some people do that naturally, other people, you know, don't. I think that

Chris (52:28.213)

And I think we've probably all observed that the way that you prompt creates a different outcome, a different output from a tool often. So there's going to be a skill set to learn there. But there is also a question around accountability here. So what is an AI? It's flawed.

Colin (52:49.334)

Yeah, who's accountable if the AI's output is flawed, it? Let's face it, often is.

Chris (52:57.747)

Yeah, and that leads to some really, really interesting questions now. I think it's a bit like what's going on with stuff like Waymo and the sort of like Robo taxi. It's like, you know, if that drives the wrong way, the wrong way street, who's actually accountable there? Well, you know, if your AI agent, you know, processes a bunch of spurious invoices that have been sent in by someone and does that incorrectly, and you pay a bunch of money out, who's accountable? Is it the person driving the agent? Is the person that built the agent?

Is it nobody? it the AI themselves? So there's a whole bunch of questions we need to kind of ask ourselves here. And it definitely adds a new dimension to the sort of racy framework, if you like. So who is accountable? Who's responsible? So I think that adds sort of leads to some really, really interesting questions that businesses are going to need to ask themselves and also to kind of create governance around.

So I think we're going to see increasingly a new part to the operative that's going to exist within kind of AI infused workflows. And that's really going to be about things like explainability. I think that's a phrase that we're going to hear a lot more of in most organizations. How can we actually explain why the AI did what it did? What data sources did it reference? What data sources did it not reference?

what pathway did it take, what logic pattern did it take? So there is actually a whole kind of technological piece going on there which needs to kind of create governance, needs to create explainability within AI workflows. But from a human perspective, we're also then going to have to build into our operism, review, governance, interpretation, and ultimately building that kind of continuous learning piece that we talk about in organizations and actually putting that into our AI agents.

you know, when it did something wrong, how do we make sure it doesn't do that next time? Well, if we're just raising a ticket with IT, that's going to become probably quite laborious. So there are different skill sets that are going to be required to make training data available. We're going to have to have different interfaces for non-technical users into our body of knowledge. We're going to need to have centers of excellence around creating kind of custom instructions and prompts for AI workers.

Chris (55:23.613)

So there is a whole bunch of stuff going on there. And that's just talking about human to AI collaboration.

Colin (55:29.994)

agent to agent. Do we even have time to go into agent to agent? Because I think a lot of people are just not thinking about this yet. Although I think Google just released or just announced this sort of agent to agent protocol. This is like really fresh.

Chris (55:34.101)

Thank you.

Chris (55:43.061)

yesterday I think.

Yeah, this is like, yeah, yesterday, 9th of April, as we're recording this, think that there's an A2A protocol came out. Again, just without disappearing down a technical rabbit hole here. Yes, the future of agentic is going to because they are more than hourly defined in their purpose.

Colin (56:00.45)

This is a serious rabbit hole.

Chris (56:10.205)

they are going to have to talk to each other. They already do. There's technology that already exists that manages kind of AI agents to agent orchestration, as we'll call it. So where are the handoffs of data? What is the trigger point where the skills of one agent runs out and it knows it needs to then hand the task off to the next agent? How do we make that explainable and how we define those workflows? And really the...

you know, when you've got a sales agent that has spotted that something's gone to, you know, ready to quote in your pipeline, that it then hands all of the information off to your finance agent to generate a quote and send it back to the seller.

How do you know it got it all right? And that is a big, big question that we're going to have to learn how to deal with as workers. And I'm afraid I don't have all the answers to that. And the answers I do have, we probably don't have time to cover. But safe to say that Google doesn't have all the answers. 24 hours old, though it is, A2A already has a bunch of critics out there saying that it's too cumbersome, too big, too bloated.

There are, in our technical partner community, the organization that I'm out in Lisbon at this week, Wacato, who are our enterprise orchestration platform partner.

they have their own approach to this in terms of agent to agent orchestration, which is a lot more kind of user friendly than Google's A2A, people are talking about MCPs. And, you know, we could, we could definitely go down a funnel more than even this audience on this podcast will probably enjoy, but collaboration is changing.

Chris (57:59.253)

The nature of work is changing, the nature of how work gets done is changing. And collaboration won't go away. It's just going to change meaning or it's going to extend its meaning into the realm of IT.

we're going to have to change our own playbooks, we're going to have to kind of seize the emergent best practices coming out of organizations that are further ahead with this, we're going to have to build new governance frameworks within our organizations, we're to have to manage explainability, we're going to have to manage continuous learning processes for AI, and ultimately we are going to see this you know black swan moment in the world of work that is already gathering pace.

and it's going to lead to some really interesting changes in the dynamics and how things get done.

Colin (58:48.13)

A lot of free, sort of free flowing innovation going on. It's been very democratized as well. And I wouldn't say not a lot going on around governance, actually a lot, but not a lot of answers around the governance piece, I think. I should probably inform you at this point that we are very, very close to the end of the episode and probably should not dive any further into agent to agent collaboration.

Chris (59:16.021)

I'm going to

Colin (59:17.326)

I just wondered if you had any closing thoughts or sort of practical takeaways just to kind of close up on.

Chris (59:24.885)

Well, let's zoom right in the way back out again and just remember that collaboration is the, I would say, key interconnection that governs the functioning of all the elements in our system. So it's something that needs significant focus. You cannot leave good collaboration to chance. It is not, well,

Collaboration is an emergent property of the structure that you have within your system. So make sure that it is structured appropriately to ensure that you have strong collaboration because with strong collaboration comes strong value creation. There you go. That's a busy end, isn't it?

Colin (01:00:08.814)

Yeah, I like that. I almost don't want to sort of, maybe I won't actually add anything to that because it's such a good ending. We are also, I believe, just about to hit the one hour mark. I think we should probably move on to the end of the episode. Thanks very much for listening. If you listened this far, please don't forget to follow and rate the podcast. It really helps us to bring the content.

to a wider audience. We'd really appreciate a moment of your time to tell us what you think. And especially interested to know what sort of subjects you'd like us to delve into further. do people want to know more about agent-to-agent collaboration, for example? Maybe we should go down that rabbit hole, or maybe we should absolutely stay away from it for now. So it'd be great to hear a bit more feedback. It really does help guide.

what we do here on the growth system. All that's left to say today is that the growth system is brought to you by us, the way of Rebspace, a growth systems consultancy that connects B2B organizations with the future of growth, who offer consultancy, education, and even applied delivery services. That's all we've got time for this week. We'll see you again next week. Thanks very much. Bye bye.

Chris (01:01:29.461)

Thanks for listening.