Building Customer Success for Scale with GitLab and Sanity.io Heavybit
In this special fireside chat, GitLab’s Head of Global Technical Account Managers, Sherrod Patching, and Sanity.io Co-founder and CEO, Magnus Hillestad, explore the work of founding and scaling an enterprise focused customer success organization. Sherrod and Magnus cover a wide spectrum of topics relevant to early stage founders who are asking themselves whether and how they should institute customer success in their companies, and later stage founders who are looking to scale their CS teams.
Magnus: I’m Magnus, CEO and Co-founder of Sanity. I’m Norwegian, based in the East Bay. I’m actually a finance guy by training so I’m a bit new to the startup world because I used to work in private equity, but I love this community. I’m loving learning about all the ways you build businesses and develop businesses and very happy to be here, to speak to Sherrod today about customer success.
Sherrod: I’m Sherrod Patching, I lead the Technical Account Management team at GitLab. Technical Account Management team, or TAMs, is essentially synonymous with a technical CSM. So you may hear those a little bit interchangeably today. Our team is globally dispersed and you probably are familiar with the GitLab model, but we’re a DevOps platform.
I’m from Canada originally. I moved to England when I was 19, spent about 16 years there and then moved to the West Coast about nine years ago. So I’ve been all over. I’m not quite sure where I’ve considered home anymore, but love them all dearly.
Magnus: That’s fantastic. Thank you for being here and looking forward to this discussion that we’re going to have. And maybe before we jump into a little preamble here about what customer success really is, I’m curious, how did you end up in customer success?
Sherrod: I actually trained in music initially, so I worked as a musician and was doing jobs on the side and leading teams on the side, but was working in music full-time in England, until I got to about 30 and then realized that I probably wasn’t on a track to get famous. I thought I should probably pivot into something that was going to pay the bills a bit more steadily.
Sherrod: I had the leadership background, and so I started leading a digital agency and got excited about being exposed to some technology that we had internally and the opportunity of scale that technology brings. Then I moved to an AI-focused company in London and led at the time what was a client services team before customer success was really coined.
Then from there just kind of fell into it, moved to the U.S. and to the Bay Area, where we have a much further along understanding of what customer success means. And I’ve built a career from there.
What is Customer Success?
Magnus: That’s really cool. So we’re similar to that regard. I think I was 35 or even later when I realized that there was this world of technology that is super cool and exciting to be in. Maybe we could start there by talking about what is customer success and the many definitions, but how do you think about what customer success is?
Customer success is ensuring that we’re aligned with the customer and their business objectives.
So not just that reactive, “if you have a question I’m going to answer it,” but actually aligning with what a customer is looking to solve for and ensuring they get to those solutions with the ultimate goal of ensuring that we keep our customers and that they grow.
So from a business standpoint, we ensure that we have happy customers that stay customers and grow. And from the customer standpoint we’re someone that partners with them to ensure that they are getting the solution to the business pain that they had, that drew them to us in the first place.
The Evolution of Customer Success
Magnus: You said earlier that it was called client services before. Customer Success can have many names. How has this field developed over time? I’m sure it’s still developing. What does it come from and what are some of the underlying ideas that have been driving the development of this field from your perspective?
Sherrod: I think one of the primary things that I’ve seen and I’ve actually been on this journey with a few companies now is, a lot of customer success, particularly out of a number of years ago, was around feature function. So how do we ensure that we are proactively showing you how to use maybe the features from the new releases or whatever it may be?
But what I was just referring to earlier about was the shift to business. So the platform is a vehicle for you to try to solve your business pains. Your goal is not to understand every feature and function, your goal is to solve your business pain. And so customer success really shifted a number of years ago, but we’re still seeing this.
It certainly happened a number of years ago in more mature markets, but there are a lot of companies that are just now figuring this out for themselves around, “how do we take the CSM or the technical team away from just pointing to the features and actually talking about business objectives and how to product is a vehicle for solving that?”
So we’re trying to solve for improving cycle time or reducing security risk. We’re not trying to solve for them knowing where all the buttons are necessarily.
The Team and Responsibilities
Magnus: If you take an organization like GitLab, a fairly large organization, what does the customer success team look like when you’re at that kind of size? And what are the typical core responsibilities or outcomes that are owned by that team?
Sherrod: Every company is different. We assign a technical account manager when a customer pays above a certain ARR threshold. So that’s how we go about it. Other companies, particularly in a smaller state, you may assign them to all of your customers, but you segment your customers.
So maybe you might have one technical CSM or CSM assigned to 50 customers in the SMB space or 101 assigned to one in the enterprise. So you can think about different ways to go about determining who is going to get a TAM or a technical CSM and how much of their attention. But that’s how we think about it.
Typically what you see in the industry is ARR per head. So the industry standard is 2 million. However, if you’re a small company without a lot of processes, without a lot of frameworks, it could be a lot less than that, just because, if you’re not at a point where you’re able to support what the teams are doing through systems, then it could potentially take more time.
There is a lot you can do around determining the capacity of your team, but quite frankly, I think the first step is an active conversation with your team in the early stages to determine what their capacity is and to try and build a model around that.
Magnus: How many in total would that be in your organization at GitLab now?
Sherrod: Just shy of 50.
Magnus: I assume it’s a bit like sales in that you start with everyone being the same and then it specializes a bit over time, as you develop. What are some of the distinct groups inside the customer success organization that you lead now? Are there two or three or four different roles? And what is the vision of where you’d like to go with your customer success organization?
Sherrod: Some companies will choose, particularly if there are very nuanced industries. With GitLab, the way that you use the platform can be quite similar regardless of the industry that you’re in. So we haven’t gone deep into industry expertise. We really focus more on SREs, we may have team members who are more familiar with our security features or more familiar with our CI features.
But the way that we actually segment our TAMs is to do with size of customer. So we have an SMB team, a mid-market team, and an enterprise team. And for us, SMB is companies up to 100, mid-market is 100 to 1,000, and then enterprise is 2,000 and above. So we have TAMs associated with both. They all carry the same book of business, which for us is 3.6 million.
And then in SMB that could look like 100 customers, in an enterprise it could look like four potentially. So, as you can imagine, the depth you’re able to go with that customer differs depending on your size of book of business, and also the expectations of that customer.
Magnus: We’re going to talk about the roles and the responsibilities and the outcomes in a second, but do you also have certain people that are more technical-responsible and certain people that are more business-responsible? Or is it all the same, but split by the size of the customers and they all have their different accounts?
Sherrod: It’s the latter for us but you’ll see different models. So sometimes you’ll see a TAM and a CSM model where you have a CSM who’s going to own the business conversation and a TAM who may be overlays on a set of accounts.
We actually have a TAM that is more like a technical CSM. So it is someone who truly owns that customer life cycle. They own all of the onboarding, the enablement, the expansion into the account, but they also are that trusted advisor for technical things.
So we draw the line with hands-on-keyboard. We’re not a Professional Services team. But we need to have the technical chops to be able to meet our developer audiences where they are. So we ask both, which makes it a harder profile to hire for, but in my opinion, a more orchestrated experience with a customer.
Magnus: Are these philosophical choices, like some people like and think it’s better this way or that way, or is it more driven by the kind of go-to-market motion you have or the kind of company you are or the technical level of your product? Are there some golden rules for whether you go here or there or would you say it’s just a preference?
Sherrod: I have seen it be a preference so far. If there is a model I’ve not seen one. I do know that there are a number of customers or companies rather that have reached out to me personally to talk about consolidating the CSM and TAM role into one, because the challenge becomes overlapping costs. Is there truly enough of a differentiation or are they actually just sitting on the same calls together? I would recommend you start with one before you start exploring two, because attribution is complex and it’s expensive to have two people servicing an account.
Magnus: It’s one thing that at least I felt we bumped into pretty early-on. Sanity is a content platform so it’s very technical. We figured out a lot of our customers needed that technical follow-up, but we also saw that there was a lot of general customer success managers who are less technical and more about following up on the business side and we scratched our heads over, should we have both? Or should we just send more technical people in because at the end of the day, that’s really what drives the success of our customers?
Sherrod: If you were trying to debate the question, “do I get a less technical person and try to teach them to be technical so they can meet the customer where they’re at? Or do I get a technical person and try and teach them more about having those business conversations,” we went with the latter.
TAMs vs Technical CSMs
Magnus: So what’s been the typical profile? It seems like, and I think this is worthwhile for those listening in, you would say a TAM and a technical CSM is interchangeable or at least that’s what you told me the other day. It’s the same face.
Magnus: And that was news to me. What’s the profile then? Could you explain a typical TAM or technical CSM profile at the GitLab?
Sherrod: We have some interesting backgrounds actually. One of our strongest TAMs comes out of actually the recruitment team. She wasn’t from a technical background, but she had a hunger to learn and loved and was using the product in her role. I think a lot of it is like a natural curiosity and aptitude towards more technical conversations. But we also have people who’ve come out of embedded engineer backgrounds, PS background, support backgrounds.
Typically the profile that we see more often than not is people who come from engineering backgrounds who have that as a slant.
Magnus: So it’s about the ability to communicate and listen to people than it is to really understand the technology. Because then we’d be talking about solution engineers or pre- and post-sales, which I’m assuming you have at GitLab.
Sherrod: We do. They’ll come in and do the more hands-on deep-dive demos, that kind of thing. If we’re going to get into it into a demo environment and start actually working through some of our features, then we would partner with the SA on that. But to your point, a lot of this is just about ensuring that we’re listening to the customer, that we’re able to understand these things. Our documentation covers a lot of things, but it doesn’t cover a lot of our third party integrations, for example.
So the TAM becomes that wealth of knowledge of being able to guide a customer where to go to find the information that they need.
Magnus: Exactly. What are the typical 2-3 tasks that these people do and what’s 1-2 ways that we typically measure them?
Sherrod: I’m going to oversimplify it. But I think any TAM who owns a customer life cycle or any technical CSM, does three things primarily. So they onboard a customer, they ensure a customer is enabled in their existing use cases. i.e the things I wanted to do with your platform, and then they expand them into additional ones. So that is a gross oversimplification, but you could really boil down everything we do into those three topics.
When it comes to onboarding, do they have what they need to be able to be set up correctly and securely and all the things you’d expect to see? Do they understand what maturity looks like within the use cases they’re planning on doing, that might for us be SCM/CI and then where do we go from here? How do I help you drive an additional return of investment through using more of the platform because it’s a win-win?
So those are the three areas that we would want any technical CSM or TAM to own. And the metrics follow the same. So what’s time-to-first-value? Ensuring that executive business reviews are actually being held, that we’re having those conversations. That’s probably for a more mature motion but understanding product utilization. If you know that a successful customer uses these three things, are they using those three things? And if not, how do we get them from two to three?
Then we think about expansion, and the metrics around how often are we expanding into our customer base? Where are we not seeing expansion? Then how do we overcome some of those objections?
Magnus: Expansion, as we spoke about, that’s a little bit of a disputed area. Some people would say your org belongs with sales. What’s the thought behind both of these sides?
Sherrod: There’s expansion into additional use cases and there’s expansion from upsell. We have tiers at GitLab when you think about it. We actually partner with sales, so oftentimes the opportunity to drive into additional tiers comes through success in their existing use cases. And that is very much a TAM-led motion, but I think when it comes to who owns the dollar, that can be a pretty hot topic to your point.
I think it comes to, for us, we actually are both incentivized on that. We have a joint number, it does roll up into the sales number, but part of our team’s compensation is based on growth. So we’re hyper-focused on ensuring that our customers are growing. When it comes to who owns the dollar, it ultimately comes down to who gets to make the decision, who owns that motion.
I think there is a camp that would say that essentially, if it’s a fairly transactional renewal or upsell, it makes more sense to keep it with the CSM simply because you’re not also paying commission on that. So if you just think about it from a dollars perspective, it is cheaper to have your CSMs run those.
If you think about it from a negotiation standpoint– you brought in someone who was very good at being able to do objection overcoming and all of the kind of commercial conversations– if you want that, then it may be worth paying the X percent to ensure that you’re getting the upsells and your deals in addition to your CSM.
That’s kind of the decision matrix and thinking. It comes in part down to costs and what’s going to be more effective, not necessarily efficient.
Magnus: For me, at the stage where we are, as a founder it’s not so much about paying the commission. Of course the total economics of the business is important, but it’s really about making sure we win it and that we don’t lose those customers. The incentives people have for just keeping customers happy could speak towards having it in your department, instead of having it in the sales department.
Salespeople could be less interested if it’s less of an upsell opportunity, at least with us, because we don’t pay commission on renewal. I’ll pay a commission on an expansion to our sales team. We don’t have a broad CSM function. We have solution engineers but not a broad CSM function in the classical sense yet.
How can you judge whether you’re in a situation where salespeople aren’t incentivized? Because incentivization sounds like a big driver to me.
Compensation and Incentivization
Sherrod: I’ve seen a few different models and been a part of a few different ones as well. I think if you’re not going to pay any kind of renewal or any kind of commission rather on a flat renewal, then you do run into that challenge. Maybe there’s a lot of fighting that needs to happen to even save that customer.
If you’re asking an AE to do all of that kind of struggle to keep the customer, and then you’re not going to pay them commission, it can be quite challenging to keep them going in that direction. As you can imagine, the easiest thing to do as an AE if you’re not getting any commission on a flat renewal is to not spend your time on there and spend your time on pipeline that’s going to potentially close.
To the other situation, where there’s no growth, you end up having customers who have basically sold to all of their developers. So it’s not even that the customer is challenged, but there is no growth there. And you want the AE to lead these AE motions, but the AE is not particularly interested because they’re not going to make any money off of this customer.
What I’ve seen a lot of companies do is start to have a renewals person. So they sometimes live in CS, they sometimes live in sales, but they’re purely focused on the renewal. And so they might get 2-3%, every model is different, but that is there and their primary focus is gross retention. So ensuring that every dollar that you have of the dollar that you own today is renewed.
Magnus: Let’s go back to metrics. Because at the end of the day this is a very, as you say, transactional focus. It’s about making customers happy so that they stick with you so that they upsell. It’s about revenue. You mentioned earlier the three ways that you measure. Do those change depending on what kind of business motion you have?
The CSM sounds to me to be very correlated with the enterprise sales motion, but how should PLG companies think about this? Is it any different, should they think differently about it when they mature?
Sherrod: We are also a PLG company, it’s before my time when we opened the enterprise motion. So to your point, yes, you oftentimes do see the CSMs come in, as you’re starting to engage with a different caliber of customer who expects a different experience. We grew very organically and continue to do so, but as we think about engaging with our larger, most strategic customers, it doesn’t work just to have in-app support anymore.
We work very closely with our growth team, because we’re constantly looking to have a better experience for all of our users through the platform and through docs of course. So we want to ensure that it never just moves to a hands-on all-TAM motion. You want to enable a customer to self-serve to the best of their ability. And that’s really how we closely partner with growth.
The more you can do around chat or in-app experience or better UX or all of those things used to solve them all. They are cheaper and they’re a better experience because they hit on every user. But that CS layer is oftentimes brought it on maybe higher investments where a customer feels like, regardless of size, “I’m paying you enough money that I expect things I shouldn’t have to find things myself.” And I think that’s really where that kind of inflection point of bringing in CS begins.
Magnus: So is there such a thing as like a programmatic CMS function person, who cares about growth and engagement? I can see it’s very similar, but at the end of the day, they could be measured on somewhat different things. Would you have separate people who think about theCSM strategy for self-serve people or would you be measured somehow as the TAM organization on those kinds of things?
Sherrod: We do yes. And I could talk about it all day. So essentially there’s a notion of a digital TAM, or they call it a tech-touch. Tech-touch CSM, digital CSM, you’ll hear this. So essentially what that means is we look to see trends where customers are moving away from adoption, and we try and solve that through content. So we actually do have a digital program at GitLab.
One of the things we do is, from the moment a customer becomes a customer, they start receiving emails that then point them to the various different areas of docs to guide them through the gotchas around setup or ensuring that they have all of their security elements in place, so on and so forth.
We do the same thing around CI. So we guide them through our CI utilization. And then we can do things based on triggers when we see license utilization drop. There’s a number of different things you can do, both through where the customer is in their life cycle and also where they are with feature consumption, to start using that to trigger content.
That is by far the most scalable method when you think about reaching all of those customers who potentially won’t ever pay enough than they necessarily could warrant a TAM or a CSM.
Magnus: I never thought of this and this wasn’t on our list of pre-planned questions,but it’s super interesting because the whole PLG motion drives a lot of new, I guess, disciplines of ways of working. And they often bump into each other, so this bumps quite into growth, but it still sits in the CSM organization. I am correct in understanding that?
Sherrod: It does, yeah. We work closely with growth on it and you’re right. And we partner a lot on these initiatives. I would say between growth and customer marketing, we talk a lot.
Magnus: And what kind of people would do that kind of job?
Sherrod: Growth or?
Magnus: I mean, the programmatic, or what did you call it? The digital CSM?
Sherrod: Digital CSM. Yeah. So we’ve had people out of a program’s background, actually the person who leads our programs was leading growth for another company previously.
Magnus: That makes sense. So typically number savvy, tech savvy people, but also some writing skills, I assume in terms of the communication, but quite a different skill set than your normal TAM then?
Sherrod: Very, yeah. So we call them a programs team, the motion is called tech-touch or digital-touch. We don’t even call them CSMs. We call them the RCS programs team.
Magnus: Okay. But it sits in the same organization.
Magnus: So it’s kind of customer success. It makes a lot of sense though. I could think about sales, you’ve got the inbound and you’ve got the enterprise team. That was enlightening.
Let’s move over to talk about earlier stage companies. When we spoke, you said you haven’t been a founder, so you can’t speak to what people like me should do, but I think there’s a lot of learning for us. You explained how the vision should look like. One of the things I can explain from my background was when we had gotten the first larger deals at Sanity, we understood that these customers needed to be maintained.
And we did it probably not in the right way. A lot of it was founders and salespeople trying to stay in touch. Some customers got a lot of our attention, some got less. We didn’t get a lot of churn, we got lucky with that. But we realized before it went too far that we needed to do something proactive about it, and we’d heard about customer success for a long time and we needed to make some choices.
One of the big challenges I found was where do you start? What’s the kind of personalities that you think are good in a small CSM team? How should it look or where should you find those kinds of people? Who are they?
Sherrod: I think I gave you a tongue in cheek answer when you asked me this before, but I would look at the resources from your competitors or in the landscape. But I mean, ideally if you’re looking for the first one, you want someone who’s done this before, I’ve seen a lot of companies hire player coaches.
So someone who’s maybe has minimal management experience and is looking to build a bigger team over time, or is looking to get into management and has chops from leadership and other areas. But you want someone who’s done it before and knows what they’re trying to build.
Magnus: And we actually went the other way around, we hired one of our customers.
Sherrod: Oh, well that too.
Magnus: We knew this person from before and he was very technical and really understood the product while at the same time understood customers and business, seemed like a good match for us. But I can see the pros and cons.
The first thing maybe I should have asked, the timing. When should you really think about hiring? How do you know when’s the right time to hire someone who’s solely focused on this question?
Sherrod: My recommendation would be as soon as you’re able to. So you talked about, “we’ve got a customer model and it’s a lot of reaching out.” I mean,
the goal with customer success is building repeatable motions that customers can follow.
So rather than waiting until a customer has a question in onboarding, ideally customers should be doing A, B, C, and D. And we understand that every customer is a snowflake. However, there are going to be consistent things that customers should be doing on our platform that is going to lead them towards success.
So just get them doing that. You’ve got one person who’s just focused on it. And maybe then there are a couple of additional use cases where customers, again, just need to do A, B, C and D. I understand that everyone is going to be slightly different how they approach it, but that just fundamental guidance of taking it and proactively guiding a customer through, that’s what we do. If you can get someone early on to begin to guide your customers through that.
So they’re less likely to set it up incorrectly and have scale problems because the foundation was poor or less likely to end up using it because it’s confusing and your documentation is lacking or all of the things that it could be. If you can get someone in there proactively guiding your customers from early on and building out. My short answer would be as soon as you can afford it.
Magnus: I assume if you start to see churn, you’re too late?
Sherrod: Exactly. You could wait until then, but it’d be a painful lesson.
Magnus: If we assume that a leading indicator is the learning they need or materials they need or help they need to get onboarded, and that’s what you should look after, then how do you define what lies under the customer success area? Because, at least for a PLG centric company, you already have a set of docs, maybe that lies with engineering, maybe DevRel. So you’re already doing some things or thinking about how people get onboarded.
How could you have a mental model for what kind of content and learning should sit within the CSM team and what should sit in other parts of the organization?
Sherrod: We don’t try and move people away from docs, we try to have a single source of truth and docs is it. So what we try and do is provide a curated experience through docs. So just because everything is in a doc, doesn’t mean that the customer is going to be clear on what A is versus B. And also too, I think that they’re going to actually thoroughly do all of these steps.
So my recommendation would be you choose a single source of truth and you stay there and in docs. So we try and kind of build curation over that. We have email campaigns that say, “Hey, customer, welcome. First you’re going to do this,” but it points to docs. “And next you want to do that,” but we’re constantly driving them back towards docs. It’s that more curated experience through.
Magnus: Who owns the documentation? The question that we explicitly got here was, “what are your thoughts on putting the documentation team under CS or under product?” And maybe we could add to that based on what you just said. What is if CMS doesn’t own docs, what is the relationship with docs?
Sherrod: We have a close relationship. We actually hired, with the blessing of Susan Tacker who leads our docs team, a technical writer who’s a part of our CS programs. So she collaborates with the docs team. She writes our emails, she writes our content, but she also too collaborates on the docs as well.
So we took a bunch of the quick start guides that we’d written and moved them across to docs and she worked with the docs teams on that piece too. So I don’t have a view on taking docs, for us doc rolls up into engineering.
I don’t feel strongly about that changing but you’d have to work closely with them, for sure. In our team one of the muscles that we’re still trying to build is that as you’re working with the customer, you’re going to find things that are missing in docs, or maybe it doesn’t work quite the same way that it did, or it needs to be augmented.
We’re really working with our team to continue to open MRs and to actually iterate on the docs ourselves. That’s very much the GitLab way of everyone contributes. So we don’t treat it as the “precious docs over there,” but “we all own this.”We own the customer experience. So if you see something wrong, fix it.
Magnus: Have you ever heard about docs being owned by a CSM team?
Sherrod: No, I haven’t. I mean, we have a technical writer, but that’s as far as we go, I’m sure it exists. I’ve not come across it though.
Magnus: Yeah, that makes sense. Is there any collateral or any library of any other sort for maybe larger customers? Or anything that sits in addition to the docs? Or is everything back to the docs? GitLab obviously has its handbook.
Sherrod: Yes. Thank you. There is, we actually are still building this out. Some companies who’ve got this much more robustly, but we’re still a late stage startup so this is the part that we’re still building, but we have a third-party education suite that allows curated journeys. So we’re starting to build out all of our onboarding onto those.
Essentially the emails drive customers to this EdCast, which is the platform that we’re using. We can track attribution to how long, where people come from, how long they stay on a page, all the things you’d want to see in analytics. But the actual content, maybe there’s some framing content that gives context to what we’re showing, but the technical content actually links back out to docs too. So we’re building that as an experience on top of docs.
Magnus: This is interesting. So I understand everything drives us back to the docs. Enterprise plan customers, the bigger that they are, the more attention they require. They pay you a lot more so they should get value for that and they need more onboarding.
And we were asking ourselves whether we should create separate onboarding tracks? Because in effect, the solution engineers in the CSM team would be doing that a little bit by hand so why not try to automate that.
How should you think about having that exclusive for the larger customers? It goes a bit against the PLG philosophy of really getting everybody up to speed. Are there situations where we should create exclusive content for enterprise as part of the broader product offering? Or is that just a bad thought to follow?
Sherrod: I have not come across that. For an enterprise customer, you need to work with the services team because the complexity of the builds can be much more broad. So I’ve definitely seen there be different experiences that are available to different customer bases. So maybe only content to SMB, whereas a mid-market might get content plus some kind of best practice. And then the enterprise with a big investment looks more like a PS engagement. I’ve not seen content only be available to enterprise, but it probably exists.
The Tech Stack
Magnus: Yeah. I can see arguments for and against it. I’m curious about two questions. How does the CSM tech-stack for the work you do look like when you’re more mature, but also where should you start? What’s the first thing you should think about when you start building this function out as an early stage company?
Sherrod: There are CS platforms out there. The one that we use is Gainsight. I’ve used that through a few companies now. It’s an app essentially inside of Salesforce. We use Zendesk, of course, a lot too. We don’t actually answer tickets, but we track very closely to understand our customer tickets. So Salesforce, Zendesk, Gainsight is where we live.
But for young companies , there’s nothing wrong with spreadsheets. I think I’ve gone into startups that are very, very early stage and spent two weeks trying to find out who are our customers and when do they renew? And it has to live in a spreadsheet and so be it. I think that’s a fine place to start.
Magnus: People who know me know I love that answer. “Figure out what you’re going to automate before you start automating it, because there’s so many nice tools.” But yeah, not too long after, you’re going to need those tools. I’ve heard about Gainsight as well. Are there other tools or is the world of CSM inside Gainsight or Zendesk mainly?
Sherrod: For us personally, we teach our customers to dogfood or drink their own champagne through GitLab. We open up a project for each customer and we contribute and collaborate with the customer through issues in those projects. So our team spends significant amount of their time in GitLab as you would imagine.
Magnus: We do the same with Sanity. We have a couple more questions here. Someone asked, what does it take to actually become a good CSM?
Sherrod: I have always said that it takes the ability to have the macro conversation and the micro. I think you need to have someone with natural curiosity who really does want to get in and truly understand the tech. I think there is a flavor of CSM who’s more like the business conversations, that’s not interested in the tech itself but it just doesn’t work in my experience.
So I think you need someone who loves the detail, but also can have the macro conversation. The last thing you want to do is put your only CSM in front of one of your buyers and just have them talk about low level features, or maybe some of the technical challenges that they’re overcoming.
That’s actually really hard to find. So someone who can talk to you about your business or at least about what you’re trying to solve with this platform. But I also too need someone who can get down into the weeds and better understand some of the challenges and how we overcome them.
I think you can weed those people out by asking them to give scenarios. “Tell me about a time when you overcame a customer problem and how did you communicate that to the buyer?” You can weed out their ability in interview processes by just having them tell stories. The more you can get them to talk about their experience, in hiring someone who’s done this before, the easier it will become to find that, but it is the macro and the micro, a natural curiosity and attention to detail.
Customer Health Scores
Magnus: At GitLab, you have to be technical, but there are other companies where it’s more about the more business-y elements, because it is a different kind of product. With GitLab need to be more technical and you really need to understand how it’s applied for the customers, because at the end of the day, that’s the value you need to drive for them.
Do you use health scores for your customers and how are they set up?
Sherrod: We do. Yes. Some of the things I talked about earlier, onboarding, enable and expand. We have scorecards around all of those. So we have a scorecard and then I’ll talk about a couple more. So for scorecards, we expect a TAM or a CSM to speak to a customer within 14 days of having sold because the customer is excited. If you miss that opportunity, you take a month or two months to get through them, they’re probably annoyed by now. If they’re even willing to talk to you, that’s one.
Two is time to value. So what is that first inflection point? For us it’s about 10% license utilization. So they’ve gone beyond just the admins and now they’re starting to onboard team leads and developers. We track that very closely.
That’s also a scorecard and then total onboarding. If onboarding goes too long and you’re starting to get into halfway through the contract or worse, now you’re talking about potentially having to extend your contract with them, or even having potential churn as a result of not seeing return on investment. So getting them out of onboarding quickly, but ensuring that they are set up for success. That’s key. So we have scorecards around those.
We have scorecards around executive business reviews. You’ll hear that in the space instead of kind of QBR as a quarterly business review, we do ours once a year, so the term is executive business review. We track that those happen. We track that we have a success plan in place, that we do have a plan with the customer that goes beyond just the features they want to use. So it’s about quantitative business metrics, cycle time, deployment frequency, those kinds of things. So we track that that is actually in place that we’ve set that up with the customer.
We also track how long since we last spoke to the customer. So with an enterprise customer who is a named account and we have a strategic opportunity with, we should be talking to them no less than once a month. For our customers who are strategic, but maybe need us less than every 60 days, we have scorecards that change color when a call hasn’t been logged in that time period. So we can understand, is it just a hygiene issue and we need to speak to one of the CSMs, or actually as the customer not talking to us?
Because typically if a customer stops talking to you, they either have not found value in what you’ve had to bring to the table. So you need to iterate on what you’re talking about. Or they’re talking to a competitor and there’s potential risks there where there’s something has gone wrong. And so being able to see across your customer base, who’s not talking to you is incredibly helpful, particularly in the higher paying customers.
Magnus: And all of this is measured inside Gainsight? So that’s your dashboard. And it’s a lot of metrics around how you interact with the customers and then the discussions and the frequency of those discussions.
There’s another question here, what is the data you analyze in order to identify risk of churn ahead of time?
Sherrod: So license utilization is a no brainer. If you get to the renewal and they’ve only utilized 75% of their licenses, quite likely, you’re going to see a 25% haircut. Or they’re going to ask for money back or to extension or all the things that you may expect to see. So license utilization is huge.
But then also too, we look at use case. So for us, we have a series of use cases across GitLab. We’ve been able to see over time that if a customer has only adopted one of our use cases, they are much more likely to contract or churn than if they’ve adopted two or three, and three is that sweet spot for us. So we’re always trying to ensure that we’re working with customers to get beyond just SCM (Source Code Management), for example. So that’s a key piece for us.
Even if a customer’s completely happy, we consider it not completely green if it’s only doing just SCM with us, because we understand that there’s still risks.
Magnus: In our product platform we would probably not be able to do that because of different use cases would look the same by API calls, et cetera. So we would probably have to do that manually then. But we could do the same thing of trying to understand how much value they’re getting out by the diversity of use they have, that’s something we should definitely look at.
Magnus: Are there a couple of others that are key that you measure also? Or in your analytic?
Sherrod: So all those key engagement piece things that we look at like, are we talking to them, did they onboard in a timely matter? Did they get to value? And that then coupled with all the product usage data, I think those are the two key ones. Are we having the right conversations with them? Those kinds of things.
We have one scorecard called TAM sentiment. You’ll see this a lot across a lot of companies, because sometimes you look at all the datam they’re using all of the features. We’re having all the right conversations. They’re talking to us all the time, but they’re just not being very successful in what they’re trying to do. Maybe for lack of knowledge or lack of guidance or whatever the case may be.
They’re not getting any value from it. And having a technical CSM or a TAM talk to your customer, sometimes they’ll just go to find out things from a conversation that you can’t see in data. And so we had that scorecard that has the heaviest weighted. It actually is 50-51% weighted. So as soon as a TAM marked anything red, the whole thing goes red. It doesn’t matter what they’re doing with product usage data, or if they had a good onboarding experience.
Magnus: So it’s a rating the CSM does in Gainsight to impact the scorecard of that customer?
Sherrod: Basically. Yeah, it has the heaviest weighting. So as soon as the TAM says anything is red, then the whole thing turns red essentially.
Handing off to the CSM
Magnus: We have a question about handovers and whether the CSM gets introduced prior to signing the contract? If not, how is the handover managed? And I guess the question is, how do you secure the best handovers between sales solution engineering and customer success?
Sherrod: First of all, everything I’m saying is in our handbook. So if you haven’t ever seen our handbook, you should go and look, classic it’s awesome.I do want to preface this with that because all of this is in there but we’ve just been through a process of further defining our SA to TAM handover.
We used to do AE to TAM handover, but you’ve got a non-technical resource handing over to a technical resource. And so my worst nightmare in CS is that game of telephone, where you call up someone to talk about your problem, they transfer you departments. They ask you all the same questions again, it’s just the worst. And so we want to ensure that everything that was given to us in the pre-sales process is carried across and that the post-sales is just a continuation of that same conversation.
We understand what you’re trying to solve for. We understand what you’re looking to do. We’ve been through those, I don’t need to ask you discovery questions again. I think if you search for SA- TAM handover in the GitLab handbook, you’ll see there our latest iteration, but we’ve just rolled out a more robust product, or process rather, to ensure that the customer feels fully supported and that they trust their TAM. Because what we’ve been finding is if you don’t hand off well, the customer just wants to keep talking to the SA. Because you built trust in the pre-sales process and they don’t trust this new person who doesn’t have the context.
Magnus: SA is solutions architect, I assume.
Sherrod: Yes. They typically lead on pre-sales. To answer the question, we do introduce the TAM pre-sale. Oftentimes we’ll do some kind of like POV or technical evaluation once we know them. When the customers most likely moving forward into a sale, we’ll then introduce the TAM. So that post-sales experience is just seamless. We do that for enterprise, but for commercial we don’t. It’s a much higher volume of customers, so we wait until the sale is closed. But then we very quickly introduce them to TAM.
Magnus: That makes sense. I also hate answering those same questions, it happens at so many places.
Sherrod: It’s a bad experience. .
Magnus: It’s so bad. Is there a system for keeping track of conversations between people? Is everything logged by the AEs or the SAs or Solutions Engineers inside Salesforce? Is this a systems question or is it a process question?
Sherrod: It’s both. We all collaborate on Google Docs together, we ensure that all the notes are in the same place. But some of these technical conversations, I haven’t seen something where they could be translated into something that can just automatically be handed over without context. Not yet anyway.
So we use Google Docs so that everybody’s contributing to the same set of notes. We have contexts up top, but then we also use GitLab too. So we’ll also open up that project for the customer when they’re a prospect. And so we do as much as we can to keep things in central locations that everyone’s contributing to. But there is a level of handoff that needs to happen between people.
Magnus: When it’s handed over, the sales people who I assume have already gotten their commission, are they done? You mentioned at GitLab, the retention and upsell is a customer success matter.
Sherrod: Sales stays on it for the longevity of the customer. We don’t yet have a renewals team. We’re just starting to explore that in commercial, and the reason being is because we’re all land and expand. So usually when a customer comes to the door, it’s just the beginning of our partnership. They don’t come in all bells and whistles, they haven’t completely explored GitLab for all of their developer teams. So for that reason that we keep sales on the account, the SA comes off of the account.
There are primarily two situations when an SA would go back into an account. And one is when there is an opportunity for a tier upsell. So selling new features that are not available to them. So the demo and getting more into the technical weeds of what that could potentially could look like.
And then the other is around our security features,.Tier upsell is the primary one, but the other one is around where there needs to be a hands-on demo or a proof of value to move into something. So typically the sales will come in to lead those motions.
Magnus: Are the AEs comped in the same way? I assume percentage for sale and expansion. If not, do you think it slows down sales velocity because reps are trying to get larger initial deals?
Sherrod: I actually don’t know. It’s not my wheelhouse enough to know. We have just rolled out a new hunting team, essentially. So a new logo team who are just purely focused on new logos because that’s been a big one for us. So I know we’re bifurcating compensation strategies based on that, but I actually don’t know what our comp looks like for the sales team.
Magnus: We do it completely the same. The percentage comp is the same for initial sale and the expansion. And there is no compensation for a resell. And this is exactly the reason, I think you don’t want the sales cycle prolonged by someone trying to sell for a larger deal than they have to or the customer really wants just to get a higher compensation in the beginning. So that’s how we did it.
Sherrod: So one thing I would counter on that is that we have historically sold smaller deals and grown them into much larger deals. What we have found though, is that when you sell a small deal that you 1) you’ve pigeonholed a set of budget that maybe isn’t available for another year. So we sold it for 20 instead of 50, and now there’s not 50 till next year.
But 2) we led with a smaller, like maybe SCM only, and then let’s try to get into CI. Then let’s try to get the CD. Then let’s try to get into security. We didn’t talk to security teams up front. So once you bring in the security teams it’s a longer sales cycle. But what we were finding was that people just pigeonholed us in their own minds as GitLab the SCM solution. So we’ve sold 20 with the intention of getting to 100, but we get stuck at 30 because we can’t get into these other teams because it wasn’t perceived as such up front.
And the buyers that we were talking to, they see us as this SCM solution because we didn’t position ourselves as a DevSecOps solution. And that we’ve had to undo and get ourselves out of. So we are learning that the longer sale and a bigger sale with the bells and whistles from the beginning has been a much more successful motion for us.
Magnus: I love it because we’d been feeling that pain also that if you go in too low and you try to limit yourself, then you’re viewed as a limited thing as well. Did that sales process impact you in as the customer success org in any way? Do you have strategies for immediately clearing that up?
If the customer only comes for part of what GitLab has to offer, do you immediately start giving them success on something broader, to expand their view?
Sherrod: Not immediately, because I think someone described it to me as,
if you hire someone to come paint your house, they paint half your house and they start asking for references, you kind of want them to finish the house first.
That one stuck with me. So I think once someone has bought you for something, you want to make sure that you kind of get them set up and maybe there’s an opportunity, but most likely they’re not going to introduce you to other teams internally until they’ve seen some level of success. But it does change the CS motion.
When you sell an end-to-end platform upfront, then our motion becomes a lot less about focusing on getting into expansion and a lot more about ensuring that a customer is utilizing all the features they bought. So how do we make sure that they don’t buy all of it?
They come to us with this DevSecOps, but then they only actually ever use end up using SEM. So it’s more of a defend motion for us. Like let’s ensure you’ve bought this and make sure that you’re set up for success in using all of these features. So it’s a different motion for us.
Magnus: Percentage use of features makes a lot of sense to track. But are there any specific features that if a customer starts using it, they’ll notice that they’re missing out on other features? Do you have a specific strategies to drive upsell? Are there features that you try to get them to turn on cause it’ll drive upsell?
Sherrod: It does to a degree. Yeah, but it’s more around the use cases in particular, than features necessarily. Our security use case is an example. So it might be our SaaS plus our DaaS and our container scanning. It’s not as simple as just the one, but yeah, we typically see customers being much more successful when they’re using multiple use cases. Because now you’re talking about removing friction and silos between teams and all the things that a unified platform gives you.
Magnus: Amazing, I’ve learned so much. This is so cool. I’ve started to become a CSM nerd. I love this.
Sherrod: Oh, good.
Magnus: Final question to end is, where do people go to nerd out on this? Where do we go to learn more about this? Where do you draw inspiration from?
Sherrod: So I will again, say that all of our processes are in the handbook, so there’s probably nothing that I’ve told you today that you can’t find in writing and it’s all public.
But Gainsight is really an authority in this space. So Gainsight’s got a great blog, they’ve got tons of resources. They’ve got a great early CSM course or if you want a new CSM to go and do a course or want someone to learn about good CS practices, Gainsight has some fantastic courses that they run.
So if I were to follow anything, I would follow them very closely. I’m very much and advocate. They’re the new Salesforce. Salesforce coined the term but Gainsight gave explanation to what it looks like in a modern day.