Managing Employee Change: Lessons From Salesforce and Zendesk Migrations | Ben Gardner, Salesloft

Ken Babcock (00:00.797)
Hey everybody, welcome back to season two of the Change Enablers podcast. I'm super pumped to have Ben Gardner with us today. Ben is the VP of Customer Experience and AI Strategy at SalesLoft. He got into that role because he was the VP of Customer Support and Enablement at Drift, which was acquired by SalesLoft. Ben's got a wealth of experience in SaaS. He spent about eight years there.

and 10 plus overall years in leadership, three years in education. there's a lot of stuff that we're going to be, you know, be, being able to pull out of Ben, a lot of insights. I should also mention he's an advisor at a company called built first. Built first is a platform that allows anybody to create a partner marketplace. Pretty cool. Whether you're a perks marketplace, integration, reseller service. it's kind of all in one. And so Ben works with, with that team too. The fun fact that I wanted to share about Ben.

and we were actually just reminiscing about this. Ben was the champion of the first ever Tango pilot. That was in January of 2021. Product was really early, pretty rough around the edges, but Ben and his team over at Drift gave us invaluable feedback and set us on a pretty cool course. We're also gonna talk about Ben starting his career as a math teacher. I think that'll be fun to dig into.

And he's also a passionate cook. So after the episode, Ben's gonna share some resources from his time at Drift and Sales Loft. If you wanna just return the favor, send him a recipe, I think that's gonna go a long way. So with that, Ben, welcome to the show.

Ben Gardner (01:44.174)
Thanks Ken, I do have to ask since you said welcome back to season two, did season one end on a cliffhanger? Like was it kind of a...

Ken Babcock (01:51.673)
big cliffhanger, we were like, you know, who's gonna be this mysterious first guest? It's you, man. You're the cliffhanger, it's you. No, but it was, yeah, it was a great first season. Lots of awesome episodes in there. And, you know, some folks who had experiences similar to your own, but maybe with a different flavor. So, maybe that's a good time for us to.

Ben Gardner (01:59.342)
nice.

Ken Babcock (02:19.224)
to start off, I mentioned the math teacher piece, which I love. I think in an alternative universe, I would probably be some kind of teacher. I don't know if I could quite stomach math, but you did that. How did you make the switch into ops? And what have you taken from your experience as a teacher into your current role?

Ben Gardner (02:41.327)
So I taught high school math for three years, algebra, geometry, and algebra two. And I start with that just because that helped me get into where I am and make that decision because teaching high school is not easy. It's more difficult than anyone could imagine. And I specifically chose that for some reason. I thought middle school would be a little bit harder because I was like, okay, well maybe, you know.

all the emotions running through kids will be a little bit complicated. They'll grow out of it by high school. Not a chance, not a chance at all. So while I was there, like I was just, you know, reaching out to contacts. I actually reached out to my sister who worked for a software company, ConnectWise. And I was like, you know, are you hiring? I'd really like to get into that because I thought the space would be really nice. And that's how I got my foot in the door and ultimately ended up to kind of being where I am now. But the biggest lessons.

Ken Babcock (03:10.103)
You

Ben Gardner (03:36.847)
that I would say I learned is two different things. One from just an approach perspective is it's all about problem solving. Like math, teaching all those things are build a plan, figure out how to execute. The more thorough your plan is, the better the outcome. You know, a teaching day could go awry if you walked into it going, I'm just gonna teach them how to find the slope of the equation. No outline, whatever. That was a bad day.

Those were the bad days where I was like, I got this, this is easy. And then the other thing would be from working with students, patients, how you kind of coach and develop people is very similar. I'd say adults aren't too far off from how high schoolers are and like they're trying to do something and they don't quite know how, but you have to approach it and understand them and realize that it's not a one size fits all approach.

Ken Babcock (04:32.531)
Yeah, I think that's huge. And I think there are some themes there that we'll probably revisit in some of the questioning. I think one size fits all is something that we all are wrestling with constantly because it just doesn't really exist. And in fact, at Tango, we talk a lot about the software adoption lifecycle, which is a framework that we use to kind of help explain what companies undergo when they...

when they decide to adopt new software. And we use this framework trying to say, hey, everything kind of fits into this framework, but there's so many edge cases within it, and there's so many unique anecdotes even within those steps. And so I feel like a lot of times we're constantly trying to make sense of the world and describe the themes and frameworks, acknowledging that there isn't a one size fits all within it. And we'll get into that today. And so...

