Winning at pre-to-post-sales: Lessons from Gitlab

In this episode, we are joined by Reshmi Krishna (Senior Manager, Enterprise Solutions Architect) and Sherrod Patching (Head of Global Technical Account Managers), GitLab.

Reshmi has extensive experience in being an engineer and a solutions architect. She has been in leadership positions for multiple years now.

Sherrod is a seasoned customer-centric technology leader with deep experience in building high-performing global teams focused on driving excellent customer experience and significant revenue growth.

While Reshmi loves to dive into the nitty gritty, Sherrod excels in driving organic and inorganic revenue growth.

In this episode, we have them talking about:

1. What pre-sales and post-sales look like at Gitlab, and how they have evolved
2. How should the right journey be structured from pre- to post-sales
3. How to get  better at handoffs

...and more.

Check out our conversation below.

Sri: Let’s start with a fun intro. Reshmi, tell us what you think is Sherrod’s superpower at work. Sherrod, you’re next!

‍Reshmi: (Being) the Peacekeeper. Whenever I'm in a meeting with Sherrod, no matter how challenging the situation, she always diffuses it and brings a calm energy. I love that about her, and customers love working with Sherrod. She represents the GitLab values in front of our customers, internal team members, and execs alike.

Sherrod: I actually think I’ll struggle to pick between the two that I see, and so I'm going to give both of them to you. 

Reshmi leads with passion, which is incredibly valuable. Everything that she brings, he brings with honest energy that just really drives change. I think when you look at leaders across our org and other orgs, those that really lead with passion are the ones that have always stood out to me and Reshmi does so to another level.

That's one side. The other is that she excels at the macro and the micro – which is incredibly difficult to do – to be able to go from strategic initiatives down into the details… working through very detailed analysis for our customer base, but then also being able to zoom back out and have those macro business-level conversations with our customers at the same time. So I think those are two of her superpowers.

Sri: Awesome. Before we get into how things are beautifully orchestrated at Gitlab, let’s talk a little bit about the history behind it. How were things set up when it comes to like presale and post-sale? What challenges did you see?  

Reshmi: Absolutely. So before I start, I’d to level set on what the pre-sales process looks like in GitLab, what it used to be, and what it looks like today. I'll talk about some of the challenges that we saw in the past and how we are solving them today.

So in terms of our pre-sales journey, we get involved after the sale. Our sales counterparts, or account execs, have the initial meeting with the customer and understand their pain points and value drivers. And then they bring in a Solution Architect (SA), essentially to show the product, and do demos, etc. We have different processes for our technical evaluation, which starts with the technical demo, which can then go into a deeper dive, a hands-on workshop, and finally culminate in a proof of value – when need be for customer scenarios and use cases.

In the past, we would often proceed with the technical evaluation, and only after we won the technical evaluation, would we involve the technical account manager from Sherrod’s team. They came in, and it was a handover meeting almost – and then we throw the ball over to the technical account managers. Oftentimes what we saw was that we had to be brought back in, because customers had that previous relationship with us.

So essentially, the challenge was that we were bringing Sherrod’s team too late in the game. We were essentially doing a formal introduction and walking away, instead of leveraging some of their superpowers. So, bringing them a little bit earlier and closer, making sure customers understand that they are also technical advisors – that's something that we have been working on for the past year and a half. 

Sri: Perfect. I think that gives us good context on how things used to be and some of the challenges. Sherrod, is there anything else you'd like to add about other challenges downstream?

Sherrod: I think when you're so deeply involved with the customer for the period that Reshmi’s team is, a handoff meeting isn't enough. We need that handoff, but it’s about the Solution Architect actually introducing the account in the pre-sales process, saying, “This is going to be the person who is really going to be your guide on adoption for the post-sales journey. We're aligned on the business pains that we're solving for, your desired business outcomes, and they are going to work with you on the milestones”. 

Setting that expectation upfront is incredibly helpful in ensuring that post the sale, the customer understands who this person is and what their role is. And just to level-set, the term can mean different things across different words. We don’t have CSMs. The Technical Account Manager owns the customer lifecycle post-sale and is responsible for ensuring the customer adopts their desired use cases and expands into additional use cases. 

