Charlotte Ward: 0:13
Hello and welcome to episode 310 of the Customer Support Leaders Podcast. I'm Charlotte Ward. Today, welcome Colin Flanigan to talk about bringing cohesion to chaos. Today, welcome Colin Flanigan again after what I think is about two years we established, right, Colin? Lovely to see you.
Colin Flanigan: 0:40
That's very great to see you as well.
Charlotte Ward: 0:42
Welcome back. So I'm quite excited for today's conversation, not least because the title just holds so much promise. Bringing cohesion to chaos is our topic for today. But before we dig into that, would you please just reintroduce yourself for our listeners?
Colin Flanigan: 0:58
Yeah, absolutely. So my name is Colin Flanigan. I have been uh in CX leadership in SaaS tech for the last oh over a decade now, uh, leading and building teams from small ones to big ones across the B2B SaaS sphere. Uh, currently the director of technical support at a cybersecurity company called Netrix.
Charlotte Ward: 1:21
Lovely. That's a that's a tough job any day of the week. Uh that deeply technical support. Um, I think cybersecurity is the last frontier for me. It's it's a type of technical support that I I feel very unqualified to talk about on any level, let alone lead. Um, and that's saying something because I'm also in that fairly deeply technical support space, but that's just a whole as a whole level up as far as I'm concerned. So congratulations.
Colin Flanigan: 1:49
Well, thank you. I I I'd love to imagine I'm qualified to speak on it, uh, but that's actually the the exact reason that I joined this organization, is it uh felt like a last frontier for me as well and a fun, a fun challenge. And so it has been.
Charlotte Ward: 2:02
Excellent. Um, and uh I know that like joining teams and and uh uh I I mean when we talked about this, joining a team and then um kind of sorting out the problems or joining a team and growing growing that team in a certain direction, or I think you gave me some scary numbers when you pitched this topic to me, which I'm sure we'll dive into. Um but but the chaos that we're talking about is it it has a lot of frontiers, doesn't it? And so I I would love to explore with you um exactly what we mean by chaos, because it's it's not it's not the uh the product side. We're talking we're diving into the team side here, right?
Colin Flanigan: 2:45
Absolutely, absolutely, and the cross-functional side as well. So um, you know, I I feel as though every uh organization I've joined, every role that I have interviewed for uh at this stage of my career, uh at least for the last 10 years, has included the word builder mentality somewhere in the job description. And yeah, I've there's two approaches, really. I I don't think there's a third that I can think of uh that I've taken. Uh, you know, either you're joining at an early stage and you're building a team from the ground up, which is well, I'm I'm really not sure which is easier per se, but that one feels easier anyway, uh, because you know, it's a green field, you've got the world in front of you. Uh, the other option is coming into established teams uh that are, again, some form of chaotic or another. Otherwise, uh, why would they be looking for leadership? And establishing order
Colin Flanigan: 3:40
in those teams. Uh, and that's very much what I've I've done uh at Netflix and in a number of my previous positions as well, is come into relatively chaotic teams or uh or even just sort of ungainly, maybe is a more polite term to use.
Charlotte Ward: 3:57
Well, I think I think it's a spectrum, right? Like so many things in life. It's like things are things are a little bit ungainly, or they're well, you know, I'm allowed to swear I'm British batshit freaking crazy, right? I think I think if we have uh if we have learned nothing, it's the that there are all types of support teams out there requiring all types of leadership. So I I hear you. I hear you.
Colin Flanigan: 4:20
Yeah, yeah. Yeah, and to touch on those those somewhat scary numbers, the the version of uh ungainliness or or chaos um that I've most recently dealt with is uh in joining networks. I joined right after they finished uh their past past 10 acquisitions in about uh the space of about four years. And so we just had team after team after team joining and product after product sort of you know bolted on in many respects uh to the the broader systems and uh um and so yeah, there was quite a bit of cleanup and and process management and and and change management indeed um to bring people along into as well, because you know, of course, by the time I joined people were certainly not all uh there's a there's a manager I have that uses the phrase singing from the same page that I like quite a bit, and uh we were not doing that when I joined.
Charlotte Ward: 5:21
And this is this is the missing cohesion that we're talking about then. And acquisit acquisitions are I mean, they are a particular flavor of um, you know, lack of singing from the same hymn sheet, right? They are um because to your point, there are so many um stages of um what Neil Travis would call maturity um for for support teams everywhere that when you are acquiring or being acquired, you're getting any level of maturity, any size of team, any level of chaos uh being kind of stuck bolted onto the side because that's how acquisitions usually go. Um I've I've done I've ridden the acquisition boat ride myself, so I know exactly how choppy those waters can be. Um, and uh how um yeah, they can lack direction, they can lack that cohesion, they can lack certainly in the early days. So so is it acquisitions that we're primarily talking about? I mean, you talked about joining teams at other stage, you know, it for other reasons and uh other stages of maturity that might lack internal cohesion, but acquisitions are a particular flavor.
Colin Flanigan: 6:40
You know, there's another there's another team I can recall joining uh a few organizations ago, a few roles ago, um, who had not done any acquisitions, but they were the another category of I think chaos or ungainliness, which is the the hyper-growth company. Um, and especially when you're joining sort of in the middle of that uh growth phase. So um a lot of chaos there comes from you know, you've hired a bunch of people really, really rapidly. You've got your uh your original team members who are often more highly technical and more experienced with the product, and then you've got this whole crew of newbies, and then you've got your people in the middle, and you have to figure out how to get them all to get along and share knowledge. And most of the time, when I've joined teams like that, I've done that two or three times. Um, you find that that knowledge transfer is a real choke point because they've just never really thought about it before. Because up until then, they've been small and it's been easy and it's just sort of happened organically. And um that's a that's a word that comes up a lot as well, uh, alongside builder mentality, is uh in conversations I have when I join these organizations, is that like, well, this was happening organically, and now we have to figure out how to how to make this thing uh that was happening organically systematized. Um and there's of course then follow-on questions about you know, how do we do that without losing some of the the beauty of the that organic information sharing and uh and all of that? Um you know, my own. It's interesting, isn't it? Turning people into automatons.
Charlotte Ward: 8:16
Yeah, it's interesting. I I've joined at that stage a couple of times as well. And that that to me is kind of interesting because when things when things are labeled as organic, what I see is chaos. Yeah, and chaos has a beauty, you know, it does. You you know, chaos produces butterflies, but it also produces tornadoes, you know, artisan a famous effect. Um and and I think that that um I I think everyone tends to assume that their particular organic growth is the butterfly. Whereas some and to your point, it's beautiful and we should preserve it and we should pin it very carefully on this, you know, uh on this board and and set it in a frame and look at it every now and then. But uh frankly, uh a lot of those, um a lot of those situations aren't quite as beautiful as as people believe them to be from the inside, I would say.
Colin Flanigan: 9:19
There's uh there's a phrase that I like to use that applies well to to those sort of organic situations as well as uh to product managers and their relationships to products, which is no one likes to be told they have an ugly baby.
Charlotte Ward: 9:34
Very true.
Colin Flanigan: 9:35
And yet, so often we find it is our job to uh to notify people that their baby is in fact ugly, or that perhaps they shouldn't be considering this thing their baby uh at all.
Charlotte Ward: 9:48
Or maybe it's not even ugly, but maybe it is a tornado instead of a butterfly. And tornadoes have a special sort of beauty,
Charlotte Ward: 9:55
but they're not very effective at driving things in one direction. Let's just say that.
Colin Flanigan: 10:00
That's right. That's right. And I should clarify that I do think that all babies are beautiful for the sake of uh you know the podcast.
Charlotte Ward: 10:08
Well, I I can't I'm I'm not sure I agree with that, but okay. Um what what I will attest is that I'm very fond of building a metaphor and then hackneying it for a whole podcast episode. So I feel the butt, I feel the butterfly and tornado one is going to come back a few times over the rest of this conversation.
Colin Flanigan: 10:27
Most definitely.
Charlotte Ward: 10:28
We'll we'll we'll ride it for as long as I can take it. But um the yeah, so you know, the the fact that things don't have this kind of neat direction and ability to deliver things predictably is often uh one like the the the most frustrating, the you know, the the most urgent um and the most difficult thing to fix when we're talking about these kind of organizations. That chaos leads to unpredictable outcomes, actually, and that's the danger, isn't it? And so so when you when you step into those kind of situations, whether it's a fresh organization or an acquisition, um people from the inside get a little, you know, they get a little bit antsy, they get a little bit scared, a little bit anxious about maybe you're calling their baby ugly, or maybe you're just saying, actually, I want to turn this tornado into something predictable, something we can actually sail on the wind of and uh see, I'm gonna do it. But but also I think that they're a little bit, the anxiety is around is a lot around change. It's a bit about their baby, it's a lot around change, though. And the idea that structure and all of the things that are necessary to drive predictable outcomes might you know actually ruin the beauty uh um of of the uh of the the organization or the culture or whatever. And I and I think that's largely that fear of change is where a lot of those anxieties and that pushback you sometimes have comes from. Um how do you approach those situations then? So, you know, when you when when you're told like we've acquired this company, here's this team, it's going to be bolted on the side, and and you know, uh I used to run this announcing. I used to have this, this was actually something I applied to a product I was supporting 32 years ago, Colin. Um, 31, 32 years ago. Um, this product ceased to function well because it had started as this as this beautifully defined, like well um, well-performing, highly spherical ball that you could roll across the ground predictably and it would go wherever you rolled it. And eventually there was so much extra functionality bolted on the side, it no longer rolled or bounced predictably, and it would just this would this was you know a mainframe situation. That's all you need to know. I couldn't remember much else about it, but I had that analogy, like the you bolt enough stuff onto the side of any well-functioning system and it ceases to function predictably. And like if we're talking about acquisitions, that was that's what we're talking about, isn't it? So in that scenario specifically, how do you even approach bringing that to some kind of level of predictability with that cohesion in mind?
Colin Flanigan: 13:19
Yeah, well, and you you brought up too the the feelings aspect uh of it as well, which I'm I'm happy to touch on because that's uh uh I I I feel a particular specialty of mine. Um, you know, the first few weeks that I spend at any organization, whether I feel like it's well functioning or not, because you never really know until you know your first few weeks in.
Charlotte Ward: 13:40
It's never what they tell you in the interview, is it?
Colin Flanigan: 13:43
That's right. Or sometimes it is, and that's just as bad. True. But uh but um I think you know, I spend the first I'd say three to six weeks at any organization that I join, um doing a sort of a deep analysis as I'd uh I usually say 50% journalist and 50% analyst. Um and so I spend time meeting with people, meeting with leadership, usually with the most uh critical cross-functional leaders I'm going to need to work with, the immediate team members I have to work with. And we just talk. I talk about, you know, I I I use my newcomer card uh and and uh use the innocence I have to my advantage to ask them, you know, what's not working, what is working, um, what's going to surprise me is one of my favorite questions because it it is often it's surprising how truthful pe people are.
Charlotte Ward: 14:40
Uh when you ask me, I need to ask, what's the best answer you've ever had to that question?
Colin Flanigan: 14:46
Oh, uh we don't need you.
Charlotte Ward: 14:50
That's a level of confidence, isn't it? Wow.
Colin Flanigan: 14:52
Yeah, uh which is which is an answer uh unto itself, right? Um not not, I think the answer they thought it was, but it but is an answer on unto itself. Um and you never know, sometimes well, they weren't right, um, but someday someone maybe will be, I don't know. Um but you get this this sense for um even in the most beautiful, well-functioning systems, at least on on their faces, um there are friction points that people want to talk. And people love to complain. We love to complain. It's a it's a deep-seated human need. And so I find that when I step into a situation, um, you know, I learn someone's dog's name, um, uh, you know, and and and what their favorite pizza top toppings are, excuse me. Um, and then I ask them to complain to me, they're apt to tell the truth. Um, and then it's up to me to sort of define and categorize and label those complaints uh and sort of start to position them um, you know, functional functionally and cross-functionally, uh, and start to map things out. And so that's where I usually start is I
Colin Flanigan: 16:05
build myself a self a map of friction points.
Charlotte Ward: 16:08
Um and then I is this like a functional map? Is it a map of processes and things or usually a process map?
Colin Flanigan: 16:17
Um it doesn't start out as a map, it starts out as a list, and then those things from the list become map. Yes. Um and then once I've got my sort of rough map, then I start digging into the data. So I don't actually always look at raw data um in our systems until maybe week two or three, after I've had those conversations, so that by the time I get to the data, I can correlate that um that qualitative or quantitative data to qualitative uh analysis. And I can understand sort of like, you know, okay, here's the current team's version of the story that this data tells. I can write my version and see where those things coalesce, where they diverge, things like that. Um and as far as the emotions tied to all of this, uh I usually just acknowledge them right off the bat that I am the I'm the new guy who's gonna come in and change, want to change things, and that we may feel some pushback, there may be some discomfort, but I also uh start off on the foot of collaboration. I I want to involve these folks in the ways that I am designing these systems. I come with with frameworks, not with prescriptions, um, as any good you know physician might uh I ideally. And so I'm very clear about that as well. I'll usually share some of my frameworks with them early on and say these are things I've done that have worked in the past, but they were specific to these organizations. Let's figure out what's going to work well for this organization. Uh, and then I just continually bring people in. I also have a tendency to operate um some might say extremely transparently. So all of my project documentations, all of my findings, all of my data, all of my research is generally speaking shared for whomever uh in the organization wants to see it. I don't really hide anything so that any question the folks have can they can they can answer it right there in the documentation.
Charlotte Ward: 18:20
How um how much do you in your experience um find that the frameworks that you approach uh stakeholders with? Um even though you have that narrative of like this worked there, now let's find out what worked here. Be honest, just for you know, just like you said you said you were transparent, you said you're open, honest, I'm gonna I'm gonna take this answer at face value. How much actually is it pretty much that there's very little you need to change? Because in my experience, even though even though, okay, platforms might change, titles might change, some things around the way support is delivered might change. I think the I I'm I still think that m at least up to this point, the fundamentals of what works at the very core essences have changed not a great deal. I mean, I've been doing this job 30 years, and and I think that you know, on there there are core tenets around how support relates to engineering or product or success that okay, specific processes aren't gonna be the same, but like the division of the work, how people relate to each other, typical division of platforms and scope and things like that. I I feel like they haven't, and I do think we're on the edge of something in support, so I'm gonna caveat that very heavily with up to this point, uh, just so I'm not held to account on this two years from now. But but I'm hedging my bets a little bit. But for 30 years, I think that that it's been, you know, there's there's there's there's core ways of working, core relationships, core scope, and things like that that have broadly, and I this is a very broad brush, not changed. Would you say that's fair?
Colin Flanigan: 20:23
Yeah, I I I think so. You know, there's a reason why engineering teams have been using agile scrum methodologies for over a decade, and you know, for uh so there are certain systems that we just sort of know work and they're pre-built, but again, I I do think it's important to look at those as like that that in and of itself, agile scrum is a is a framework, it's a methodology. True. Um and I've I've observed and been a part of teams using Agile Scrum methodology at you know uh countless companies now, um either as a consultant or or a direct employee. And uh it's always a little different, you know. There's always uh perhaps it's spices or garnishes or whatever analogy you want to use. Um, but there's always little differences in whose responsibility is what, things like that. Sometimes I've had uh what are essentially junior developers, and I think this is maybe what you were getting at, um, on the support team at the very you know, uppermost tier. And then sometimes, you know, never the twain shall meet uh engineering and support, right? And so you're you're hucking things over the fence to the other team. And so it's I think it's little differences like that. So to a certain degree, yes, I think that um much of it comes down to choosing the right framework from your sort of menu of frameworks. And then you follow that framework and make little tiny subtle changes and adaptations uh based on the team. Um and then there are some areas. I think there are key areas, for example. Where something truly bespoke is uh is in order. And that's usually things like um if we're looking at voice of the customer programs, for example. Um, I don't think that I've put together a voice of the customer program uh quite the same way twice. Again, similar methodologies, similar frameworks, but the inputs and outputs are just so different depending on the business vector, the the product itself, the ICP, all of the above, the way the team operates.
Charlotte Ward: 22:32
The journey by which you get there is f fairly consistent, but but the uh the outcomes are quite different. And so how that gets executed on in the business is quite different. Yeah. That's right.
Colin Flanigan: 22:44
So that's where I I find the most variation, I think.
Charlotte Ward: 22:48
That makes sense. That makes sense. So so you go into these uh situations, you you have you know your back pocket stuffed full of frameworks and uh experience, uh, you you do that, what some people call a listening tour. I love the kind of idea of half journalist,
Charlotte Ward: 23:05
half analyst, uh, you know, making uh interviewing, making observations, and then validating before you publish, please. Um the the kind of um I think there is all you know, some people call that a listening tour because I think there is an element of um even though we have those frameworks of of like mm double checking what we believe to be true, are do the definitions match up? Do what I understand to be does does what I would call a happy customer look the same as what I've historic, you know, what this this organization calls a happy customer? Things like that. Yeah.
Colin Flanigan: 23:50
Right? I I think a great example of that is uh, you know, um uh a little bit of a I suppose it was strong enough to call it a crisis of confidence uh early on uh in my current role, moving from um, you know other areas of B2B SaaS into cybersecurity and into in particular a more technical uh customer. Um there was a point where you know I was repeating this phrase where you know, well, our our our technical capabilities on the team seem very strong. We're we're we're good on those, but I feel like there's a lack uh in in our customer service acumen, um, our our empathy, the way we speak to customers, the way we phrase things, the way we follow up, you know, we we could we could uplift on these things. And there was a point, uh maybe three months in where I sat down and I thought to myself, like, well, but these are other highly technical people on the customer end who are submitting these inquiry. Maybe they don't care. Maybe all they care about is that the the issue gets solved relatively quickly, and that's paramount, and you know, everything else, you know, the niceties, the softener words and our uh, you know, our our our text expander snippets uh don't matter as much. Um that turned out not to be the case, but I thought about it. So yeah, I think you just have to apply that lens. Um it's why I I talked to uh marketing maybe earlier than uh than some of the folks I've met in in this similar sphere. Um I talked to them really, really early to see like what is our ICP? Who is our customer? You know, what do they think? What are they like, what moves the needle on a purchasing decision? Um so talking to people in the growth department about that so that I can wrap my head around our approach to then ticketing.
Charlotte Ward: 25:47
Uh I love that. Um I I think that's a I think that's a really um a really key relationship that support doesn't spend a great deal of time. We don't spend much time at the other end of the business anyway, but but I mean I think once you get more into the like understanding more about customer experience than support, and you you are looking at VOC and you are looking at customer journeys, you you pay attention to what are the early promises we're making our customers and are we fulfilling all the way through the life cycle. And I think actually I'd love to see more support people, not just leaders, spend more time with marketing. Even if it's just reading the marketing team bulletins or whatever, like so many, even like entry-level support people just treat them as irrelevant and they're not.
Colin Flanigan: 26:35
Yes, right. Yes, yes, yeah, yeah. I mean, I know a lot of people hate to hear it, but we we have to talk to sales, we have to talk to growth, we have to talk to marketing. They're important as well. And they're they're teeing up all the conversations we're downstream of as well. So if you're not paying attention, uh you you probably should be.
Charlotte Ward: 26:54
Mm-hmm. True, true, true. Uh, same is true of so many parts of the business, professional services implementation teams. It's all about are we keep I mean, support's right the other end of the life cycle often, isn't it? And we are we are um we need to be sure that we're delivering what we've promised our customers at every point, you know, because from from first marketing engagement through sales, through implementation, through that CS relationship, which is ongoing in parallel with us often, like we need to know what everybody has said upstream of us. This is what working with us long term looks like, and that's so often with the the support team. So we should 100% know what the expectations are of our that our customers have before they get to us.
Colin Flanigan: 27:42
Yeah, yeah. And I well, I I this this belies, I think, part of the the ordering process that I usually find myself implementing as well. There's a um it's not always true. There's often you know technical, fiddly process-driven nonsense you have to fix um that is deeply technical, it's integrative, it's uh it's you know, sometimes even engineering-facing. Um but there's an extent to which I uh who knows, maybe I'll I'll recant uh of this in in two years' time as well, but I think there's an extent to which some of the most technical problems, quote unquote technical problems, uh that I have resolved and worked on at some of these organizations, ultimately come down to fixing extremely broken communication channels and systems. Um I'm a big, a big fan of and believer in oh, I hope I'm not getting this wrong. I believe it's Conway's Law, if you're familiar.
Charlotte Ward: 28:46
Oh, is that the uh the Pekend rule?
Colin Flanigan: 28:50
I don't know if it's called that, but uh Conway's Law, if I'm if I'm referencing it correctly, I believe I am, uh, is essentially that um the communication systems of an organization uh influence the outputs of those organizations in such a way that the outputs of that organization can essentially only be recreations or simulacrum of those communication systems.
Charlotte Ward: 29:21
I think I have heard of it. I wouldn't have been able to name it. So yeah, I was thinking of something else. Uh the peak end rule is is about what our customers remember, which is Oh, that's right. They typically remember the point at which they were most emotionally engaged and then how the how the interaction sequence ended. So that those are the two key interaction points they remember. Which which is, you know, ultimately those interactions are an output of Conway's law to your point. But yeah, yeah, yeah. Yeah, interesting, interesting. Yes, yes. Um, so uh I I think the the missing piece in all of this, and you did promise me that you'd talk about feelings a little bit at the start. Um, is is the people, you know. Uh let's, you know, we just talked about customers' feelings there, the things they remember, and and the fact that um the the way that we structure ourselves internally is how and it drives how we communicate to our customers, our customers' experience of us as an organization, not just as a product or of a support team, but as an organization. Um where do feelings come into all of this internally?
Colin Flanigan: 30:29
Oh, they are messily strewn throughout the entire process uh of bringing
Colin Flanigan: 30:35
this order. And um, you know, it's difficult. It's the most difficult part of this process I have found for myself to systematize into a consistent framework. But um I tend to define goals and then work backwards to figure out how how I either will or have achieved them. And my goal at this point for um or at least people who report to me and and often people who don't, but whom I rely on as stakeholders uh cross-functionally, is not necessarily full acceptance of whatever we try. The the phrase that I yearn to hear from my managers, for example, uh isn't necessarily I fully agree with this and I love it, and let's let's let's do it, let's go. Um that's a bonus if we get there. Uh and and we often do, but the interim thing that I listen for is look, I trust you enough at this point to implement and to champion this solution, even if I don't fully agree with it. That's the magic. Um, and and I think you get there again by a combination of things. Um that listening tour, as we said, is an extremely big part of it, and you cannot approach that as merely a process. You have to approach it with actual humanity and actual listening and actual understanding. Um, if all it is is sort of part of the process, then it's it's not gonna go well. Um, and again, you show that through the the transparency and the involvement you bring people into. Um another part of the process that I think really helps with that is um, you know, we said people love to complain, they're gonna have those friction points they want to bring up, and they're gonna have those pet ones. And so I always take notes about who brings up which specific friction points that I need to fix so that I can go back to them. And once I have a plan in place, say, hey, will you be my champion for this on the team? Um and it's it's such a great way to get that immediate buy-in and build that immediate trust, not only that we've arrived at a solution to something that they are particularly peeved about, um but they're they're involved in being the solution to it as well. Um, so that's a really big part is is team involvement. And then uh I think the other oft-forgotten step is um walking that delicate line between uh highlighting team wins and highlighting I told you so's um really delicately, uh, but you earn credibility through early wins. And so I'm always looking for, you know, in that first 60 to 90 days, what can we fix and how can I involve people and then how can I point back to and champion those people who've then championed the solutions to the broader team to start building that trust? Because the friction, the major friction point, I think, when you're joining as you know, a leader who's coming into an established team, who's probably been through a handful of leaders already, who is you know disoriented and no one's doing things the same way, but everybody's way is the right way. Um, the way that you you earn that trust, I think, is by actually fixing things and involving people in that and then pointing to it and saying, like, hey, we like we did it, gang. Yeah, we can do it, and we can do it again.
Charlotte Ward: 34:21
And I think actually I'm gonna reframe the kind of I told you so as like this is why. That's right. And I think I'm gonna advise that like we think about you know, not I told you, see that thing I told you six weeks ago.
Colin Flanigan: 34:35
I I think Well, you never actually say I told you so. I should clarify that.
Charlotte Ward: 34:40
I I I know I know you never would, Colin. I think it's just worth stating for the record. Indeed. It's like so so remember that thing we talked about. Um, and I asked you to come along on the journey for a month or whatever. Well, he look, these this is the outcome, like this is why it's it would be a good idea to continue, right? This is why. Um, assuming it has a positive outcome, of course.
Colin Flanigan: 35:05
Of course, of course, of course. Yes, and in which case it's you know, whose idea was that? Yeah, of course. Well, and I think there is there's another key element here that I I I try to use this wherever I can. Um, it's not always an available option, but um, I think when you when you come into a team that's established, there are also probably people in leadership positions among managers or or senior engineers or senior um uh support agents or things like that, where there are projects that they've wanted to work on for some time to fix XYZ thing, but they've never been given the resources or the time or often the permission to do so. And so if you can unearth a few of those that are relevant to your goals as well, and say, hey, listen, full steam ahead, you want to do this, let's whip up a quick and dirty uh project plan template just so I can follow along reasonably. Let's create some measurements so that I can track progress and then go for it.
Charlotte Ward: 36:06
Do and create alignment right. So here's here's here's the thing that's me as as the new leader, I would consider my priorities, and this fits inside this. So it's great. It's gonna help us accelerate that thing that I know we need to do, that I know you know that outcome I know we need to get to. So the permission there is is key, and and uh you're the person as the leader who can often unlock the resources they need, uh, bare minimum the time to do it, but often engineering involvement, a product change, uh, you know, some report, some data out of Snowflake, whatever it is, like you're often the person you can just unlock a few little bits and and they're off and running, aren't they?
Colin Flanigan: 36:46
Yeah, yeah. And it it's interesting too because those types of projects frequently reveal um what I think is a uh a hidden gotcha in a lot of these processes. Um, you know, we mentioned the the butterflies, right? That are the special, beautiful, organic things. And one of the one of the things that I think comes up quite often is um misplaced or misapportioned goodwill. Um, and this is often a cross-functional problem, right? For example, I think it crops up a lot with engineering. I step into technical teams, and there's this sort of almost passive aggression between uh between developers and support engineers, you know, your your technical support team, uh, because the developers like really want to help, they really do, they care about the customers, they want to fix things, and the support engineers are are happy to have that goodwill and uh and and don't uh necessarily demand tools and systems and access to be able to solve things on their own because it's it's working, it's organic and it's great. And then you you dig a little bit and you find that both sides are frustrated because support wants to be able to fix the thing, but can't doesn't have the keys to the door to fix the thing.
Charlotte Ward: 38:05
And everybody gets stuck in that, right? Yeah, and everybody gets stuck in that dynamic as well. Yeah, I mean I've seen that several times. Like the the idea that uh, you know, it's to your point, like it's moving along, it's kind of working, everyone's a little bit frustrated that the others, the others aren't like, you know, do taking
Charlotte Ward: 38:25
staying in their lane, yeah. But also the boat's still moving, we're just like a bit messy under underneath the water somewhere, and it's kind of there's a lot of it's resentment can build, and uh like that dysfunctionality can increase, right? It can compound over time.
Colin Flanigan: 38:43
It yeah, it's this odd, this odd false positive where all of the inputs are good. Uh you know, ever everyone feels pretty good about what they're doing, and they feel helpful and they want to be helpful and all that, but the but that then the outputs are are are bad, in fact, and uh and people are frustrated about those. And so you have to dig and uh and sort of correct and say, like, I I need you to not help me, for example, is something that no one expects to hear. Yeah, yeah.
Charlotte Ward: 39:09
Uh I know I need our I need our engineers to not be in Zen disk.
Colin Flanigan: 39:13
Right, exactly.
Charlotte Ward: 39:14
It's like it is getting in lane a little bit.
Colin Flanigan: 39:16
Is that is that or my my favorite uh that that always makes people make a face is I need my project managers to tell me we're not gonna build that. Uh I've I've stepped into multiple teams where they just they don't want to say that and no one's ever asked them to, and then I ask them, like, I need you to tell me today whether we're gonna build this or not, not you know, a hundred days from now. And if the answer is no, I'd rather know now, I'd rather know at day five than at day 105, and so would the customer. So let's just let's just if we're not gonna do it, just tell me we're not gonna do it. That's okay.
Charlotte Ward: 39:50
Yeah, yeah, yeah, yeah, yeah. Yeah, I uh I couldn't agree more. That clarity uh uh just across the business um helps everyone, I think. Um and and helps us bring that uh that cohesion that we we began with, the the great desire to like all move in the same direction at the same speed and preferably quickly, but you know, yeah, it's impossible if there's a lot of flaying it flailing around and chaos under the surface. Yeah, absolutely.
Colin Flanigan: 40:19
And I think those are those are sort of the last two key uh key things, I think, are uh bringing in a disposition for disagreeing well, is I think really key. Um, because so many teams that are chaotic, uh, are chaotic because they don't know how to de disagree well, they will either hold back opinions that they think will cause friction, and so that builds resentment, or uh you have the noisy noisier team members who are constantly disagreeing and they always win. Um, and and that that builds friction.
Charlotte Ward: 40:53
I think that's a key. Your point there about being able to disagree well is so key to to a lot of the people elements that we've been discussing. And and I've been chewing over in my mind, if my mind can chew over stuff while you've been talking around like the how to manage some of these conversations. So just this notion of like disagree and commit, you mentioned it earlier, like being able not just being able to disagree well, but having the confidence to to kind of get on board for a little bit. I mean, that that's often when I join a team, the kind of uh part of my uh, let's say, selling for some of the frameworks or some of the processes or some of the change that I want to enact is is really kind of treat it as an experiment. We're gonna try this for a month or six weeks. I would like you along on that journey for a finite amount of time, and then this enables you to have those kind of this is why moments, like we're gonna run this as an experiment. Uh, I have reason to believe it will work. And here's my reasons. I've got these frameworks, I've got this experience, this was my experience in another place, I found it worked there. We might need to adjust, but if we consider this as an experiment for a finite amount of time, I would really like you to engage. And you can tell me now your concerns, and we will adjust midstream if we really have to. But but let's just consider this a finite experiment for six weeks and see where we are in six weeks. And if it really fails, we'll stop it 100%.
Colin Flanigan: 42:26
Yeah, yeah. And there's another key phrase I've I've I've come to use uh for that exact sort of rollout, uh, which is like, let's not optimize for the edge case. Because you find teams doing that all the time, especially teams that have an over uh sometimes an overabundance of caution, uh, will just consistently up optimize for the edge case and say, like, well, what if this goes wrong? And what if that goes wrong? What if this goes wrong? And uh there's a there's a key, I I consider myself a recovering perfectionist because you're never fully recovered. Um, but there's something that I learned uh from my first bout of uh of homeownership and learning to sort of DIY my way through problems, which is you know, you you you start pulling open walls and disconnecting pipes and doing various things of that nature, and uh and you you view homes as this very, very fragile ecosystem, which you know they they are in some ways, but then you also learn that there's there's once you get a wall open, you you look at it in its component parts and you realize like, wow, there are actually relatively few things I can break here that can't be repaired. And that's something that I repeat constantly to my teams is you know, I'm not I'm not a move fast break things guy necessarily, but I think operating with the knowledge that there are few things that we can break that cannot be repaired, um, that really, really helps uh to keep us from optimizing for that edge case.
Charlotte Ward: 43:47
Yeah, uh and there are very few things that can electrocute you or drown you if you're once you've got the cover off, right? That's right. And like we're definitely not gonna touch those, but this whole piece over here we can play around with. Or or you know, the walls aren't gonna come tumbling down. But there's there's like we can confident like let's take the let's uncover a bit. I guarantee 60% of this we can confidently move around and experiment with adding a window or taking a door out or whatever, and the walls aren't gonna come tumbling down and we'll live through it, we'll be fine.
Colin Flanigan: 44:22
Yeah, yeah. Well, and that other that last piece uh that I was gonna mention is is defining boundaries well, because that's the other sort of key I can't think of a term for it, but key issue that I I see in a lot of these teams is that the boundaries have sort of gotten all over the place, both internal to an individual team and certainly cross-functionally. Um, and again, often it's it's good natured, right? It's out of uh an immense overabundance of goodwill. And then those boundary lines get incredibly blurry and everyone gets frustrated because no one knows what their job is.
Charlotte Ward: 44:56
Yeah, absolutely. Absolutely. And this is where things like time-bound boundaries help super super much super much. If I can I don't know why I'm going with super much. Super much. A lot, I think, is what super much extremely vary. Oh, I don't know. It's late. I shouldn't be recording this late, but you know what I mean. I haven't even had a drink yet, Colin. Honestly, um, I'm gonna go and get one after this because uh I feel like I need uh a moment to absorb. So I'm gonna go and uh uh try and uh absorb everything I've learned today. Um uh and and reflect it on with you. Um but but you're right, good boundary setting, both in terms of those swim lanes, you know, project boundaries, what's risky, what's not, um, and uh what we hope to achieve within certain time frames. Um all of those boundaries, I think, help people get on board with the process. And it can be a long process, can't it?
Colin Flanigan: 45:54
Indeed. Yeah.
Charlotte Ward: 45:56
Super much, I think, is the answer to it.
Colin Flanigan: 45:58
Extremely very, yes.
Charlotte Ward: 46:02
Um, all right. Uh I think I need to go and have a lie down after all of this, but Colin, thank you so much for joining
Charlotte Ward: 46:10
me, nonetheless, and uh taking me through um a somewhat uh chaotic approach to bringing cohesion to chaos. Uh I've I I have enjoyed it immensely. I've learned a lot, and I've uh you've caused me to reflect on some things that maybe I could have done better, and uh we can all do better next time, I I'm sure. Um thank you very much. Will you come back and uh have another chat with me another time?
Colin Flanigan: 46:34
Absolutely. I'd love to.
Charlotte Ward: 46:36
Thank you so much. That's it for today. Go to customersportleaders.com forward slash three one zero for the show notes, and I'll see you next time.