I'm really curious, we're gonna get right into brass tacks, but I'm really curious, you have a current project right now where you are migrating Salesforce within your current company, Salesforce, or SalesLoft, a lot of sales, sales, et cetera. I'm curious, tell us a little bit about that, what was the impetus for it, why are you doing it, and kind of what's at stake?

Ben Gardner (05:56.943)
Yeah, so Drift was acquired by Salesforce and so looking at that, you really don't want to have multiple systems. You have to figure out how does everyone operate under one roof. And in this situation, pretty thankfully, is both of us were using Salesforce Service Cloud for our support teams. So we were able to kind of look at it and go, all right, this should be pretty straightforward. I'm going to say that straightforward in quotes because it's just one system that's the same thing to the other.

But, you know, as we're going through that, the whole idea was we don't want to pay for two different systems. We want all of our data in the same place, all of our customer information in one location. And so getting everyone from the Salesforce platform in Drift to the Salesforce platform in SalesLoft is our current project that we're undergoing. And it is, it's a lot more complicated than I originally thought, but I'm putting more effort into it this time than a previous example that I've got.

Ken Babcock (06:56.206)
Well, you would love, I mean, we talked about season one. Our dear friend, Demar Amaker, did an episode talking about merging two Salesforce instances, and it was gnarly. So you guys should connect. You should listen to that episode. Obviously, there's some value in just keeping everything consistent, but was there a...

a business need for this, were there clear metrics that the teams wanted to move? Beyond just like, let's not have two, let's have one, what are you hoping to drive?

Ben Gardner (07:37.231)
For one, it's consistency for our customers as well as our internal teams, but also efficiencies when we looked at it and everyone out there can think that you're doing everything perfectly fine, like you've made all the great decisions. But as we were going through this, we're like, there gotta be great things that we were doing on the drift side, as well as great things on the sales loft side and figuring out which ones are the ones we want to move forward with. What do we want to kind of change and pivot away from? And so ultimately it is,

finding the gaps for each team and going, let's build one super team. I guess kind of like the Avengers here is like, we're going to combine everything, but in the best ways possible, not the worst ways. And so that when we walk out of this, the idea of being every single person is able to do their job efficiently, effectively. Our customers get the help they need. Our success managers and services can see all the data that they need without all the extra stuff that if you've had a system for as long as we did and SalesLoft did.

you realize that you've got fields that nobody's touched that just sit there and you're like, but this is taking up space or it's on that screen. I don't know why, but nobody ever said anything. And it's kind of trying to remove all that all at the same time of bringing the teams together.

Ken Babcock (08:51.882)
I love that. I want to talk about that a little bit later because I think, you know, the Avengers build the super team, take the best practices from each side and combine them. You know, it's a really lofty aim. I'm sure it's not as easy as it sounds. You know, I think folks objectively evaluating what's working, what's not is always hard, right? And you're going to run into that. So we'll talk about that a little bit later. Before we do that, you actually had a similar experience when you were at Drift.

You migrated Zendesk to Salesforce. You shared with us that you learned a lot from that. And so hopefully, you're taking all those learnings and you're saying, you know what, this thing at SalesLoft that we're doing, going from one Salesforce instance to the super instance, that's gonna be a breeze, right? So talk us through that experience and what were the big learnings from going from Zendesk to Salesforce while you were at Drift?

Ben Gardner (09:44.688)
Yeah, that one is a I love that example because my team never lets me live that one down Because I fell flat on my face like with that thinking this is gonna be pretty easy Let's move from this system to this and I'll start with the reason why? that we ended up choosing Salesforce was our entire services success and sales team were all using this as a platform and For them to understand the customer tickets the issues that were coming in

We either had to get them a seat in another system, build a custom report to push things over, and it wasn't always accurate. And so it was a better decision to say, let's all be in one system for a 360 view. So that's what got us there. And the reason why I'm starting there is it started out as a business decision for how can we be more effective, but that didn't cascade its way all the way down to how is the team going to be using this, which is where all the failures and learning came in.

Because I kind of went through and as we were preparing for this mapped it out and this was the shortest like slide I could ever create of here was the plan it was Let's meet as a leadership team talk about what's important. Let's meet as an operations team of what do the leaders say needs to make its way over And then let's roll this out to everybody and what that turned into was all of the agents on day one had what was validated