Sri: Sherrod, can you get into some detail on what that process looks like now and what happens – starting from when you get introduced and down to the post-sale journey?

Sherrod: So if you're not familiar with GitLab, we do everything as transparently as possible. The GitLab handbook contains most of our processes, bar those that can't be documented publicly. And our desire is really that other people can see this, and actually benefit in their own orgs.

Back to the question.

So, when we get involved, our primary goal is to understand what the customer is looking to solve (for), and the business pains discussed. 

We believe that our platform is really a vehicle for the customer to achieve their desired business outcomes. Our goal is to not show them all the features and functions. And if you're not familiar with GitLab, it's a very robust platform that solves several use cases. So you could talk about features and functions all day, but you could end up never talking about business value. And so our goal is to really engage with the customer and understand:  

What they are trying to solve? What are their desired business outcomes? And what are those milestones?

We capture those in partnership with the SA from the pre-sales process, and that goes into a success plan that then becomes really the customer-facing roadmap as we move forward. Then we actually have a series of enablement steps that will run with a customer. So that’s about how we wrap our arms around the desired use cases for the customer.

For us – because we're a collaboration platform for teams from product through to development through tests – our team actually looks to see how we ensure that we enable customers on their core use cases, always, and then agree on a set of metrics that are going to get them to the desired business outcome. So that might be saving cost by a reduction of the toolchain, or it might be improving cycle time to get products shipped faster. So we want to align on those, the path to getting there, and then align on the enablement that is needed for our champions and the broader orgs, to be equipped to be successful with GitLab. And then, we want to make sure that we track the progress of that we do that through executive business reviews. Typically, they're around the sixth month of each year, we ask, “What is the progress that we've seen?
If progress hasn't happened to the degree that we were wanting, how do we recreate that alignment on what's important?”

And then from there, we drive into additional use cases. The customer can solve all of their development planning, development testing, and security needs on GitLab, and as we begin to build trust, through success and maturity, we work with them to expand them into additional use cases so that they can continue to have an increased return on investment. So that's our lifecycle at a very macro level. But the real goal is to ensure that customers are successful with their desired business outcomes. And that starts in the pre-sales process.

Sri: Got it. For those of you who don't know, one of the unique things about Gitlab is that it's fully remote. What's helped you succeed in figuring out the right playbook, and, ensuring it's documented to the T?

Reshmi: As Gitlab as a company and as team members, we have our ‘CREDIT’ values – Collaboration, Results, Efficiency, Diversity, Inclusion and belonging, Iteration, and Transparency. And as a company, that is the core of how we act every day. 

If there's a challenge, if there's a process, or even if you're a manager of one, you can implement that and we will iterate over it. That's the whole purpose of just starting. Get started, with a minimal viable product, and then we will iterate over it. And since we are a very transparent organization, everybody can come and chime in. However, there's also a concept of Directly Responsible Individual (DRI), and I love that because as you grow – specifically at the stage that we are in –  we have a lot of collaborators cross-functionally, and we work acing through issues and documents, Google Documents, and so on. As a DRI, it's in your power to make sure the task gets completed in a timely fashion.

One of the values that I really admire in GitLab is ‘assume positive intent’. So a lot of the times when you're remote, and haven't seen somebody in person, just assuming positive intent and asking questions have helped a lot of our team members in the past.

Sri: Sherrod, do you have anything you want to add to that in terms of process evolution? And you lead a team, different ideas are going to come through. How do you manage all of that in the remote world and ensure everyone feels heard and influences how you chase your outcomes?

Sherrod: I'll double-click on Reshmi’s points around issues. So we use GitLab for our collaboration, and anytime we start a new process, we will open it up in an issue. So around this specifically, this pre to post-sale, we had a realization through a couple of customer experiences that we could improve the process that we had in place. It was identified actually by one of our team members in conjunction with the SA, and then one of our sales leaders decided to work together and collaborate on a solution that was an improved iteration of our process. So they started out by proposing what they were thinking about doing – in an issue.

