Charlotte Ward •

206: Fireside with Jim Israel

About this episode

Specials: Fireside 22 Jim Israel talks about the dangers of developing a culture of heroism in our teams, despite being the type of folks who always want to help.

Jim Israel

Transcript

Charlotte Ward: 0:13

Hello, and welcome to episode two hundred and six of the Customer Support Leaders Podcast. I'm Charlotte Ward. Today, welcome Jim Israel for a fireside chat. I'd like to welcome to the podcast today for the first time, Jim Israel. Jim, it's lovely to have you join me. Thank you so much for coming on the show. And um it's a fireside episode. So in a moment, I'm gonna ask you what we're talking about tonight. But first, um perhaps you'd like to introduce yourself for the benefit of our listeners.

Jim Israel: 0:54

Well, thank you. I appreciate being on here. And and it's nice to be part of the community that you have been uh evolving and developing over the years. And uh I know I've been listening and thinking, uh, I should not just be a taker, I should also contribute to the discussion. So I'm I'm happy to be part of uh part of the chat. Um yeah, my background uh varied. You know, I I have um prior to technology, I had some time in human resources, ISO management, um, and in working in logistics. And then I moved into software development um as a career change, and then uh from there came into uh technical support. Um a lot of the uh systems that I have been working on have been mainly automation systems, so uh cloud support, on-prem systems, uh often involving um everything from uh hand scanners that people use to automation systems and controlling um uh a lot of uh baggage-related systems in airports um in North America. So if you've flew in and flown in North America at one point in time, you were probably impacted by one or more of the systems that we were supporting or the teams that I was leading. Um, also uh a background in uh supporting um autonomous mobile robots, robots driving around factories by themselves. And uh and now uh looking at some uh fresh opportunities to uh to move forward and and looking at some interesting uh things moving forward where I might be doing some more development type of uh leadership. So um a bit of a very background there.

Charlotte Ward: 2:36

Wow, yeah, you've been everywhere. Um and from the sound of it, people have traveled everywhere on the basis of technologies that you've supported. So that's I guess that must be a super fascinating space to be in. Um, I meet such interesting people doing all sorts of things, like uh robot support down like to like the most empathic person-to-person support you can imagine. So so welcome. Thanks for joining me. Um, and today's as I said, uh as I said at the top of the show is a fireside. Um, would you like to tell me what you want to talk about today?

Jim Israel: 3:11

Yeah, so I I recently came across uh an interesting article uh from in the Harvard Business Review. Um great thing to get a subscription to, by the way. I'd highly recommend it. There's a lot of great leadership stuff there if you're looking for that. Um, but I came across this article uh from Ron Carrucci, and he talks about, you know, is your organization always jumping from crisis to crisis? And in really what the focus of his article was on was talking about heroics and heroic um organizations that built a culture around heroics, uh teams that uh build their culture around heroics, and and and um and individuals that can even become addicted uh to heroics. And I thought he had a great quote, and I thought this was really relevant a lot of times in support, simply because of the nature of our job often leads to that sense of heroics um or having to having to perform heroics. And he talks about, I think a quote is you know, when you have uh routine deadlines, projects, and day-to-day work, he says when they're characterized by people needing to exhaust themselves, pull all nighters, and or keep things at a feverish pitch uh to make sure that you get the results, then you might have that heroics culture that has really set up that a culture of of really having to, you know, be the company SEAL team at a all all times, all of the you know, of the um at all times or on a regular basis. And um, you know, I I kind of talked a bit about in my article about how this can be a bit damaging, um, not just to the individuals. I mean, I think it's pretty, it's pretty intuitive that this can be damaging to employees in the long run, but ultimately it impacts the customer. And uh because it it tends to be uh indicative of a few things. And I I thought that Ron, Ron was talking a bit about, you know, he says, you know, when when you're getting into um uh that kind of culture, he says, come back and take a look at things like the tools and the processes that you have provided for your team. Uh take a look at are you having realistic discussions around uh resourcing needs that you have on your team? And um, so that that's really some of the indicators. I know we've had, I'm sure you have had some of your you know favorite moments of heroics that we've had to put in. And look, we all have to do that from time to time. We are a reactive team, tend to be a reactive team. I understand we can also talk about proactive stuff, but we do have to react to the surprise and gotchas out in the world.

Charlotte Ward: 5:56