by us as leaders going, they can create tickets, they can do this, they can send emails. But immediately we got flooded with questions of, well, where is this? Where is this macro? Well, how do I do this? What is the process for this? And we're like, well, we have that documented. It's like, well, you documented this one part of it, but not everything that we do for our day to day. And so got a ton of feedback from everyone on the team. One of the biggest impacts and learnings that we had too was we do a,

quarterly employee net promoter or employee satisfaction survey. And support typically was the highest rated team in the entire company. We dropped below the success services, like every team, it was like all of a sudden support was down near the bottom because that survey went out right after we did this launch and comments were like all going through everyone of needing to be more prepared, wish we had more feedback, wish you had done a better job of.

Ben Gardner (12:07.921)
understanding what our day -to -day looks like. And so it was a huge road, you know, to climb back from that. And so we had to very quickly go, let's meet with you, talk with you, figure this out, figure out what's important, add that in, get that back in their hands, kind of go through that motion again, building immediate feedback channels for if you're missing something, tell us right away so that we can bring it back. And that went on for, we launched officially in January of 2022.

And we had to continue collecting that feedback for about three months because we just weren't sure what we were missing. And to ask your team in the middle of supporting customers to say, hey, can you also give me this feedback about what's not working after knowing we already messed up? I know it wasn't the greatest thing for them, which is why I think it took a lot longer because it wasn't part of the let's do this right the first time or they're more eager to do it. This was, you should have thought about that sooner. You should have thought in.

They were right. They were 100 % right.

Ken Babcock (13:10.182)
And why do you think, because you're not alone in this. I know you're a humble guy and you're saying you fell flat on your face and your team likes to keep you reminded of it. But leadership kind of overestimating the superpowers of what software can accomplish and probably underestimating the change management. I don't think you're alone in that. What gave you confidence as a leadership team initially that this would go off without a hitch?

Ben Gardner (13:41.329)
I think the big thing was we met and we talked about it and we said we're going to outline what was important and we got these people in a room together saying this is what is important. And so, you know, we thought that this group of people knows what everyone does. They've got a good pulse on what that day to day is. And I think that's where we had our biggest mistake. There was your end users of any software tool that you purchase anything that you're going through.

They're the most important people because if they don't adopt it, I think we were lucky that they had to. So we're going to get all that feedback. We're going to make sure that we hear from them. But if it's a luxury tool that's not necessary to do some of the things that they've got to do, then you're going to just start losing adoption. People aren't going to do those different things. You're going to figure out you wasted money on this. But it's because we didn't connect directly to the people using the software day to day.

Ken Babcock (14:37.894)
Yeah, and that, you know, that sort of shined through in what you talked about with the NPS survey. Were there business metrics that were also impacted by this?

Ben Gardner (14:51.536)
yeah. So for key metrics and support, we looked at, time to resolution, customer satisfaction. we also, you know, kind of look at what the just volume and output is, from the team and our SLA adherence. So responding to customers within a certain period of time, everything suffered because it was just harder to do their job. from a CSAT perspective, getting feedback from customers, which, you know, I can dive into later too, is we didn't.

model completely the customer experience during the migration. So when we're thinking about the tools that we use, that was great. But we had cases in two different systems or tickets in Zendesk cases in Salesforce, and then figuring out, well, what happens to this email here versus this one? If this one reopens, where does it go? Which was a challenge. And so like everyone was impacted by this. And for a certain period of time there, it was me kind of reporting to all of ELT.

Here's what we're expecting. We know what's happening. Like, you know, the migration itself is decent because we got the new system up and running, but the outcomes are not going to be there until the second half of the year because we have to fix a lot of things.

Ken Babcock (16:02.886)
That is, so just to play that back, you had sort of this NPS survey, so team happiness and overall just motivation was suffering a little bit. But then you also saw business metrics across the board, handle time, CSAT, resolution, all of them negatively impacted by this migration. And this,

what you mentioned around this disconnect between leadership and your end users and not knowing what it takes in the day to day, that can be also really emotional, right? Hey, we've made this decision and here's how we're gonna tackle it. And then the reaction is kind of like, well, wait a minute, you have no idea what I'm doing day to day. You've completely glossed over the fact that I have to figure out how to manage this change now and there's nothing guiding me through that. In the software,

adoption life cycle that I mentioned at the outset, you know, the third phase for us is managing employee change, which it sounds like you were in the throes of managing employee change. when, once all that happened, how did you go about rebuilding your reputation and the partnership with your reps and getting people rallied around this migration?