If I'm remembering correctly, a few others decided to be a part of the initiative. We typically open up issues in public, and from there, we ask if anyone is interested in contributing to this. We make sure that it's brought up in team meetings so that people understand that this is something that we're working on. And then the progress against these initiatives is typically documented in the issue.

It’s all very transparent. And as a result, people can be a part of things that they want – they can be receivers or participators, it's really up to them.

But to Reshmi’s point, the way you keep it moving is by having a DRI and oftentimes we will make these into OKRs. So when we find that there are key process initiatives that we want to improve, that we want to be time-bound, we make them OKRs to give ourselves accountability.

So that's the key piece for us really.

I would really encourage people to consider opening up their process changes at the beginning – because you get so much more buy-in when people are a part of the process versus when they’re told what you've already decided.

‍Reshmi: And just to add to Sherrod’s point, all of this goes back to our handbook. The GitLab handbook is a single source of truth. Whatever you do in terms of issues, or whatever your collaboration methods are, everything ends up in the handbook. 

And so as a result, you can see what people have done in the past and you can iterate over it. And that's I think that's another key piece of how GitLab as a company works really well every day.

Sri: I'm sure over the last two years, many organizations have benefited borrowing from your handbook. 

A question that comes to my mind, looking at the pre-sale part. You mentioned that you do proof of value exercises with some of the customers, not all of them. How do you ensure that during the POV, you're building for someone to take it over and make it part of the real-life implementation? Versus just throwing it out? Do you usually look at it as just proof? 

‍Reshmi: Absolutely. And that's a great question, Sri.

So at GitLab, we do Proof of Value –  that's slightly different from Proof of Concept. Proof of Values are where you have defined success criteria that align with the customer’s pain points, and you will have already discovered the value drivers before you embark on this proof of value journey. 

Now, in terms of implementation, it really depends on the customer. Ideally, what we prefer, is to get customers to  implement GitLab in their non-production environment. We do have Professional Services, who then can work with the customer to implement that in their own production environment. 

Now, there have been times that we do proof of values and phases. So essentially, if you're looking at capabilities that you want to prove, we say, “Let's prove it out in your non-prod environment, and you can take that to your production environment”. Sometimes, we implement some of the features in the production environment. However, looking at how we are structured, that is an anti-pattern – because we do have Professional Services, and we also want to empower our customers to do what's best for them. 

And then when you think about our support organization, and our technical account manager organizations, and when they come in, it's again, going back to our handbook – we have reference architectures that we follow, starting from the pre-sales process. 

So, customers have to abide by that reference architecture. Sure, they can make customizations, but that has to be approved, so the support can then make sure that the installation is done properly, based on that.

Sri: I think what I'm hearing is that you still follow the right reference architecture. It's not a scrappy prototype to prove something – it's actually done the right way, so you can move it to production, but it's not necessarily the pre-sales team that's going to do that part of it. There may be a professional services team that comes in to translate what you've built out in a pre-prod, or staging environment, to a production environment.

You get to that proof of value, and the customer says, “Yes, this is successful”, and then buys. And then, Sherrod, our team that is already involved at that stage has then taken over the customer account. 

Now, how do you think about value beyond that? You mentioned that there are a bunch of things that you can enable further. Do you follow some sort of a prescriptive model? 

Or do you let the customer decide where they want to get to first?

Reshmi: The first step is really more about letting the customer determine where they want to get to first. We know that there are some primary value drivers for GitLab – you improve cycle time by having all the teams collaborating in one place, you're going to build products faster, you reduce your spend because we have your toolchain consolidation, and it actually decreases the security risk, which is a big piece, right? 

So customers typically have these three primary value drivers when they come to us.

But then from there, it becomes more about the customers and how they go about getting there. it could be that they want to improve their cycle time, decrease it by rolling it continuous integration with other solutions, or it might be removing the roadblocks that we discover together. So the path is really determined in the pre-sales process and it is quite custom to the customer – once you go below the overarching business objectives.

‍Sri: Got it. And is there a way you measure time-to-value, first value, etc?