Yeah, for sure. Um, and like just everything that you ran through there, I was exactly thinking, oh yeah, there was that time. Oh yeah, there was that time. And you know, and and I think you're absolutely right, and particularly in such a reactive space as support, where the work never stops. It never stops. We're never done. There's always just another problem, another customer around the corner, or you know, um a minute before the end of your shift, usually, right?

Jim Israel: 6:22

Yeah, yeah.

Charlotte Ward: 6:24

Um, and uh yeah, and just actually we are super helpful by nature as well. I think we do want to help on a very human level, on a very human level, but actually also resolve the problems in that kind of that kind of abstract way, that that puzzle kind of seeker in us, like really wants to get to the bottom of a problem. And like we can get caught up in both of those as well. Um, so what's your experience in this area then?

Jim Israel: 6:52

Have you have you seen uh heroics in support and uh what's absolutely, you know, the most of the stuff I've been doing have either, like I said, have been these these systems where if it goes down, you know, somebody's calling the either local news media or even the national news media and saying, you know, baggage system down at airport, whatever. And um, or you know, factories where you know the the risk to their production is very, very high. And um, so you know, so yeah, I've I've personally had that experience myself. You know, the longest support call I've ever had was 24 hours straight, 9 a.m. Saturday to 9 a.m. Sunday. It was um, you know, and you know, I just sort of collapsed at the end of it, you know, and and it do get caught up in that sense of um, you know, one of the reasons that a lot of us get into that, as you were saying, get into the technical support side. We love solving the problems, we love seeing systems come back online, we love being that hero. And it's great to, you know, you kind of get that little buzz coming off of it. I fixed it, and they're good now. Um, but you have to be careful and be aware of when that can turn um into something where you're making up for things like a poor process design, um, you know, the wrong tool for the job, and um or trying to make up for a lack of resources, things like that. And as customer support leaders, we need to make sure we need to understand that we we need to build sustainable roles, um, you know, the health of our people in the long run, but also the customer as well. Exhausted people, um, people, you know, working at a feverish pitch are going to start making mistakes. They're gonna start um, you know, going in the wrong direction, that communication, that empathy starts to go down. All of those key things that we need to have as our mindset um as technical support or customer service agents, um, as we need to keep that front and center and and keep that patience in front of us, you know, all of that can kind of go away. And you end up impacting the customer's ultimate um ultimate experience with with the product and with your service.

Charlotte Ward: 9:16

Yeah. Uh you know, and and you talk there about like the um stepping up and going above and beyond, you do get that hit, that little fix, that little moment of joy and uh uh celebration and achievement, which which actually is something I've talked about, is one of the reasons I got into support, is like I'm absolutely addicted to solving problems. I just love getting that little fix 20 times a day. You know, it's not I think some somebody else recently said to me, you know, a day in support is not a day full of problems, it's a day full of opportunities. Um, and I think that's a way a lot of like really hardcore people who are like career support people like me kind of see a day in support. Um, and I think for me it's not it's no different in leadership. But but I think also like as as enjoyable as those little hits are, if that's all you're doing with no space for thought about why you're doing it, or if it's right to be doing it, you end up in this very actually the the overall pattern becomes almost like a negatively charged cycle, doesn't it? Because you've no way of stepping away from it to improve the thing that's causing you to enter that pattern of behavior.

Jim Israel: 10:29

Yeah, and there's some interesting things that you know you can draw on from um uh you know, from the DevOps world, from the SRE system reliability engineering world. I've been watching some of those uh lectures that you can get on on YouTube, um, and some folks from Google doing some incredible work there. And they talk about how they have they actually have a percentage of time. I can't remember what it is, and I think it's flexible, uh, but there's a percentage of time that they're allowed um to do um what they call um uh I'm trying to remember the term here, but it it's reducing, oh yeah, reducing toil, they call it reduce your toil. Yes, yeah, and and taking a step back and making having enough time to make your job easier. And you know, as as we move forward and try to look at these, and yes, we love to solve problems. I enjoy that as much as anything, right? I mean, it's always it's always, hey, there's something I can I can figure out. So let me go figure that out, right? And and it is it is a fun experience, it can be a fun experience, but when it moves past uh sustainable, um, then we get into that's where we get into problems. And you know, when we talking about that, I mean, really as leaders, as we start to talk to the, you know, talk to your frontline people who are doing the work, um, talk to the folks who are executing this stuff day to day. Hey, what ask the ask really good questions, not questions that set up for the answers you want. Um, because that's easy to do. Um, but ask for the questions that give you the answer of what their experience really is like day to day, and what are the things that they see getting in the way of them executing at their best and and working at a reasonable pace. Um, the other thing is talk to your customers, talk to the people that have had the experience with your team and understand what they are doing and what they are experiencing when they are engaging with your team to understand what they see. And a lot of times, you know, you can't you can't hide bad processes. You can only hide that so much. You get some customers, they'll figure it out pretty fast. And uh they'll understand when you're when your team is, you know, apologizing for the tools that they're working with, or um, you know, walking the customer through uh, you know, uh constantly walking your customer through very complex steps. You know, you've got some other indicators that you need to work backwards through.