Ben Gardner (17:24.785)
getting as connected to them as possible. And when I say that, I mean, in literally everything, instead of assuming what they were doing after that moment, what we ended up doing is every. Facet of how they do their job, every process. we wanted to really understand it. So we started doing ride -alongs, as we call them so that we could sit down and go, just do your day to day. We're going to sit here. We're going to ask questions. We're going to figure this out. we're going to try to understand, you know, what.

we could do better, what do we need to make sure everyone else understands, what do we not have documented? And so they saw from us, well, you really invested and you really wanna know, you're not assuming anymore. And then for future things that we rolled out or even just future projects and programs that we had going on, the two things that we stressed were number one, the why behind it. Like I think it was, they understood like this was a business decision from the top, but we didn't really focus as much on the why.

now that they see the why it's, you know, this is really important. I need to be bought in, not just you changed how I do my day -to -day job and like, this is really bothering me. And then the other thing is including them as much as possible in the process. So getting their feedback, making sure they understand it, figuring out if there are things that they think we shouldn't do, make sure you document that. And if you still need to do it, you better have a good reason why, or you look at it and go.

Well, maybe that's not as important for us to do and starting to phase things out as what do you need for day one and what can you do for like day one 80 so that you have that plan? Because if it's important and we think it's important as a business, the success of the rollout is more important than that one particular thing. And so if you don't need to do that day one, can you do that later as you get them more ramped up and kind of bought into it instead of just saying,

here's everything we're gonna cram down your throat, you're changing how you do this, you're also doing this, you don't wanna do this, but we decided to just ignore it, you're gonna do it anyways. You have to be more strategic and go, as a leadership team, we can't do everything they're doing. You can't answer every customer ticket, you can't get on calls. So if you don't wanna do that, then make it easier for them to do that so that you can ultimately kinda hit your outcomes you're looking for.

Ken Babcock (19:43.014)
I love that concept of ride alongs too, just this idea that you really need to go straight to the end user and not talk about things in a way that's focused on feature parity or comparing pieces of software. It's more about what is the job to be done? What do you need this piece of software to do for you based on what you've done in the past? And that I think, that disconnect that...

you highlighted earlier on, that can kind of be exacerbated, because that's how a lot of sales processes are with new software. It's like, you're on this? Well, we have this, this, this, and this. And of like, of course, it's going to translate perfectly, but you forget kind of that perspective of what is the job to be done for my end user. So I love how you kind of 180 dot, went straight to the source and figured it out. Let's jump back to the present. So we're coming back to...

at Salesforce, we are creating the Salesforce super instance, taking the best practices from both sides. You've gotten a crash course in how to do this effectively. How are you approaching this one differently from when you went from Zendesk to Salesforce?

Ben Gardner (21:01.969)
I'd say we are not making the same assumptions that we made before. And so from the very beginning, you still need to, I would say you don't want to throw out as a leadership team, try to figure out and think what you think should be done, what good looks like. That's just your starting point though. That's not where you're going to dive into the rest of the project. And it was let's meet as leaders and say,

Here's the processes we think are important. Here are all the fields and data points that we also think are important. And then take that to a group of stakeholders and say, what are your thoughts? Are we missing anything? Would you change anything? Is this really important to your day to day? So like we're getting that feedback from the team itself and we're not just going from a VP to VP level. We're like going down to directors, managers, our QA team. We've got team leads, just everyone going.

let's get that feedback as we move along. So that when we create, I'd say the big difference here and we're pretty close to launching it is building a sandbox environment for every team to go through user acceptance testing. I think, and in this case too, that testing is a phased approach of again, here's what we think is important. And then once they go through it is what is missing from this list of are you able to do your job?

And then we're going to build the new testing into it so that they can go back, but making sure this is a longer process. Beforehand, when we went through the Zendesk migration, it was, you know, really kicking things off in October and then launching in January. In this case, our goal is to get everything up and running by August. But we started our discussions in January with here's where we needed to really think. And then you start bringing everyone along.

So it's a lot longer, a lot more detailed, mapping everything out and figuring out what's important to us as we kind of go through this.

Ken Babcock (23:03.085)
So just to play that back for everybody, that's three months of lead time when they went from Zendesk to Salesforce, eight months of lead time in kind of merging these instances. So clearly you're taking a much more meticulous approach to it. It's the sandbox environment, allowing people to kind of test what it's going to look like. Are they testing those on real live workflows, tickets? How are you structuring the sandbox environment?

