Ep#58: The Role of Customer Success in Aligning Business Outcomes with Technical Solutions ft. Josh Levin (Manager of Customer Success, Honeycomb.io)

Josh Levin 0:01 To get close to the users, you have to go through us, through customer success. And so there’s naturally a lot of points for us to communicate and be that gateway between the end user and product engineering. And they acknowledge that. Taylor Kenerson 0:15 Welcome to the Hyperengage Podcast. We are so happy to have you along our journey. Here, we uncover bits of knowledge from some of the greatest minds in tech. We unearth, the hows, whys, and whats that drive the tech of today. Welcome to the movement. Hello, Hyperengage Podcast. My name is Taylor, and I’m here with Josh from honeycomb. Hey, Josh, thanks so much for joining us. Josh Levin 0:44 Thanks for having me. Taylor. Taylor Kenerson 0:45 Amazing. Can you just walk us through your journey on how you got into CS and how you found this little niche in Honeycomb? Josh Levin 0:54 Yeah, absolutely. It’s, as it is the case for a lot of CS folks. I mean, there is no traditional path. I mean, for CS, and I’m a great example of that. I got my start, actually in a completely unrelated field. Again, not that unusual for CS, I was a neuroscience researcher coming out of coming out of college. Taylor Kenerson 1:15 wow. Yeah, you. Wow, you got it back up there. So you graduated college as an in this as a science major. Josh Levin 1:24 Yeah, I graduated college with an art with a neuroscience degree. And went into what ended up being about a year and a half to two years, like neuro neuro research, because I left that I left college thinking like, I’m gonna be a researcher for the rest of my life, do academic research. And I did it for a couple of years. And it wasn’t for me, it just was not my cup of tea. It’s like, I have a ton of respect for people who do that. But it’s a grind. It’s a really gnarly grind, because you’re, you’re living paycheck to paycheck for most of your career, even as a senior researcher, because there’s so little academic money to go around for such great projects around the world. So like you’re you’re really scrappy, you really scrappy, you’re really fighting your way up from from day one. And it’s, it’s really, really tough. And it really just wasn’t it for me for a variety of reasons. But yeah, so I did that. And and when I left, when I was like, really kind of at the bottom, and just being like, I really hate this, I don’t want to do this anymore. A friend of mine from college, who was working in tech, working for a small tech consultancy, doing like implementations, he reached out to me and said, like, hey, you know, we’re small, we’re nimble, we can like we might be able to bring you on. And the rest is kind of history. From there, I got brought on and seven or eight years later, here I am. Taylor Kenerson 2:47 Wow, so you initially got brought on to that company in a customer facing role, and then work your way around into different that’s amazing, incredible. I I obviously most people in CS have, you know, a unique journey and pathway getting into it. But your is a neuroscientist, but it actually, it’s interesting because neuroscience, you’re learning about the brain. So you’re learning the fundamentals of how the brain works. And if you can take that perspective when you’re talking to customers and clients like human behavior, and something that studied forever. And you have an insight or a different perspective and a different look on how the human works and how the mind works and making decisions and all of that. So can you just briefly touch on how maybe your science background gives you a unique value to you know, the situations you handle and how you approach things? Josh Levin 3:37 Well, yeah, that’s a great explanation Taylor and definitely aligned with like, how I positioned myself in my early in my early interviews, I definitely said like, Oh, yes, I can somehow connect my neuro research background specifically to understanding how people think and blah, blah, blah. But like, again, we’ve all been through those early career interviews and know that like, that’s, it’s a bit of a stretch for some of those. And I’ll be the first to admit that like, as much as I want to say that helped me, it really didn’t, I think like, like how it got me into customer facing roles is like, really two core things that are really similar between the two fields as weird as it may sound. One is that they’re both very heavy in problem solving. Like that’s like it’s something that you do on a day to day basis in neuro research. Obviously, it’s something you do in CS too, especially in a technical CS role. You’re problem solving everything from internal processes and data questions to pay customers coming to me with a problem I need to help solve it either technical or strategic. The other part of it is that neuro research, especially because the neuro research I was doing was very like it was a lot of the work was running patients through through like tests and through like programs. And I was working a lot with with kids who were on the autism spectrum disorder, sorry, who had on the autism spectrum rather. And so I got, I think pretty good at engaging with folks at very He’s levels both at various levels of understanding of neuroscience, but at just various levels of interact, like wanting to interact with me. And so I wanted to continue doing that I wanted to continue building relationships and working with people while also doing something that that like scratch the itch of problem solving and see us ended up being that thing. Taylor Kenerson 5:20 I love that that’s really those are two unique comparisons, they the two fields might not seem similar in any sense of any sense of the words. But when you kind of break it down to the fundamentals, it does have some core similarities that you, you can who, who you are definitely looking back now might have never thought that you would be, you know, problem solving and dealing with a different kind of customers and clients, even though you were training kids back then to do something different. But you’re also now almost training kids, in a sense, obviously, they’re adults, but they’re kids in the sense of immaturity using your product. So you have to train them and show them the value just like you would show a child trying to help them understand something in life. And it’s a similar, you know, piece there. Can you dive into honeycomb a little bit? What what do you guys do? And then who your customers are and who you serve? Josh Levin 6:13 Yeah, absolutely. So honeycomb is a developer tool. Ultimately, it’s a tool that allows users to see the health of their production systems. And what we mean by production systems is think like, when you go to Facebook, Facebook has tons of engineers, if Facebook has having a tough day, and like Facebook isn’t loading for users, that’s usually indicative of the systems that that software is running on. Or having he’s having problems, either the software itself is buggy, or the servers that are running are buggy. All those systems generate signals about like what’s going on. And it’s one of the challenging parts of being an engineer is taking that signal and making sense of it, like, Okay, I see all these all this log output, all the stuff our systems are seeing are wrong, I see all these metrics and like going up and down and like, there’s a almost like a, an art and a skill to reading that and making sense of it. And honeycomb is a tool that allows you to do that. But in a way that’s doesn’t require a huge amount of tribal knowledge and allows you to go in, and and present information in a more consumable way. So and as a result of that our users are primarily engineers, at large fortune 500 companies for the most part, and all very, very talented engineers, like most smarter than much smarter than me. But it’s very humbling and really wonderful working with them every day. Taylor Kenerson 7:32 That’s great. And because you have a high touch model, obviously serving those large enterprise clients, how do you prioritize the customer success? Engagement? You know, that’s a huge, obviously, it’s a huge topic. So can you walk us through, you know, the journey of how you go about that? And how you actually take steps to ensure that that customer is successful? Josh Levin 7:52 Yeah, absolutely. So our our model is very, is very slack based as not to dive too deep into the weeds of the tool itself. But the reason I say that is, for the most part, especially for our enterprise customers, you’re right, we’re very high touch. And we for each of our enterprise customers, we have a shared Slack channel with them, we, we try to meet with them as much as possible usually ends up being about once a month, because we know they’re busy, but we want to be with them pretty regularly. And we want to keep those communication channels as open as possible, we don’t want them to have to rely on email. And getting that automatic feedback, especially for engineers, who oftentimes work at the timescale of minutes. Like they have to, there’s a fire, they don’t get can’t wait a few hours for an hour for an email. That being said, we have gates in place to be like, if you if you nudge me at seven o’clock at night, I’m not going to get back to you at 705. Let’s be realistic. So like we have guardrails in place to protect our our own CSMs sanity. But that touch model of providing an open channel for communication has been really, really positive for us. We have it for all of our enterprise customers. And then for our our customers that are a little earlier on in their journey, like they’re not full enterprise users, we’ve started building out a scale program that does rely on on email, because we just can’t afford to set up that many Slack channels at that scale. But we tried to we’re trying to engage them more and more over the last six months as well. Taylor Kenerson 9:21 I’m glad you touched on the balance of the automation and like actually engaging with the customer humanly How do you balance the two and like when do you know what should be you know, automated, obviously, the repetitive tasks, but how do you know sometimes when to interject as as a CS team? Josh Levin 9:38 Yeah, it’s a really tough one because honeycomb as a tool it generates itself generates a lots of lots of signal. Ultimately, when you talk about automation, automation is only as simple or as complex as the signals that it’s based off of. So if your tool only does one or two things, there’s a pretty straightforward thing you can do. They’re made a heck of a lot more because there’s just, there’s just less for it to cover and less grammar to cover. The honeycomb is a developer tool. So it’s, in other words, like it’s an it’s an environment is it’s a data playground, as I sometimes like to say. So there’s a, there’s lots of ways for people to hold it, and to use it a lot of ways for us to interpret that signal. So as a result, it’d be really tough for us to like completely up end our enterprise segments, and automate, automate a lot of it for our enterprise segment, because there’s just so much to work with them on so much strategy, so much so much signal, we it is pretty high touch. But what we can’t automate are a lot of the alerts like because there are so many things about how someone can use their tool, both good and bad, and ways that they could be like maybe consuming their contract, really, hitting a wall with a tool that they just don’t realize is a wall, where that’s something that we are that we’ve already started to automate. And we’re still going to continue automating, like alerts. And so that’s a CSM, when they do engage has like a dashboard of here’s all the things that you should be talking to them about. It is admittedly somewhat aspirational. We haven’t done the thing yet completely. But it’s something we’ve started to do. And we’re we’re getting there. Taylor Kenerson 11:13 And now that you you actually talked on something like a dashboard, can you talk about what what the metrics look like to measure the customer success, and then how you use those metrics and that data to improve any of your customers outcomes? Josh Levin 11:27 Yeah, the our, the way we measure health or metrics that we rather retract to measure customer health, there’s a handful of them, but luckily, not too many. Ultimately, like contract consumption is one, we measured in a specific way. But it’s it’s essentially contract consumption. But we try to measure a lot of different like dimensions of the usage too. So we have like really high level stuff, such as Days Active. So over the course of the last 30 days, how many days over the last 30 days, were somewhat active in the tool from that team. We find that like, the are really successful customers are using it, at least like 20 to 25, if not more days, a month. Our really successful customers are using it every day. And so that that should measure like in some capacity, like breadth of adoption, we have a few other measures as well for breath. But ultimately, it’s what we’re trying to measure breath with that kind of thing. The other one is depth of adaption. So across our different feature functionalities are different our suite of functions, I should say, we have ways of measuring like, are they adopting this part in this part in this part? Well, were they missing things. Similarly, like the 30 day measurement is also kind of naive, because to say someone’s using it today, all they have to do is run a query in the tool. And that’s it. And that’s not really representative of like depth. So we have other ways to at the user level of measuring, like, how mature are these users that we built over the course of a few months, a model that’s informed with some machine learning code. Like how mature are these users as a whole? Are they are they users as a whole just like running one query? And that’s it? Or are they diving deep? Asking them asking this tool interesting questions. And we have measurements at a high level for those as well. Taylor Kenerson 13:16 You talked about the measurements, how are you measuring this stuff? Do you have different tooling in place? And what is like your tech stack? Like? Yeah, Josh Levin 13:24 so our data stack is it sounds complex, but it’s actually, I think, reasonably straightforward. It’s basically a bunch of signals like everything from like, their interaction with the basic interaction with a tool through like a MySQL store. Plus, like their stripe for like their financial stuff and all the signals we generate, although most of the use of stuff is coming from MySQL, it all gets smushed into a snowflake instance, through Fivetran so Fivetran takes all that data mushes it into a snowflake instance. In snowflake, we have all the raw data and then we do a bunch of ETL work on it using DBT so snowflake has both the raw data as well as the nice pretty cleaned up data. And then we take the nice pretty cleaned up data from snowflake and push it to our downstream systems like Salesforce like Gainsight like Intercom using tools primarily like Census which is a reverse ETL tool. And that’s kind of how we maintain it it’s through that that essentially three layers. Taylor Kenerson 14:29 Yeah, it seems it can seem a little complex but it all is obviously it makes sense in the steps that you know you’re using to engage with these customers. So can you walk us through a little bit how you as the CS team go from, you know, onboarding a client to then looking to expand them and what steps are like what key touch points that you have recognized that need to happen in order to expand that client not just retain them? Josh Levin 14:56 Yeah, the we very much are a land and expand type of shop We refer to ourselves like that a lot of Honeycomb in that. It’s because in our ecosystem, the like, there’s a lot of tools that are incumbent that have been in the in this in this sphere for, you know, 20 years. And we’re competing with them. So we understand that trying to sell them right out of the gates of like, yeah, you want to spend spent $50,000 with us, but it like they don’t, they need to be convinced there needs to be some kind of proof point, even after sales, our sales team does a great job of proving out initially, but they need to see long term retention, long term ability of usage. So there’s a lot of like, land them at this, work with them, show them, show them the way show them with their success, and then they’ll expand naturally at the first renewal and so on. But the way we do it, our touch model is not horribly complex. It’s just like any other typical CS model, you have a kickoff, you have a business review at some point in the year, ideally, not too long after kickoff, so you can make sure like, Hey, are we actually doing the thing after three months, and then meeting with them in a regular cadence. So in terms of like the touch points, the touch points themselves don’t really have, I think, a huge influence. And I wouldn’t say even the business review is like, there is the light. Now we’re going to get clear with you. But it’s I think it’s the continued engagement and the outcomes based engagements like not get it’s really easy to get lost and get getting stuck in the weeds with a really technical product. But we’ve we’ve worked with our CSMs. And our CSMs are naturally very, very good, very talented CSMs at taking that step back and asking the question of, okay, you’re saying you’re having this problem getting this data into a honeycomb or doing this thing? I don’t know, why, like, why are you trying to do this? What outcome? Are you trying to achieve? What led you to this point? And ask keeping things at that level and asking questions like that, that’s, I think, been the key differentiator and moving those customers along to growth. Taylor Kenerson 16:55 I still echo with that. Sometimes, when you’re in discussions with customer, they might present a problem to you. And if you’re too quick to recommend a solution, you might, you might be missing the real underlying problem. And that’s why it’s so important to not only ask the questions, but also equip your team with that confidence in asking those questions and unpeeling those layers to figure out why why are they looking for something like this and just uncovering all of those, you know, different aspects that can be contributing to why they’re even bringing up the problem or question in the first place. And I think as a CSM, you know, or anyone really within customer facing roles. It’s it’s vital to be curious, you need to be curious, you need to ask questions, and you need to, you know, feel confident in how you’re, you’re going about that. And that could drive exponential value by you just unpeeling a few layers, and not just going with the flow of as things are. So can you can you speak a bit on some of the challenges that maybe you experienced as a CSM and maybe one a couple things that you’ve had to do to overcome those challenges that come right to mind? Josh Levin 18:04 Yeah, there’s lots of challenges first, Taylor Kenerson 18:07 endless list Josh Levin 18:09 Endless list. Yeah, I mean, with with Honeycomb. With my time at honeycomb. The I think the there’s a variety of challenges. I think one of the core ones that a lot of my CSMs would would echo is that you like working with engineers. They’re like engineers as a whole. And me too. I’m not an engineer, but like I’m a solution based kind of person to just like you describe Taylor, like, my first thought is, how do I fix the thing? Not? Why am I fixing the thing? And that’s something I’m still kind of working through, even after eight years. But but as results are in there, our customers tend to think like that. That’s how they’re built. That’s how they’re supposed to think. And they’re they’re supposed to ask the question of how and not why. And I think a lot of the challenges that we face are getting them to take that step back with us like, hey, we’ll come back with us take a step back and understand it, but understand the system as a whole and why we’re trying to do this thing. And think from more outcomes business perspective, engineers, especially individual contributors, who are like staff engineers, they, again, they’re based primarily in this solutioning base, they don’t think too much about it, because they don’t have to about like, what how does this drive business impact, but ultimately, for us, as a tool developer tool to grow with the team, we can’t just stay in a single engineering team, we have to talk to procurement, we have to talk to the business to the dps of the directors, and we need to have something to sell them to. And so positioning it and working with our ICs to be like okay, what like to be more specific Honeycomb, one of honeycombs core functionalities is SLOs service level objectives. And those are attached to service level agreements. SLAs. And one of the biggest challenges we’re getting adoption of that functionality is it’s easy for an engineer to think how can I measure the health of my system with a single number they’ll have plenty of it. they’re really smart. But if we’re trying to tell them, how do we connect those numbers to business impact, how does this drive revenue for your business, that’s not a switch, they’re used to flipping in their mind. And it’s and so we have to work with them to get to that point. So I say that’s the biggest challenge otherwise, if the typical CS types of types of problems, but I will say, On the note of working with engineers, I’ve worked with, in my CS career, I’ve worked with engineers, I’ve worked with CS folks, I worked at Gainsight for a few years. So like, I know, C, I’ve worked with CS folks, as users, I’ve worked with salespeople as users. They’re all lovely, but engineers are by far the best to work with, they’re just such fun people to work with super friendly and collaborative. It’s, it’s nice being that I enjoy being the dumbest person in the room, because I always leave having learned something new, that’s always great. Taylor Kenerson 20:54 I love my conversations with both engineers, their the way that they think about things is such a unique element. I mean, I’m you know, assuming that most on average, but you you, you really engage in unique conversations when you unpeel in the way that they’re familiar with, you know, because they’re in the trenches with these numbers, the data and different things that you’re not normally in the trenches as a CSM. So can you talk just a brief about how you work with other teams, it’s in Honeycomb, and like how you create that collaborative and cohesive environment to make sure that you know, or to eliminate as much things getting lost in translation and stuff like that. Josh Levin 21:36 Yeah, it’s funny, you mentioned that cuz that that topic is a key one for our OKRs. This, this quarter, we have a whole section of vocab of key results attached to like continuing to build better relationships with teams in Honeycomb. We’re naturally as a CS org, very close to sales. We’re a separate organization, but like we partner with them very, very closely. It also helps that our model our selling, I guess our our sales model, I guess you’d say is a salesperson does not stop working with the accounts after the sale, they partner with CS, CS owns the relationship for the most part, but sales partners with them, they own the they own the renewal process, like the procurement and that sort of thing in that paperwork. So we do truly partner very closely with sales. It’s not just the sales and CS handoff, we truly are partners, and our sales team is really, really top notch really great sales team. And actually marketing as well. We, I think we’re where honeycomb is different in a really good way is we also partner really, really closely with product and engineering. At my previous jobs. It was like pulling teeth, trying to get an engineer’s time, I needed an engineer to talk to a customer. Good Lord, it was it’s like, it’s like we’re trying to sacrifice their firstborn child it was it was pretty painful. by no fault of their own. Personally, it’s just organization organizationally, that’s how it was organized. At honeycomb for a variety of reasons, actually, for two main reasons. One is our execs are very customer success centric, which is phenomenal, including our board. And it helps that our end users are engineers themselves. There’s a lot- because of those two things, There’s a lot of appetites for engineering and for product to get closer to the users. To get close to the users, you have to go through us, through customer success. And so there’s naturally a lot of a lot of points for us to communicate and be that gateway between the end user and product engineering. And they acknowledge that. And similarly, we understand that we’re incumbent on them to deliver what our customers need, and to validate what the customers need. So there’s like a- we have- so at the end of the day, after that little word vomit apologies. We have a really strong relationship with product and engineering, something we’re continuing to foster. But but it’s very, very collaborative at this point. Taylor Kenerson 24:03 What do you think attributes to maybe the you mentioned organization, and the environment is everything to how engineers feel they’re heard how product team feels they’re heard and how that with the CS and how everything within the organization works together. But what do you think? I mean, because you’ve had previous experience at other companies doing you know, different things, but what are some of the attributes that allow the product team and the engineers and sales and see us to all come together and feel like they’re all are a part of this customer? No matter if you know, someone owns the account, whether that’s the answer sales at whatever point in the journey, Josh Levin 24:40 I say there are two things one small, one big. I’ll stop my head, the small one actually started the big one. The big one is when like when you’re collaborating, having ways to measure the success of the collaboration and that like the way that that kind of principle goes, goes across It’s really everything in CS really everything in engineering and software, you can argue that like, if you really want to just show the value of what you’re doing have ways of measuring the success of it. That’s like the basis of like, CS is the basis of scale CS two. And so whenever we doing whenever we engage with product engineering, we typically know where to look to see like, Okay, if we delivered this thing, or we had this engagement with this customer, did it actually drive value did it did it did either in terms of usage or in terms of ARR. And we can, and being willing to call that out, like, hey, we did this thing and look what it did, like, just call him calling that out. That’s, that’s the big one, the small one, which I would argue has just as big of impact, but at a larger a longer timescale is when you collaborate and when there are wins, big and small, calling them out as a team, like, hey, congrats, everyone, we did this and calling it out in a channel to like the company as a whole, we have a lot of people do we have a Slack channel dedicated to like call outs, we call it we just called Love it, just hashtag love. It’s, I’m very happy to say it’s one of our most contributed to channels, like at least two or three times a day, someone has something nice to say, people emoji the hell out of it. And it’s just a lot of reactions. And we we make a habit of calling out everyone who’s involved in something that’s just been done. Like a great example, is of this is actually yesterday, where one of our largest customers was asking had been asking for a while for a product enhancements, that was pretty, somewhat unique to them. But it’s something that made sense, it was something of a really, really bad impact for them. And after some engagement with product and engineering, we got product engineering teams onto a call with them, they presented a slide deck of like, here’s what we think we can build to make it better. The customer was over the moon and ecstatic about being heard, and saying, like, wow, they’re taking my feedback seriously. And we came back to the rest of the company in the love channel and said, Hey, this product manager, this director of product, this engineering manager, they were awesome, they did this, the customer is so happy, here’s a quote from the customer. And like, like those small things in a vacuum shirt, don’t drive a whole lot of impact. But if you’re constantly calling out this partnership, and how fruitful this partnership is, and how happy people makes people, it’s going to like over time, you know, make the love happy, and it’s gonna, it’s gonna make people happy to work with one another. Taylor Kenerson 27:31 I’m gonna push back a little on you, I definitely think it has a really large impact those little even though, you know, obviously, when you’re in the trenches, it doesn’t seem like it, you’re just like, Oh, I’m gonna, you know, comment something nice to someone else. But over time, little by little, obviously, it travels far, that’s maybe the one Slack channel, I would love to be a part of No, no pun intended. But um, that’s, that’s, it’s, there’s actually a study that I will send you. And I’ll actually drop it in the show notes. It’s a study that had to do with how animals, not human beings, how animals are trained. And they do it through consistent praise of what is good, and not knocking what’s bad. Instead of knocking what’s bad and kicking someone didn’t when they’re down. Instead, praise the stuff that you want to see more of. And when you when you do that, you will see the results you want. And it’s an incredible little, you know, thought experiment that you could do, but that’s a living example, the love channel is when you praise the little things that actually do matter, in the nitty gritty aspects of the relationship. And like having your customer heard that, you know, it seems obvious, but to actually, you know, drive change on that conversation you had and bring your teams together and bring the company together around something that a customer emphasize is huge, and allows for them to become true fans. And that’s how you get that, you know, the trickle effect and the network effect that everyone talks about. And I think that’s really important to really highlight, especially as you know, remote teams, you know, we’re also hybrid, or whatever your case in your working environment might be the little things really do matter. The little praising the little wins, having those upfront public channels where everyone from the team, the whole organization, regardless of your niche within the organization can see what’s being done and what’s being what’s good. And then you also have your maybe you have your low performers that see that and like oh, well maybe that’s the way and that’s how I should carry myself and pave a better path. I think that’s really important. Josh, I want to thank you so so much. This was a beautiful conversation, and I really am so excited to drop these nuggets for our audience. And yeah, I can’t thank you enough. I really appreciate you. Josh Levin 29:48 Absolutely. Thanks for the time. Taylor Kenerson 29:49 Thanks, Josh. We’ll be in touch okay. Adil Saleh 29:53 Thank you so very much for staying with us on the episode. Please share your feedback at adil@hyperengage.io. We definitely didn’t need it. We will see you next time and another guest on the stage with some concrete tips on how to operate better as a Customer Success leader and how you can empower engagements with some building some meaningful relationships. We qualify people for the episode just to make sure we bring the value to the listeners. do reach us out if you want to refer any CS leader. Until next time, goodbye and have a good rest of your day.