Charlotte Ward: 13:03

Yeah, it's busy work, isn't it? It's it is yeah, it's a it's a it you need the time in your day and in their day, I think, to take a step back, take a step out of that cycle and actually identify where you're just reproducing work because there is no other pattern available to you at that point. One thing, one thing that I um that I really stand by in recent years is some an idea that I lifted and then completely misappropriated from the call center industry, which is an industry that I I have spoken to people who've worked who have led call centres, and uh it's not something I've ever done. But in calculating resourcing for call centres, there there is like you take all of your resources literally as person hours, and you apply a certain amount of shrinkage to allow for lunch and blue breaks and everything else, you know, toilet breaks, bathroom breaks, depending on what country you're in. Um and and you apply all these shrinkage factors, you know, how long it takes someone to pick up and put down the phone to make their notes after the call. And these are all things like that still effectively require your team to be running at 100% when they're not doing all the things that you just assume they have to do to exist. But that's it. Like they take away all the things they can you can minimally get away with taking out of the equation when it comes to being on the phone. And then all the other time, supposedly, you should be on the phone doing like this this very active, busy work effectively. Um generally, that um is c is called customer occupancy in a call centre. It's the amount of time and they want to maximize it. The the idea is that you should maximize your customer occupancy. I actually um really stand firmly by the idea that we should um protect our customer occupancy at an upper level. I don't want my team spending more than X percent of their time serving customers. And for me, that's about 80% at the top end. Beyond that, they have no time in their day to break those cycles, to improve the thing, to you know, do the postmortems, to look at the the way we're doing things and do that. I call it functional development, like every everything that we do beyond 80%, yeah, should should only be like to support each other and functionally develop what we do. And and that's the top end.

Jim Israel: 15:31

Yeah, you know, your your team is gonna need the time to develop themselves, to learn more about the product, um, the product or service that they're supporting. Um, they're gonna need time to take a breather. Uh if you in and you know, it was interesting you mentioned that the call center uh example. And there's actually tools online. You can just search for you know, call center or support agent uh calculations, and you can just there's the online calculus, there's a bunch of them out there now, and you can just type in your parameters and boom, it'll tell you exactly okay, if you're gonna have 24-7 um and this is the amount of vacation everyone gets, et cetera, et cetera. It'll just spit out how many you need. And um, but there there is a certain thing where nobody can operate at 100% utilization, yeah. Um, you know, and and I would say in some cases, in some of the teams I've been working at, even 80% was high for what we were doing. Yeah, for sure. And we couldn't control, like we couldn't control how often because you know it would bounce around and and the averages would move. Um, but I I also think there's things like you know, keeping an eye on what tools and processes that the team has to work with and what you need to do in order to develop it. And uh, you know, I'd love to have another discussion with you at some point on this, but in order to develop that stuff, you know, start with your customer experience, start with the employee experience that you're looking to build, and then work your way backwards towards the processes and the tools that your team's gonna need. Um, you know, if you're looking for, hey, we want diagnosis time to be in minutes, it can't take hours for your team to be able to even download the data they need in order to look and at making a diagnosis. Um, you know, and if if you're managing a lot of a lot of different stakeholders, you're gonna need a tool that helps automate that. Otherwise, you're gonna have you're gonna be dropping the ball in some areas with different stakeholders. And I think, you know, uh with regards to tools, Craig Stoss, who has been on your program a number of times, um, you know, has a really good article and he talks about what an expensive bread knife bread knife has to do with customer support. And uh he talks, it was such a great article, just the way he placed it. And he talked about getting the right tool for the job that you need and defining that. But you know, you start with you start with first what you are trying to deliver and then work your way backwards from there. And that's what will help you understand what it is you need to be putting in place.

Charlotte Ward: 18:07