‍Sherrod: Yeah, we do. Today, we measure time to value by license utilization. So, license utilization itself is not the value,  but it is a proxy for the fact that the customer has gotten past their initial setup, and are bringing other users onto the platform. So for us, the real beauty of GitLab is when you have multiple teams collaborating together, or when you have multiple use cases all being brought into the same platform. 

So it's this one collaborative platform for all of these different teams and removing those silos from those different teams. So when we see that an admin is starting to bring their users onto the platform, then that is a proxy for the fact that they are getting to the point where they are beginning to truly receive the value of the platform. So that's how we measure it today. 

And we expect our customers, regardless of size, even our enterprise customers, to get there in 30 days, and with our smaller customers, we expect to get them more quickly. So you can get going with GitLab fairly quickly. And of course, Reshmi’s team is very key in helping a customer get there – they're starting that collaboration process before the sale.

Sri: Reshmi, is that something you measure – how many customers get to value in terms of license utilization even before the purchase?

Reshmi: That's not the specific metric we measure. However, we do measure the number of SA touches per customer, and the win rate. And then when we are engaged with the customers, we also measure their metrics. So we ask, “What are the key metrics that you are you want to measure? Or what are the key metrics that you are aligned to?”

And we often have that as part of our proof of values, which we then pass it over to our TAM (technical account managers) team so they also can measure that as well. I think, we have very customized customer value metrics also. But they're in addition to the time to value that we measure. License utilization is one that we can do across the board. 

‍Sherrod: The primary thing that we're doing with time-to-value is to determine where customers are getting stuck so we can determine where we spend our efforts. We have a large portion of our customer base with smaller ARR, and we need to be very mindful of how we spend our time with them. And the time-to-value metric helps us to determine which customers are potentially getting stuck in those early stages and how we can help them overcome. Those first 90 days are key, right? So, if we identify, say at Day 30, that a customer is getting stuck in that process, we can then have our Scale team reach out to those customers. So it’s slightly different for enterprise than it is for our smaller customers, but we'll use that metric to see trends and to identify customers that are potentially getting stuck early on before they go too far in the wrong direction.

‍Sri: Are there other ways in which you quantify and measure ROI? 

Sherrod: Yes, there is. So it really comes down to two key elements. One is from the three value drivers that I talked about. So cycle time, reducing spend, reducing risk. So there are ROI calculators for each of those we can help customers with.

But beyond that, it really gets into the the key metrics that Reshmi was talking about. So some customers may already have ROI associated with their goals. They're looking to achieve something, and this is the outcome. And sometimes it's just not quite as quantitative as that.

For example, a customer was looking to reduce the friction between the team. There were a number of different teams working on different platforms, and there was significant friction between the developers and security teams – with the code kind of waiting to be released. 

And then things gets kicked back very late in the process, and the developers move on, and it creates all sorts of challenges between the teams. Having those teams move on to go-live actually reduced friction and improvedthe quality of work for those teams. I'm sure you could probably measure that in a reduction of headcount churn. But it's more of a qualitative metric though, where you're looking at sentiment, but we look at both for sure the ROI and the sentiment also. 

‍Sri: Perfect. And what are some other metrics that you measure for your post-sale org?

Sherrod: NRR and renewal rate, those are key of course, because ultimately if you've got happy customers that are churning, then they probably weren't that happy. So that's incredibly important to us. And the GitLab handbook has all of our metrics – so you can have a look at some of them.

But for the early onboarding stage, we look at how long it takes to speak to a customer – the first customer engagement after they've come out of a great pre sales process. And the longer that takes, the more you lose that initial excitement. So we really have a goal of ensuring that we get to customers quickly.

We want to make sure that we hit the ground running with the success plan and the agreed upon milestones. 

Time-to-value is the second one and then, total time to onboard. So that’s about better understanding where customers are getting stuck and how we can improve for that customer, and also the processes invp;ved. We also look at  the how many of our Tier 1 one accounts have success plans in place, ensuring that we do have strategic assessments for all of our customers. All of this is measured through Gainsight. 

And then, we also look at executive business reviews (EBRs) and their completion rate.