Ben Gardner (23:30.514)
So it's not going to be a real customer ticket to start, but it is going to be the exact same environment that we assume that they're going to be working out of. And then, you know, getting that connected afterward, we are going to have both systems set up. So we are going to get people using it. I would say it's a little bit harder in support to say you've got, you know, the legacy system and the new one, because it's kind of hard to kind of get everyone there, but we will have the legacy one for.

fallback option, but our goal is to get everyone in it by that August timeframe. And to make one clarification, the thing you said before, you graciously gave me three months, but if you think about it, December is a holiday and that really takes out half that month. You've got November as well with PTO and everything. So I'm going to say it's probably about two months of real work going into it, which was not good planning either, planning around a holiday.

Ken Babcock (24:11.883)
Yeah.

Ken Babcock (24:21.675)
Sure, sure.

Ken Babcock (24:26.891)
Yeah, yeah, no, I definitely did forget that piece of it. So, Forex, the amount of time. I know Ben, like in your role to VP a customer's experience, you're not quarterbacking this. I mean, you're the executive sponsor and you're accountable for it, obviously, and I think you're taking a lot of your learnings to make sure that this time around it's gonna be better. But who else are you enlisting as a part of your...

migration team, and maybe that doesn't have to be specific people, but what types of roles are they playing? How are you ensuring that on the sales loft side, things are going smoothly?

Ben Gardner (25:07.858)
For us, having our Salesforce administrator in there, obviously, because they're gonna be the ones setting a lot of this stuff up, all of the different managers across the different teams, at least one from each, I'd say, like respective group, like for us, there's different tiers. And so you need a representative of each tier, because they're gonna understand the differences. Again, I think we said it earlier, you can't assume one size fits all. Tier one and tier two have different workflows, so like you need to understand that.

The education component, like the big thing here is like, you're not just moving ticketing systems, which I think is where the bulk of our conversation is, but you also have to move all of your content. So your customer facing documentation. and with that, like other stakeholders that we have are customer success, professional services, the idea there being they're going to have to interact with the team. So is it going to be the same for them or different? are they using any of those education materials that I said before, because if you're moving that over.

then where is that gonna be? Like is it a new link for them that they need to update? Sales, you know, again, this whole thing is once you sell to a customer, they're still gonna have an account owner. And that person needs to understand, well, if things are different, is the data still there where I'm like trying to see, do they have an issue? Before I start talking to them about these new features or rollouts, I don't wanna sell them something if they've got a pain point. So pretty much what I'm saying is everybody is involved this time versus just a handful of people.

Ken Babcock (26:37.158)
Yeah, I mean, still helpful for, I think, I think folks listening to understand that this is not just a one person undertaking. I think commonly, you know, we are sold the value proposition of pieces of software and we think, of course these things are going to be intuitive. Of course, you know, we're going to realize the business outcomes that we hope for. You know, that's why these products are built, but there's, there's some real preparation.

that goes into it. In part of your preparation, you also mentioned user acceptance testing. I want to talk about that a little bit. And maybe this is a point where we get a little bit in the nitty gritty, but in order to test, what are you asking? Who are you asking? When are you asking it? How are you making sure to me, it sounds like you're trying to make sure that you've kind of got this clearance to go ahead and move forward. So maybe is there a threshold where you say,

Alright, we've passed. Let's go. We're ready for August. What does it all entail?

Ben Gardner (27:40.658)
So that's a very good question. Like looking through it, we've got the different stakeholders, but the each tier. So I'm just going to use our example here, the tier one reps, tier two reps, our managers, and then our customers. Like everyone needs to have, what is their experience and can they submit an issue or a ticket, get responses, be able to get the questions answered. Can we escalate properly or work with different teams as necessary?

As a manager, can I get all the data that I need so that I can do my job? I can hold my team accountable, but I can also make sure the customers are there. And then from the customer themselves, are they able to again, reach out to us, contact us where in my opinion, it should be like nothing happened. So you want it to be exactly the same experience unless you're making improvements. If you're going to implement like a brand new portal and you never had one before, that's great. But otherwise you want them to think that whole idea is like.

nothing changed. They're still able to email the same address, get the same responses back, and then, you know, in that case, you're golden. But then for us, like what the requirements are, again, is all of the different necessary things that you need to be able to do your job from start to finish have to be checked off for it to be good to go. If any one of those things are not available, then you can't say that you're ready because we looked at it as you have a day one checklist and then

