Charlotte Ward: 0:12
Hello and welcome to episode 311 of the Customer Support Leaders Podcast. I'm Charlotte Ward. Today Alex Batchelor talks about how support can solve more by partnering with engineering. Alex, thank you so much for joining me today for the first time. It's lovely to see you. Lovely to see you too, Charlotte. Now, uh, you haven't been on the podcast before, and indeed, I think is this your first podcast? It's actually my second podcast. Your second, so you've done one since we lined this up. Oh my goodness, I should have been faster. I'm so sorry. Um, I'm I'm glad to have caught you now, a seasons podcast seasoned podcast guest. Season podcast. I'm basically famous now. Basically famous. Uh love it. Um for for the people who don't know you through your fame, um, would you please would you please introduce yourself? Tell us who you are, what you're doing.
Alex Batchelor: 1:15
Yes. Um, so uh I'm Alex Batchelor. I am the founder and CEO of Pebble. Pebble is a technical support resolution platform. We integrate with a whole bunch of help desks and desk intercom. Um, you seem to be Help Scout, Salesforce, and we help support folks take on um more technical issues, and we give them the context and kind of engineering information um to be able to very quickly debug and understand technical issues that customers are running into. And um, we're also very into using our own product for our own support. So um I'm kind of hands-on doing support every day with our customers and using our product to do it. So kind of half CEO hat, half support leader hat.
Charlotte Ward: 2:13
That's all all the best, uh all the best support leaders, I think, have uh got deeply into the product at some point as well or other. Um whether it's through doing support, like not necessarily actually building, but like spending a lot of time in the product or uh, you know, building it. Like at some point you have to, I think, just kind of get in there and understand things. Um enough, anyway, I think I think is the point.
Alex Batchelor: 2:43
Um I saw I saw a really wonderful talk last year um from um a woman called Meg Adams, I think I think that's her name. Um she works for New York Times Cooking. And she was talking about how as a leader she actually does this thing that kind of seems like micromanagement, where she will like jump in and work as an IC on her teams for a week. And she'll do like all the regular work that they do, and then then kind of like give the the leader feedback each day about how the team runs. And I feel like that's a she was using it for engineering, but I think it could be something that's really powerful for support leaders as well, where they like pop, you know, pop in and out of like being an IC and seeing what it's like and and running the team.
Charlotte Ward: 3:37
You know, I actually think from a support point of view, um there is a lot, just generally, there is a lot of value in anyone in the organization doing support. Um I think it's such good proving ground for understanding the product, obviously, but understanding the customers, understanding the kind of challenging challenges they're facing, and why certain requests are popping up and why your support team is like behaving like you know, manic chickens or uh, you know, all sorts of other like uh maybe uh other busy animal references. Um uh like yeah, I I just think that um understanding why your customers are behaving how they are behaving and why they're asking the questions they are asking, as well as how that then has echoes in your support team, which then echoes in your organization. Um, I think it's a really valuable use of time, even if you only do it for half an hour, and even if you don't have the technical knowledge to get into the product, sitting alongside the support team is valuable time, isn't it? It's it's time well spent.
Alex Batchelor: 4:48
Yeah. And actually, for you know, what today we're gonna talk about support and engine engineering collaboration and engineering getting in involved, especially because normally engineering only sees the fraction of tickets where they actually need to like make a fix or um answer a really deeply technical question. And actually a whole bunch of those like frontline issues that um that supports handling without engineering it engineering should be seeing too, to like see oh, where actually is the product unclear? And there are patterns in how we design the product that would make it more straightforward to understand without documentation and and help along the way. Or maybe there's a pattern of um things that people are trying to do that's outside our scope, but maybe that's a new product to build.
Charlotte Ward: 5:50
Yeah, um patterns are really uh I I think that um when we're talking about patterns and uh servicing them inside engineering, inside the product team, um as well. The I you know, I think I think the fallback is so often like here's some data. Here's some data. And and I do think that patterns are at a data level very, very important. Like I wouldn't ever say you can sit happily at the data end of the spectrum and just keep feeling like feeding, you know, data points on usage or ticket volumes on certain feature of you know, features in the product or whatever back to product and engineering. But also the same is true at the other end. Like I think that engineer like my my kind of perception is that engineering and product people who deep dive on a tiny subset of tickets and then overindex to that is kind of it it's such a narrow view, like it just requires you to get one slice and suddenly like you're in that kind of parable of the men and the elephant where you only see the trunk or you only see the leg or something, and like you don't see the whole picture. So I think when when I think about the value in what support teams can give product and engineering teams, it it's the whole it has to be the whole package. And so it is verbatims, it is actual experiences and complaints or requests, it is also the data, and it is it is also that increasingly AI-enabled middle ground, which is there's some here's some data-informed insights, right? And I think that can be really powerful because if you sit at one end or the other, you're missing the point somehow.
Alex Batchelor: 7:37
Yes, yeah, yeah. I always like to myself, I find it I'll start with an example and um go and find a specific example of something happening, and then I'll build the metric that shows this happens repeatedly or not.
Charlotte Ward: 7:59
Yeah, yeah, yeah, exactly. That's often the case. Um, the example can be, you know, you've spotted some particularly unhappy customer or two, or uh, you know, a kind of passing comment from one of the support team as a support leader in your one-to-one with them, where they say, you know what, this is becoming a pain in the ass, or whatever, right? It's just you just need that signal, and then you can deep dive on the data and get the supporting experiences and everything else. And and support has a lot of signals, doesn't it? Yes, yes, exactly. Yeah, yeah. So,
Charlotte Ward: 8:33
so I I think like we are here to talk about like how we can improve, how we can work with. And I think for me, the um the the with the partnership element, the the the kind of thinking about the the relationship and the symbiosis between support and engineering teams is really um, I mean, for a start, so often um traditionally support teams have used this kind of language of escalating, almost like engineering is I I mean, obviously they they they have more in like more knowledge of how particular bits of the system work, and you know, they are more possibly empowered in terms of tooling or or time or or uh you know uh like deep product knowledge about a particular slice of the product. Um and so we kind of we have historically, I think, anyway, almost like imbued our engineering teams with this kind of aura of expertise, which isn't inaccurate, but I think it um somehow demotes the support folk, um, uh even inside deeply technical organizations, to um, if we use this language of escalation, which implies more attention, more expertise, and everything else, we kind of end up demoting our support folks to just people who are passing the messaging back. Um, and so I really like I really like using different language because I think it talks much more to the partnership and the relationship and the symbiosis, which we actually should be um uh the the relationship we should be growing with our engineering teams, right? So I so I I never use it escalating, I always use routing. We're rooting this to another team because that routing language you can use sideways as well as back deeper into the organization. There's a a ticket can root anywhere if you just need something else.
Alex Batchelor: 10:30
Yes, I I totally agree. I like the example when you first taught me about this. The example you used was you wouldn't escalate to finance if you ask a finance question. You would just ask them route to finance. It's they have a different skill set from your team skill set, and that's why you're rooting to them. And I think it should be the same with engineering.
Charlotte Ward: 10:56
Yeah, absolutely, 100%. It is it's exactly that, it's a different skill set, it's not it's not it's not cleverer, it's not you know, it's not uh it's not, you know, uh access to something that um you know is gate or should be gate-kept in any way, is just access to different people, different skills. And um, yeah, I wouldn't root to finance. I'm sorry, I wouldn't escalate to finance, I would root to finance. Or, you know, to use similar language, I might pass this question over to the CSM or something. You know, it's like I never escalate unless to me, escalation talks about increasing the level of activity and attention on something rather than just getting access to a different person. And so I I think this also enables like the um clarity, this gives clarity to what escalating actually means, which in my mind is that it's like we need more attention, this is more important for some reason. So it's increased in priority, we need more attention on it, it has commercial risk, it has, you know, um, there are any number of reasons why you want might want more people to give more attention to and give a heightened um response to. And that's what I use escalating for, not routing.
Alex Batchelor: 12:19
Yes, yeah, exactly. Yeah. Um yeah, and often we know that those issues that escalate to engineering actually end up going into a black hole when no one knows what's happening with them.
Charlotte Ward: 12:33
Yeah, and I think I actually think, and one final example which I've just thought of, so I'm gonna say it, is um is uh the the the obverse is true as well. I think you would never escalate to finance, but also you would never escalate a feature request.
Alex Batchelor: 12:51
Yeah, yeah.
Charlotte Ward: 12:52
And you would pass it to your engineering teams, but you wouldn't ever say to a customer, thank you for asking for that red button to be blue. I'll escalate that to engineering. That's that's like there's a dissonance there which doesn't fit either. So I'm gonna pass it to the right people, is what I'm gonna do. All right, I think we I think we've made the point. We're no longer escalating, we're rooting. And so, and in that environment, we're passing things around. That's literally what routing is, and so there's a lot of opportunities for communication, for collaboration, for partnership, which is where we kind of began this. And so um, when we're talking about that collaboration and those insights, then, and and we are passing and routing messages around uh at the insights level or ticket by ticket, and both both are certainly true. What um what opportunities does that create if we break down those barriers?
Alex Batchelor: 13:47
Yeah, yeah. Um there's there's a couple of different things. One of the reason that I started Pebble was in my last company, I was um was running an engineering team, and my team was constantly getting pulled between answering questions for um for the support team and fixing issues that customers were running into um and trying to build all the new features that customers wanted. And so my kind of mission in starting Pebble was actually to enable support teams to be able to self-serve and take on um more of the more kind of kind of take on some responsibility from engineering and be able to um have all the context that engineering has to answer questions, um, and have also the the kind of knowledge needed to answer a question. Um and then kind of be able to protect engineering's um focus a little bit on whatever project they happen to be working on at the time. And um, so so that was kind of one of the things that that we're trying to do. But um the other side of it is that actually we don't want to reduce in doing that, we don't want to reduce the information that is going to achieve. So we might want to enable, okay, support's already working on this issue, let's enable them to self-serve, um, rather than having to um distract someone that isn't working on the issue yet. Um but then how do we enable support to actually aggregate all the learning and like share that back so that um you actually improve the product over time through the all the rich feedback that that support is getting from customers and learning from working with customers.
Charlotte Ward: 15:57
So um it's interesting. It's interesting there because you touched on protecting engineers' time, which I actually think is where some of the problems begin with this kind of idea that engineering is some sort of ivory tower and therefore we escalate to them. And all of that I'm not gonna touch on. I've done that hobby horse to death. I'm not gonna touch on that again this talk, this podcast. But I think like this idea that I think that's where it began, right? Like engineering needs to be protected. They live in this bubble, like, and and we post things over to them and then they disappear. But but what you're talking about is actually, yes, it's protecting engineers' time because you kind of, I suppose, have this kind of vehicle to carry those insights. You know, it's kind of well formatted, it's data-driven, it's packaged, everything else, um, which means it makes it consumable in a way that perhaps just throwing ticket by ticket by ticket isn't um and is hard for um engine it is easy for engineers to be distracted by potentially, um both in terms of time, but also in terms of focus, focusing on the right thing.
Alex Batchelor: 17:07
Um Yeah, and I think it's not when I say protecting engineering is time, I'm not trying to say that engineering is like, you know, it's protected.
Charlotte Ward: 17:19
Um Yeah, no, but I think that's the historic view often, right? Which I think is where that whereas which is where that escalating language probably was born somewhere, you know, three dec decades ago. Um but but what what I want to get at though is that like in making that in operationalizing some of that relationship around these packaged insights, around well-formed conversations, around it like it enables more focus. Um, but also it becomes a two-way, a two-way street, I suppose, right?
Alex Batchelor: 17:55
Yeah,
Alex Batchelor: 17:56
and I think the you know the the same issue actually can be seen from the support side where um you know support is equally distracted by switching between tickets when you have to, you know, you root a ticket to engineering and then you're waiting on the engineering team. And so you have to then switch to a different ticket. And um you're now okay, you've got five tickets waiting on engineering now, and then you have to ping engineering, and it turns out, oh, if someone's on vacation, they're not working on it. Oh, you move it to the right team, then that then like eventually they tell you it's merged, but but you actually have no idea about whether the fix is deployed, and you have to again. And so by actually moving some of this work over from engineering to support, support also has more of a flow state in being able to work on an individual ticket, resolve it all at once quickly without switching between tickets.
Charlotte Ward: 19:03
Yeah, and is it fun? Because because in some ways, the way you're describing that, it almost makes it sound like it's a single support engineer and a single engineer, support agent and engineer. So these are one-on-one and white, you know, but actually that's not the case, is it? We're talking about that you might have, even if it's five tickets, they're not all with one support person. Like you can have five, five support engine, uh, I tend to say support engineer because that's the environment. I mean, support agents or support people scattered globally who aren't even necessarily talking to each other and uh kind of filing these historically, like all five individual tickets would go to engineering, all of the aggregation and reporting would happen in engineering, engineering would pick, you'd have five people waiting on individual pieces of news potentially, and to your point, without necessarily knowing in in five different countries when this thing was going to be rolled out and when customers might expect it. So, so does it improve that, like you know, one-to-many or even many to many relationship as well, the the kind of relationship building and the kind of vehicle that we're talking about, which in in this case is is Pebble, but but also like just it outside of tooling, um, the kind of relationships we should be building.
Alex Batchelor: 20:22
Yeah, I I'll say one thing we're like doing in the product right now, because it's it's like top of my mind in answering this question, which is um one of the things we're trying to do is make sure that anything that we learn from is shared across the team. So it becomes not um, you know, I think a lot of folks are starting to use um Claude or maybe maybe they've like set their support team up with using Cursor locally. And then the kind of disadvantage of that, it's all like happening on your local machine, it's not shared team knowledge. And so we try to make it so that we learn from every support ticket and every interaction that is happening between support and engineering and use that to improve the the resolution of the ticket and also um the the knowledge, the kind of consolidated knowledge that the team has. So I think it does improve that that team knowledge, and then we also have try help to distribute okay, now this is deployed, and now it needs to go back to five different support agents because they've all got tickets they're working on that are related to this. So we kind of think of it as solving this um collaboration between support and engineering is a systems problem. There's a lot of different people involved, it's actually not even. Just support in engineering, this product and documentation and QA. There's all these different people involved, and the part of what has delayed resolution and made it difficult is actually like the passing of information between all of these different people. And so we kind of think of ourselves as um one being like the glue between all of these different people and like helping to um make the the workflow for the system as a whole more efficient.
Charlotte Ward: 22:37
And and everything we're talking about so far begins with a ticket. Um but does this mean that uh the same set of systems um can work for problems that are discovered inside engineering? Because you know, engineers are often, because you know, these are their babies out there in the world, they're often looking for looking for signals directly as well, right? Not everything begins with a ticket, like they're doing their own monitoring, they're looking at their own, you know, usage reports or you know, um tracking or whatever whatever it is that's happening inside the product. Um, they're looking at their own signals as well. So d does it enable more communication and uh, you know, more does it support the support team still if it's just stuff happening inside engineering?
Alex Batchelor: 23:28
Exactly, exactly. So the way that we solve this systems problem is that we deeply integrate with all of the engineering systems and all of the support systems, and so we we'll have context from the logs and databases and the code base, documentation and error monitoring and product analytics like amplitude or um or session recordings. And so we can use that all of that data and bring it to support to help resolve a ticket, but then we can also say, oh, like this alert came in and or this error occurred, um, or actually this pattern of log showed that a customer was trying to do something that isn't yet possible in the product. And we can pass that back to support to say, oh, this is uh an issue we saw this customer run into. And let's actually like reach out to them and tell them we saw they ran into that issue. Maybe, maybe actually like their authentication for an integration has expired. And we can say, Oh, we saw you run into an error. You're that integration has expired, you need to reconnect it, and then you can try that thing and it will it will work this time. And I think that that's such a delightful experience as a customer that I didn't even have to file a ticket. Like you saw that run into an issue and you fixed it and you told me about it, and um, and it really shows that you care about your customers.
Charlotte Ward: 25:08
And it's interesting, isn't it? Because there's so many reasons why a customer wouldn't file a ticket if they run into a problem. They could just simply not have time in the moment, or they may assume it's a uh, you know, a product capability issue rather than something underneath that actually is working as intended, but just doesn't signal that it's working as intended very well, and they need to take action to your point. Um or they've given up, like they've actually they've they've been trying out your free tier and it didn't work, and so they've just got bored and moved on to your competitor at that point, right? Um, it really depends. I I I think that's I I suppose there's also um an opportunity to drive other improvements, not just that proactive support, which is super valuable and to your point delightful as a as an experience, like if you get that kind of outreach as a customer, but but looking for those signals, you made the point earlier that there's so many teams in the system. If you're looking at signals from tickets and product insights and logs and everything else, you can you can create more documentation, you can create education, you there are other ways to support your customers as well than just the support team.
Charlotte Ward: 26:27
Um, and I think this is where um as as we're moving increasingly to a world where um support is being delivered increasingly by AI. I'm assuming that whole ecosystem can feed your agents to provide, you know, self-serve or AI deflected support, then you're left with a support team that has all the really complex issues, of course. And um, that's where you create opportunities inside support, right?
Alex Batchelor: 26:57
Yeah, yeah. I think the way that I see support roles evolving is um like a couple of different new kind of roles. One is actually the systems builder. Um, you go and actually figure out how to build a support system that um may be largely automated or providing assistance to people. Um the second role is it's more technical where you're now working on the hardest tickets that often your like vanilla coding agent will not be able to resolve and um and working working through those. Um and I think there's still a lot that you know humans can can can do there.
Charlotte Ward: 27:56
Um and then the an a third kind of role is the merging of customer success and support, where actually your the ability to build a relationship with a customer as they face an issue is because you have the time and because you have because the problems by their nature, I I think I would call this consultative support. Like the problems by their nature are longer formed, they're more nuanced, and so it's not a matter of find the answer with Claude or um, you know, in the docs or whatever, or from an engineer, um, and and pass it back. It's it's actually much more about like, oh, you want to do something more and something deeper with our product, I'll go on that journey with you. And that can be that can take a support ticket, you know, average handle time from minutes into hours or days.
Alex Batchelor: 28:54
Yes, exactly. Yeah. We had an example with a custom one of our customers that we're working with, where we actually have kind of largely AI agents, uh our agent responding to all of our support issues is the first line. I always respond later on every issue. So um, we had a customer ask for you know, run into an issue yesterday, and it turned out that the issue was really something we didn't yet support. Um, but uh the way that um GitHub works, it kind of made it look to the customer like it support, like we support it, but we don't. And and then I was able to have a discussion with them about, okay, well, why do you need this? Like what's the timeline? And it turned out that they had actually um acquired another company and they were planning to um merge the companies together, but hadn't done that yet. And that's why they needed this new feature. So it may eventually become irrelevant. And so it's actually like quite a detailed like back and forth that understanding the context of the business in order to um understand, you know, whether this was really an issue we needed to resolve.
Charlotte Ward: 30:06
Yeah, yeah. I I I I can completely see that. That I think the other the other way I sometimes frame this kind of consultative support idea is it's kind of use case two, you know, um, for complex problems, uh complex products, sorry, you you often have an implementation team. You might have a sales engineer or an implementation engineer, solution engineer of some sort in the first few days or weeks with a complex product. Um, but they move on, they move on to the next implementation, and you know, then you're with support. But what happens when you want to, to your point, refactor something or build something new on top of what was built during those first few precious weeks where you had that one-on-one attention, and suddenly, suddenly what you've got is a support team. And you know, worst case scenario it there is it's an AI agent, and you can't really explain to an AI agent deeply why you want this thing to function the way you or build this thing the way you want to build it, you need a human in there, and so that kind of understanding and deep dive on why is often something that a support uh AI agent or you know is is not capable of like dealing with that nuance over time as well, crucially, which is often what we're talking about here with that type of support.
Alex Batchelor: 31:28
Yes, exactly. And and not necessarily having access to oh, there was this Google Doc that you wrote when you were as part of like the statement of work for this company, and does your AI agent for support have access to that for that customer in a way that's not gonna give it access to that across customers as well?
Charlotte Ward: 31:51
Yeah, yeah, absolutely. And and that's really interesting, I think, then as well, because again, the problem with implementation teams is they work with very few customers at a time. And um, so they have deep knowledge on what a customer's trying to do, or what a couple of customers are trying to do in the moment. They move on, they put those customers down. Um But they've in that time they've come up with clever solutions to things. Um, they take that with them. Those are often buried in a few, you know, gong recordings or something, or or DMs or Google Docs with the customer. Um, but you don't have access to those decisions or those clever clever implementations that were made inside the customer you're talking to. Never mind maybe something that was achieved for another customer two months ago that was a bit similar but not quite. Like your agent just can't access that kind of, you know, takes that kind of human eye on something that says, I I've spotted that we did this thing over here in a weird way. There actually is a good reason for that. I can lift it over here and do something slightly different with it. Like there's a there's a lot of opportunity you can create in that kind of um with that kind of visibility and that kind of um opportunity being created, right?
Alex Batchelor: 33:07
Yes, yeah. And part of what we're trying to do is like how do we enable companies to bring in more of that context, like bring in those custom Google Docs to be able to then surface that information to support folks as they are working back and forth with this assistant to help them understand, oh yeah, sales engineering did this during the PUC and they never actually finished that particular thing, and now the customer wants it. Or yeah.
Charlotte Ward: 33:43
Yeah.
Charlotte Ward: 33:44
Do you find I I guess the final question for me, from me then at this point, is like going back to something you said before, like when you've created all this time to work complex problems inside support, um, and you've created focus inside engineering, um, but that's sort of built on systems. Do these teams actually spend more time together as well? Is there an opportunity to for like person-to-person collaboration as well? Do you think?
Alex Batchelor: 34:15
Yeah, I think it's um well, there's a there's a couple things there. One is I think the better that your support is, the more your customers will report. And so while we, you know, we save, you know, make it faster to resolve any particular issue, if you make support really great, then you end up with more issues. And that's a great thing because it's more feedback. Um, and we find that um, you know, our most successful active customers in using the product are also the ones that are filing the most issues as well. And so um that that's one thing that happens. Um, but I I do think it allows also for support in engineering to get together and have a richer conversation where um both sides have more information and are able to um uh think more strategically about how to um how to improve the system um because you're able to take the time to kind of aggregate your learning and and share them work together. So um yeah, I I think we've we've seen that where the teams it does provide an opportunity for the teams to talk together.
Charlotte Ward: 35:49
Hmm. I I I would imagine as well, and I I I I do find this in in my day job even now is that when when you provide enough insights, they want to talk to each other because it uh a little bit of information, a little bit of the right information, the right focus enables the right question to be asked, or it enables the right people to get together to say, you know, and I find that there's uh like some of the best engineers will find out something that interests them and then want to deep dive on it, and the people who have the who can enrich those insights of the support people who can say, yes, that is a thing. And here's a customer I spoke to last week, and here's how they expressed it, and here's why, and and all everything we just talked about with consultative support, right? It it carries through because you find engineers become curious and they they cross the boundary into support, and then they learn with the support team, or maybe even directly with customers as well. They want to deep dive into actually what is being trying to, what is trying to be achieved here, what's the why of this behavior we're seeing or this number we're seeing.
Alex Batchelor: 37:00
Yes, exactly. Yeah. And I think a you know, a good change that is happening in the engineering culture is the idea of the forward deployed engineer that do get more involved with with customers. And yeah, I think that uh, you know, engineering kind of coming out of the ivory tower and saying actually doesn't really work. It's much better to be like hands-on working, working with customers and um support can be great, great partners in enabling actually, okay, I'm a I'm an engineer, I want to get more involved with customers. Like, how do I do that? Well, go and sit side by side with someone in your support team and and learn from them.
Charlotte Ward: 37:50
I couldn't I couldn't think of a better way to uh wrap up, actually, is just go and spend time with your support team and have those conversations because because they've got the information for sure and the enthusiasm for getting those problems solved. So yeah, absolutely. I couldn't agree more. Alex, thank you so much for joining me today. What a lovely, uh lovely um uh thought-provoking kind of um view on that that gap. It's so often a gap. But I feel like we can we can bridge the divide at last. So that um you've left me with quite a lot of hope for the future, which is great. Thank you so much.
Alex Batchelor: 38:26
Yeah, thanks for having me, Charlotte, and for for being someone who is uh you know helping to bridge the gap.
Charlotte Ward: 38:33
Yeah. Thank you so much. Will you come back and have another conversation another time? I'd love to have uh have another conversation about this relationship or um indeed anything else in support, you know me. I'll I'll talk for I'll talk to anything. So we come back and have another conversation sometime.
Alex Batchelor: 38:48
For sure, definitely. I will um next time I'll bring uh um our founding engineer Sarah, who has been split her time between support and engineering across her career.
Charlotte Ward: 39:03
So perfect. Thank you so much. I look forward to that. Thank you for joining me.
Charlotte Ward: 39:10
That's it for today. Go to customersportleaders.com forward slash three one one for the show notes, and I'll see you next time.