We also lead a series of post-sales workshops that are enablement-focused and help us our teams or our customer teams enable their broader user base. We look at how many workshops are delivered and the percentage of our accounts that are seeing these. And that's really a proxy for ensuring that enablement is happening live with the customers and with their broader user bases. 

We also look at certain lagging indicators like license utilization, product adoption, and also, understanding if they are adopting the use cases they intended to use, etc.

Sri: Perfect, that's such a pretty comprehensive answer. 

Since we have both of you here, one of the things I'm curious about is this: What are other ways that presale and post-sale can partner up to deliver value? And what one of those are you already doing at GitLab?

‍Reshmi: Absolutely, thanks for that question. 

If you look at our customer journeys, after we hand off to our TAMs or our post-sales peers, we don't just walk away. We are still there, and we do get pulled back.

For example,  when you talk about upgrading a customer (GitLab has different tiers), or when you're talking about upgrading either the tiers or involving a new business unit( and then redoing the discovery process, and redoing the pre sales process for that particular business unit), we work very heavily with our peers in the sales organization there. 

We have, in the past, collaborated with Sherrod's team on customers workshops, webinars, and hosted them together. Depending on the skill sets, the process, etc., the solutions architects will get engaged back in. And we have this thing we call SAL-SA-TAM, where our SAL (our Account Exec), SA, and TAM meet on a bi weekly or weekly cadence to see if there are things that need help.

So again, as a whole organization, we are very collaborative. And there's never a point where we just say, “Okay, we've handed over”, and walk away.

‍Sri: Time for a controversial question. If there was an escalation in something that was done as part of a POV and you already handed off, who's going to handle it – is it presale or post-sale? 

Say, something that becomes an issue down the road – but wasn’t discovered till the sale was complete and the handoff was done.

Reshmi: Okay. So, let me break down into two different parts.

Number one: Anything that is part of the proof of value should be implemented in a non-prod environment. It's an anti-pattern to do it in production. But there have been instances where we have done it, and the SAs have to bring in Professional Services.

That said, there have been instances where either if the partner has been engaged, or the SAs have been engaged, and we haven't done that, that onus had come to Sherrod’s team where they say, “Hey, we are implementing in production right now, and we have these XY and Z issues. And what do we do?”

Then what we do is: I have my own peer from Sherrod's team, and we work together to see how we can handle things, or engage our support organization, or engage  Professional Services. And then we have our broader customer organization, that we work with very closely together. 

So this individual, ,my peer from Sherrod's team and I have our weekly meeting, we collaborate through Slack, etc. And although it might look like Sherrod's team is owning it on the front, and talking to the customer, in the background, we all work together to make sure this is not an issue, and so nobody is just left there by themselves. 

‍Sri: One last question before we go to the next section of the podcast. 

And Sherrod, this is for you. What are your big initiatives in 2022 – especially around streamlining customer onboarding?

Sherrod: We are rolling out two new TAM teams. So traditionally, we've had only one TAM team. We're rolling out a mid-touch team this year, and we're rolling out a Scale team. And the goal is to touch more of our customer base –  but in a programmatic and efficient way. We want to make sure that our customers all have access to this kind of proactive guided onboarding, to ensure that they are set up for success early. 

We're rolling out the Scale team – that is the newest approach, and that is going to be primarily through webinars. So just this month, we launched our first weekly webinar series. And that's going to be based on an intro to GitLab, some best practices, and then some deeper dives into some of the topic areas. And we are driving all of our net new customers to these webinars, and then encouraging our existing customers who have new users to also attend. 

So the goal for us is to see if we can actually see the common threads. Just before this call, I was on a call with our support leadership to understand the things we're hearing more recently in support tickets for customers in months one and two, and how we can bake those questions into the iterations of the content that we're creating.

So the short answer is:  