You know, again, like I think I said earlier, like day 180 or whatever else threshold that you want, but day one, I need my team to, for example, be able to send an email response to a customer. If they can't, that's not a, hey, we'll get back to that later. It's a, you can't move forward with anything else until you get through that. So that's how we structured it is the things that you need to be able to do to do your job have to be checked off before you can say this project is good to go.

Ken Babcock (29:37.953)
Wow, I mean, that's a stark comparison to the two month rollout last time. I'm curious, when you think about this testing, you're in a sandbox environment, you're kind of asking people to self -report on whether they're ready for those day one activities. Are you carving out additional time in the day to work in the sandbox? All these folks have...

jobs and expected efficiency and things that they want to do, how are you getting them to engage with the testing, with the sandbox environment and when?

Ben Gardner (30:20.211)
So we have all of the testing mapped out. Right now it's in a Google Sheet and the idea being follow all these steps. And the reason we did that first before I get into the other things is you have to be crystal clear about expectations. And so we wanted to make sure they knew going into it, here's the time commitment we're saying, here you can visually see what it is and they can tell us, is that accurate? Are you going to be able to go through that test in that reasonable amount of time? But then the other part is,

carving out that time and expectation saying, we're going to block off your calendar from this time to this time. We know that means these tickets are not going to be addressed. So we will take care of that piece. And if that means in our case, we staff people to watch like a Slack channel to see if questions come through, can you help each other out? And a manager can step in and watch that during that period because we have reps going in and actually doing the testing. So it's making sure that we balance it out and...

not ask them, do this, have a backlog and then feel stressed because I'm coming back into it. It's how much can we take off of their plate? Are there other things we can also do? But this was the most important thing. So when it is scheduled out, it is, you're going to be given this time because we find it to be extremely valuable. So trust us that we will take care of all the other things so that you don't have to worry about.

Ken Babcock (31:45.404)
I think that ties nicely to how you were describing, explaining the why. Why are we doing this? What's the business motivation? And also, we feel so strongly about it that we're sort of giving you a pass to say, hey, you need to go learn this thing. We understand that typically what would be expected of you would be this, but we're bending that a little bit. And I think that those two hand in hand also just.

have a bit more empathy for the end user. So it sounds like you're tackling that in the right way. August is coming up. We're in June now recording this. It may launch a little bit later, but we're in June now. You're two months out. Obviously everything's gonna go off without a hitch in August, right?

Ben Gardner (32:32.787)
I mean, that's the hope. I will say I feel pretty good because of the preparedness of the team, because of all the different stakeholders, because of everything from the different mappings that we did and the requirements that it's a lot more thorough than the previous one. And in this case, there's also, I think throughout the process at what most people don't really, I'd say, encourage their team to do, but we've done is tell us what the obstacles are.

Ken Babcock (32:34.107)
I'm out.

Ben Gardner (33:01.876)
Tell us what the dependencies are. I have an example sheet to share with people if they're interested later is list that out. Have people call out, here's the dependency. For example, if you've got data from your customer side of things that need to come in before you can start doing case data, that's a dependency. I can't do my job until this job is done. But don't just say, hey, we've got it. It's.

Ken Babcock (33:10.427)
Awesome. Thank you.

Ben Gardner (33:30.579)
call that out because then as the team quarterbacking the whole project, we can go and talk to these other people and say, hey, can you push your deadline up? Can you do this so that we can take this part in? But I think that that's the big thing is they've been calling these things out left and right. We've been getting them addressed. And so we're going to be much more likely to launch successfully because they've been able to, you know, without feeling they're hurting someone else's feelings, say, I can't do this if this thing doesn't happen.

Ken Babcock (33:58.296)
And is that gonna mirror sort of what your ongoing monitoring plan is gonna look like post August? I'm sure it's not just hey we launch, wipe our hands clean. You're probably gonna be checking in at various points to see how things are going. Maybe not, I don't know. I'm assuming you are. What is that plan post August? How are you gonna make sure that this continues to be successful?

Ben Gardner (34:23.028)
A couple different things, the in the moment one that really helped before, and I'd say the positive outcome from the failure before is creating a mechanism for people to say things right away. Here's what I'm saying what it is, because if it's urgent or a deal breaker, you can make that change quickly instead of, hey, every week we're gonna meet and talk about this, which we are gonna do as a key team is like still meet weekly and figure out what that.