Yeah, I um I remember that article very well. And and I think the other thing that you mentioned that I really want to touch on is the sustainability of any of these patterns, right? I think that um support is very reactive. You talked about it there, like the the variability across a day, across a week is there are gonna be times where any of us, any of our frontline staff, any of our any of the leadership are gonna have to step up and simply put in the hours or get on the plane or stay on the 24-hour call, right? Um there are times where it happens, you just don't want it to be the sustained and expected pattern. The work will still be there. And frankly, if you're never getting to the bottom or close to the bottom of the pile of work, then you do have that resourcing calculation to do, perhaps. You need to be operating like at a relatively minimal level, but it's always going to be there. There's always going to be something around the corner, and there's always going to be the unexpected. But but the sustainability of that pace or that intensity of work is really um, I think, the key here, because it just isn't sustainable. And it isn't sustainable at a very personal level, it isn't sustainable from a cultural point, an organizational point of view, um, or even commercial point of view, I would argue, as well. And it's it certainly isn't sustainable for your customers, as you said, because because your CX is going to drop away pretty quickly if you're having to rely on uh that level of heroism from your team.

Jim Israel: 19:47

It is. And you know, I mean, as much as everybody celebrates the hey, we pulled it out of the hat, um, hey, we did uh some amazing things. It's I mean, certainly when that happens, um the real question comes in, you know, you know, what's gonna happen in the long run? What do things look like in the wrong? Are we having to do this all the time? You know, and and there's things that don't work, you know, they, you know, depending there's there's strategies here to to working with it. I, you know, there's some that I I've I've experienced before. I've seen, you know, I've been lucky enough at times to have so things like you look for that unicorn hire, right? Who the the person you hire who can do it all, right? And um that's great, but a that's a bit of a lottery. You know, I've had one who is somebody who could do it all and did it all really, really fast. Yeah, but it took a year about a year and a half for that to really show up and then all of a sudden was like oh wow yeah okay you got this. At the same time you had to really we had to really manage him make sure that we didn't burn him out because he could do everything right and um you know and then the other side the other things you know ratcheting up the pressure on a constant basis. That's a strategy that doesn't you know I call that the Darth Vader Darth Vader model of motivation right that opening scene of return of the Jedi maybe we can find new ways to motivate them you know um you know this this kind of thing is not these things are not sustainable and they do ultimately hit your customer experience as you were saying that's where the problem comes in and your people should be able to work on a day-to-day basis we should be advocating as customer support leaders we need to make sure that we're advocating for the resources the tools the processes that we need for our teams and sometimes that means having some courageous conversations and and standing up and and making a good case for that and and that can be that could be tricky because sometimes you know things like um things like tools don't always have a direct impact on you know uh any particular metric you might be doing it might be an indirect thing but understanding that as if your team is having to work um you know at a feverish pitch all the time or is having to uh jump around from one distraction to another distraction right if you let's say you've got a uh a smorgasboard of tools that don't talk to each other and you're kind of going from one thing to the next all the time that that doesn't it doesn't help the the focus of the those agents or those uh technical support specialists to be able to really execute well and thus you end up in this sort of situation where you can't deliver the experience you want on a consistent basis.

Charlotte Ward: 22:41

And and so that's where you kind of get that inconsistency right heroics great customer experience and then you kind of collapses and then heroics great customer and you're kind of up and down and um it it leads to very very inconsistent um uh experience for the customers and that that becomes a business uh a business problem overall it really does and I I think the final part of this for me is like from the from the internal experience as well constantly relying on those cycles where a support team steps up and fills a gap is not healthy like between teams either I think uh you know you can have a wonderful team and I have a wonderful team right now and uh they like uh you can have a wonderful team and that team can be a team of heroes but if that's the cycle uh that it it's it becomes almost a self-fulfilling prophecy you can enter into these cycles where they've delivered once they'll deliver again they'll deliver again they'll deliver again it's not healthy for like their own sense of um value actually despite all that delivery it you can enter enter a place where a team can feel quite put upon and and quite kind of forgotten almost because they're constantly picking up the pieces and that like that isn't necessarily a reference to my team right now but I think that's a pattern I've seen right that the support generally and I've seen this in a a few organizations I've worked in is is a team that quite often picks up the pieces one way or another whether it's with the relationship whether a customer or whether it's filling a gap in product or whatever it is like all of this kind of gap filling and picking up the pieces is not great for uh like morale a sense of worth within the organization because it becomes a pattern that becomes thankless I think because it becomes expected yeah that yeah and that that's a I I mean yeah it's pretty common out there.

Jim Israel: 24:47