• two different teams – that's the big strategy change for us,  
• a huge focus on initial customer onboarding, 
• heavier touch for a customer. Even on the scale side, for smaller ARR customers, we're still implementing a Day 30 check-in. So a person will reach out to this customer base to make sure that things are going well, to ensure that a customer has someone they can talk to when they hit challenges, and that they're equipped to reach out to support and find documentation and the things that are key. 
• this programmatic approach where we have a digital onboarding that all of our customers receive, in addition to the TAM touch as well. So our goal is almost to teach them to fish – sending them the digital content early based on the questions that we know customers are asking, guiding them towards webinars where there's a live Q&A, so customers can come with questions around these particular topics
•  and also that additional customized approach when there is a TAM assigned some of the larger ARR accounts – based on those customer milestones that we've been discussing.

‍Sri: Perfect. Thank you so much, both of you for answering all the questions. Now we come to the final part of the podcast, which is three quick questions for both of you. Here we go. 

A book or movie that inspired you recently.

Sherrod: Yes, so I am reading – I say reading in air quotes as I'm listening to it – No Rules Rules: Netflix and the Culture of Reinvention, which is about the Netflix culture, and it is outstanding. So if you are interested in some of the things that they have done and how they go about thinking about culture, I would highly recommend it.

Reshmi: I'm reading this book called Impact players by Liz Wiseman. I don't know if you've read the book Multipliers written by her. Essentially she talks a lot about how you can scale up the ability of the team to lead and to be managers at once. She talks a lot about how to create each individual in a team and how to lead them to become impact players in their own organization and field. And I love that book!

Sri: Amazing, I think I need to add that to my list, we go to the next question. What's the best advice you've received about dealing with customers?

Reshmi: The best advice I received was: Control what you can control. And essentially, just believe in the process.

And what happens is that when a customer comes to me with any challenges or issues, I try to see how I can handle everything that the customer is asking for, and also do XYZ in the process. And often, time is a limiting factor, and you have to get to the result really, really fast. So essentially, just working through the things that I can control at this moment, and creating a phased approach to where I cannot control things, and just communicating that – that’s what I can do. 

‍Sherrod: Mine is probably from a very long time ago now. It’s to just put yourself in the customer’s shoes. When you're building out a strategy or leading large teams with big customer bases, it can be very easy to start to focus on the process and start to forget about the person. 

And so I think just remembering to maintain that level of empathy with a customer. We can have the most impressive pre to post sales process, but if the customer is unhappy, then something is lacking.

Sri: Awesome. And that reminds me of something that I think Amazon does. In every meeting, they have one empty chair. So when they're making decisions, they also ask, “Okay, that's the customer’s chair. What would their perspective be?”

I've come to the last question now, and I'm going to ask you to ask each other a question. 

‍Sherrod: One question for you, Reshmi. As we we pursue ensuring that we continue to improve on our diversity, inclusion, and belonging focus, what do you think is going to be a key area for us this year in doing so?

‍Reshmi: I can actually think about three key areas that we're already working on. Number one is increasing communication, and just having that open forum.

And the second I would say is hiring –  making sure our processes take into account cognitive biases and making sure the processes are aligned, so we are cognizant of all the different individuals that come through the process, and making sure everybody has a fair chance to succeed. That's another key area.

And the third one, I would say is in terms of retention, we need to think about career development, and just really focus on making sure that people already in GitLab are happy thriving, and where they want to be in their career, and that they have a clear goal and pathway to go there. 

Reshmi: Sherrod, a question for you: What was the most challenging part of your day today?

Sherrod: I have two little girls, one of them just turned three and she is a force to be reckoned with. So the challenge is making it work between work.

It is a gift that I work for a remote company and so I'm not dealing with commutes on top of this, but making it work is not easy as a parent, or it's not easy at all for anyone who has anything outside of work. 

I think one of the the real beauties of GitLab is that we very much value friends and family first. And I work for a company that is empathetic to the fact that we have lives outside of GitLab. And that is, I think, what makes this possible for me to progress and be promoted, and have a career as a woman and as a leader here at GitLab and still have a fairly intense life, outside.

‍Sri: Perfect. I think this has been a great conversation. I really enjoyed listening to both of you. Kudos to GitLab for enabling these careers that we're seeing and the way you're progressing and making a difference. Thanks so much for participating!