You know the outcome is but I also think from a manager level getting them to talk to their employees Directly in their weekly one -on -ones checking in how are things going? Making sure that you know, you're checking in on the rollout specifically not just how are things going but asking very specific intentional questions such as What's not working? I think quite often if you just go with how's it going? People don't want to tell you everything or they might ignore it. I

And just say like, it's fine. But like very intentionally say, tell us what's not working right now. so that we can focus on that. And then, you know, but on the flip side, I think when you're doing this with two systems is also asking, well, what do you like better? You know, is there something that you think is different since now that we changed some things that you're like, Hey, I'm so glad you don't ask me to do that anymore because I didn't like doing that. Now I don't have to, I feel happier. It's like, make sure to call that out. because then that's feedback when you share with everyone else will make the project stay.

you know, I'd say successful because now it's like, hey, we heard from you, you all love that you don't have to do this thing anymore. I'm just assuming there's gonna be something that they're gonna be really happy about not having to do anymore.

Ken Babcock (36:02.509)
I'm sure, I'm sure. Inertia is a tricky one. Some people just keep doing things because it's what's expected. I'm curious too, is there any horse trading going on? No, we have the best practice. No, we have the best practice. Is there any sort of infighting happening or are people pretty even keeled about defining that super instance?

Ben Gardner (36:26.996)
I'm pretty lucky, I would say that we're pretty even keeled and it's largely in part due to before the acquisition happened. Ironically enough, I was already meeting with the leader of support at SalesLoft and we were trading best practices saying, what are you doing right now? What am I doing? Let's figure out who's doing things the best. So we were already saying, hey, I don't want to do this anymore. Let's take your way. Let's take this way. And so it just fed into this process.

Ken Babcock (36:43.187)
Nice.

Ken Babcock (36:54.321)
That's great. Well, Ben, I mean, thank you so much for sharing that. I think that coupled with the resources that you've generously provided, everyone is going to help a lot of folks, not just, you know, in bulletproofing their own process, but, you know, acknowledging some of these intangible things that come up, some of the emotional aspects of how people's day to day changes. I think all that stuff matters. I do have one last question for you and,

This is a fun one we kind of end on with most guests. What's the biggest misconception within operations or, you know, we can even broaden that a little bit to include kind of the AI piece of your role too. Like what's the biggest misconception that people have about either of those domains?

Ben Gardner (37:42.996)
I think for, for AI in particular, it is this idea that it's just going to be this, I don't know, miracle pill that saves everything. you talked about it earlier, but it does require someone to work through it, set it up and whatever those things are. So you're not going to find an AI back tool that is just going to do everything. You still have to teach it and train it. And maybe it goes back to my teaching days. And cause I also worked.

at an afterschool daycare for a long time is that AI starts out like a two -year -old, and if you keep treating it like a two -year -old, you're gonna get two -year -old outcomes. If you start to educate it, make it better, feed it better sources, it's gonna be better. And so thinking about that when it comes to any AI platform or AI features within a tool is it's gonna be good, but you have to make it better.

to meet your needs. So just make sure you're not looking at it as I'm gonna go spend all this money and buy this thing and it didn't work. It might be because you didn't put the effort into it, kind of like me going to the gym and saying, you know, I should be in great shape, but you're doing the same thing over and over again, it's not gonna change anything.

Ken Babcock (38:55.565)
I really like that analogy, that's pretty funny. But yeah, and a lot of these AI companies that are out there, they're sort of perversely incentivized to make those claims that this is gonna be a quick fix. But I think the sooner we all get around to embracing the reality that a human has to be in the loop to make these things really special and that human brilliance isn't going anywhere.

I think that's really the inflection point that we need. So, appreciate that insight. And Ben, appreciate having you on the episode. I mean, I think there's a lot of gold in here. And it was good to just reconnect. It's been a while, but it was good to see you. And thanks for joining.

Ben Gardner (39:39.732)
It's good to be here, it's good to see you too. Better lighting than the last time when you were in that basement at HBS.

Ken Babcock (39:44.749)
I've upgraded, man. I've upgraded my surroundings. I might need to tweak some of the lighting. I'll ask the audience to see if I need to fix some lighting in this room, but much better than a basement, I can guarantee it. Thanks, Ben.

Ben Gardner (39:59.348)
You look great. I think it's great.