I've seen that a lot I've had conversations with other colleagues from other organizations and you can tell they're right in the middle of that right we're picking up the pieces and uh you know that's where some of what uh and you've actually you've hit on this a few times I think in in in your program you talked about different teams you've worked with right that that technical support managers leaders what are the other relationships you build internally and some of those will really help you one of the most productive ones I've had and and I think you've already covered this subject um uh previously was with product management and in helping product managers understand um understand that when I go to them I don't go with the hey make my job easier I go with the hey let's understand what the customer experience is when things don't go right right it it's easy to talk about the customer experience when things are doing when the application or the or the automation or the the service is working the way it's intended right I mean that's easy right and and that's that uh fit for purpose does it have all the features it needs um and then you know there's some design goes into fit for use i till fit for use which is that reliability piece right is it online when it needs to be um but we also sometimes there's a gap in understanding the experience of uh of when things don't go right how fast can we bring it back online and some of the most productive conversations I've had in the past was with product managers and bringing them into the design loop and saying this is a key component of the experience with your product or your service and we need to understand that and and a lot of times as soon as I start saying that I get the the nods they under they get it I've worked with a bunch that were formerly you know did support or involved in support in some way themselves who kind of go yeah you're right and and we start talking about how we can actually look at when things don't go right how do we inform the customer what is what is the um um you know what data are we bringing back is that data but readable can we is that data diagnosable how fast can we diagnose something without it needing to be and I I talked about this with once with a a senior system architect who said I could I could diagnose this fast and I said yeah you with 15 years of development experience having thought of most of how it's architected you understand that but if you can give me a team of use um you know then you know sure it will be much easier but if we're not going to have that depth of knowledge and we're gonna have to be more broad um the other thing that can happen is as you go into engineering teams and you you know go across several different engineering groups and they all have their parts of the system they're responsible for and they get to the you get to the one person who knows and they go oh it's so easy and you're like yeah but four other engineers didn't so you have to have some honest conversations with folks and build up strong relationships across the different roles if you know you need to have good relationships with the engineering team with your product management team you need to be providing them with effective feedback on how to um how they can understand how they are impacting the customer experience and getting that mindset from the organization's perspective that if everybody's in sales everybody is also in support right and um and that's really really key for for everyone to understand.

Charlotte Ward: 28:25

So I I really like that if everybody's in sales then everybody's also in support I am gonna take that and use that this week and I'm gonna and and you know and some of those courageous conversations you talked about I think are absolutely key here just as a just as a kind of parting couple of thoughts on this I think that as leaders that's the let's put this in inverted quotes the heroism that we can bring to this is actually sometimes slowing things down and sometimes saying no and sometimes saying look here's the data to prove that X, Y, or Z needs to happen, right? And and and also sometimes this doesn't have an immediate benefit as you said like sometimes it's there's no immediate benefit to the even the team that the tool is going to be utilized in never mind the wider business that things have a lead time or whatever you know but but like being prepared to have those courageous conversations on behalf of our team and advocating for our team and therefore through them advocating for the customer as well I think I think that's what we need to bring to this this uh set of behaviors, right?

Jim Israel: 29:37

Absolutely you know as Simon Sinek talks about it um if you haven't looked up his stuff just do some googling on on his stuff he's that start with why guy and talks a lot about connecting the day to day which is another topic we could cover at some point but connecting the day-to-day work with that why it matters um but he also talks about you know you know it's as a leader it's not about being in charge it's about taking care of the people that are in your charge which is a very different mindset and you know and again building up on what you said having those courageous conversations a lot of that will come be enabled through the relationship building that you can do um and a lot of that relationship building comes from understanding other teams first understanding what they are dealing with what things they are doing and as as you understand them and this works with your customer too as you understand your customer as you understand other teams that you work with it unlocks their ability to understand you. And that's where then you can start bringing into the conversation hey you know these two things go hand in hand the customer experience and the employee experience of the people who are dealing with the customers on a day-to-day basis. The last thing we all need are frustrated employees talking to frustrated customers right we need to make sure that we are greasing the wheels to make that deliver the experience that we are expecting.

Charlotte Ward: 31:02

So yeah thank you so much Jim this has been an absolutely fascinating conversation um thank you for coming do join me again thank you for having me on it's great to be uh great to be here and hopefully we'll talk again soon that's it for today go to customersupportleaders.com forward slash two zero six for the show notes and I'll see you next time

A little disclaimer about the podcast, blog interviews, and articles on this site: the views, thoughts, and opinions expressed in the text and podcast belong solely to the author or interviewee, and not necessarily to any employer, organization, committee or other group or individual.
© 2026 Customer Support Leaders
Made with in the UK & AU