Adapting your customer success strategy through times of change

My name is Sherrod Patching, and I’m here to share how you can adapt your customer success strategy through times of change.

A bit about me before we get started: I’m the Head of Global Technical Account Managers at a company called GitLab. I've been leading customer success teams for around 12 years, since before it was called customer success.

About GitLab

Let me tell you a bit about GitLab. We are an open DevOps platform that facilitates end-to-end collaboration from product design, all the way through to the creation, testing, and release of the code.

We enable all the teams involved in that process to collaborate in one place. We're an open-source platform. That means that customers and members of our community contribute back to our platform – we’ve seen over 2200 code contributions to date.

One of the key pillars of our success is our values, which include iteration, transparency, and collaboration – all vital elements of managing teams through change. In this article, I’ll share more about how we apply these values plus these three key themes for managing teams and building strategy through change:

Your ultimate strategy always has to be customer value
Applying change management techniques
Always leading with transparency

Your ultimate strategy: Customer value

Customer value has got to be pivotal to everything that we do. We all know that, but when things become more challenging, we can lose sight of it. It’s easy to hunker down and start thinking about the looming competition, becoming hyper-focused on simply staying afloat, rather than prioritizing customer value.

The number one rule, no matter how hard things get, is don't fall back into a feature-function mindset. Don't let yourself be trapped in trying to compete with bells and whistles and shiny objects.

Maybe there are features that you need to consider building, and maybe there are areas in the platform that need to be built upon, but your approach always has to be guided by how to drive more value for your customers.

If the competition gets stronger, you need to double down on thinking about customers’ desired business outcomes, aligning with your customers on those, and reporting back on the progress you’re making towards those goals.

It's true that this, not the bells and whistles, is what's going to keep your customers loyal to your business.

Don’t lose sight of metrics

Metrics are the second piece – don't lose sight of them. Think about the “why” behind the metrics you have. If your metrics are changing as a result of the change in strategy that you're going through, there needs to be a direct line back to how that will impact the customer.

Think about onboarding and time to value. We measure time to value because we don’t want customers going through a long onboarding period where they feel like they're not seeing a return on investment – that’s going to make them frustrated and maybe even think about churning. There’s a direct link between this metric and customer value.

Maybe you look at NPS. I know there's a lot of debate around the efficacy of NPS, but it points back to the customer's satisfaction. It's not a vanity metric.

NPS allows you to have a conversation with a customer about how you can make high scores repeatable or solve problems so you don’t keep seeing low scores. To my mind, these conversations are the most beneficial part of tracking NPS.

You’ll also want to align some metrics with how you drive value for your team. In times of change, it’s easy to become hyper-focused on what the business needs to succeed, but you also need to look at how you can ensure that the team continues to be supported.

Why not establish lightweight metrics to ensure that your teams are bought into the new strategies you're rolling out?

Documenting your strategy

As you think about change, document your strategy. I know this seems obvious, but write it down, and write it down in a central place where people can see it and where you can iterate on it. Don't just put it in a deck and then leave it somewhere it will never be found again.

Your strategy should encompass all of the following elements:

What: Goal clarification

What are you trying to do? It's so easy to talk about what is changing without explaining the ultimate goal. For example, perhaps your goal is to drive customer adoption in another area of your business and you're going to do that through X process over Y period of time.

Why: The reasons for the change

Maybe this change will help customers be successful. Maybe that will help your business to continue to be successful. Maybe it’s simply to help the team to feel fulfilled in the engagements they're having with their customers. Whatever the reason behind your plan, make sure you share it.

How: Articulate the plan

While your plans may change, it’s better to articulate anything than to articulate nothing. Explain how you’re going to go about making this change, ensuring that people understand that you’re going to iterate on the plan so it may change.

Who/When: Assign owners and timelines

Timelines change, but it doesn't mean that you shouldn't have one to begin with. At least lead with the timeframes that you’re proposing to move these strategic changes forward.

WIIFM: How this change helps the individual, not just the company

Most importantly, spell out how this change is going to impact not just your customer and your business, but also how it's going to help your team.

What does it mean to them, to the fulfillment of their role, and to their job satisfaction? This is an incredibly important part of getting buy-in for any strategic change that you roll out.

Make room for feedback and iteration

Once you've documented your strategy, your next step is not to roll it out but to open up a forum to receive feedback.

At GitLab, when we're beginning to build out a new strategy or make key changes, we'll articulate that within an issue and then open it up to our teams for feedback – just the TAM team or even to GitLab as a whole, depending on who the new strategy is impacting.

We're not moving to a vote in opening this up, but we want to be sure to consider feedback early and often so that we don't roll something out and then discover that it's not the right direction, that there are problems we hadn't thought about, or that we don't have buy-in from the teams we're rolling this out to because we didn't introduce the idea to them early enough.

Be as transparent as you can in the decision-making process. Document your strategy and open it up for feedback. Whether you use GitLab or a Google Doc, whether you present it in a QBR or team meeting, give people an avenue to feedback on that idea, ideally in writing.

That way, you can read through your teams’ responses and consider whether you need to iterate on your strategy.

You also want to make sure you give yourself time for iteration. The last thing you need is to have only a day or two to get feedback when you're trying to ship change within a couple of days.

Assume you're going to need to iterate on your strategy based on the feedback that you get from the teams and give yourself time to do so. Finally, make sure it’s clear who is making the decision, what the timeline is, and that all feedback will be considered.

Communicate clearly and document

Once you've documented your strategy, you've taken feedback on it, you've gotten to your final strategy, and you're ready to roll it out, make sure you clearly communicate what the strategy is and document it in a place where people can find it.

I cannot stress enough how important it is to not just have it in a deck that you present once and then assume that it's out there.

We at GitLab have a handbook where we document all of our processes and our strategies. That way, it’s accessible not only to our teams but also to the general public.

Our metrics and plans for the coming year are documented in the handbook. That way when a new TAM comes on board, they don't need to learn everything through the grapevine. Instead, all that information is available to them in an easily searchable place.

Maybe you’ll use an internal wiki or just a Google Doc. In any case, make sure it's easily available to the team, that they know how to reference it, and that they can find and remind themselves of the goals there.

As you start rolling forward with your strategy, ensure that you're focusing on the results and not the tactics.

One thing I’ve learned over this last year of working with teams who are used to iterating on ideas is that there are probably going to be better ideas than yours on how to go about achieving your goals, so you need to be open to feedback throughout the process.

Focus on the ultimate goals you're trying to reach and the key milestones you're looking to get to, and then let go of the tactics.

Let the team give feedback on how things are going and give yourself the flexibility and the freedom to iterate on the steps that will get you to those milestones and goals as you begin to work with your team on the rollout itself.

Enable

Once your plan is out there, it's documented, and you’ve begun to communicate it, enable, enable, and enable some more.

Don't assume that just because you've outlined your strategy once people are going to remember it.

I have made the mistake many times of building out a plan, which becomes totally ingrained in me because I've spent so long thinking about it, then launching it to the team and getting confused as to why they can't quite remember the details – even though only I spelled it out once or twice at best.

Make room for yourself to go through this plan over and over again, build out enablement sessions, and drill down deep. You should expect to repeat yourself. In fact, you should plan to repeat yourself.

Whether in QBRs or team meetings, remind your teams of the key milestones and goals often. What are you trying to solve? What are you working towards? What progress have you made to date? Keep going over those pieces.

Build ongoing iteration on enablement for your team into your strategy. That way, you’ll ensure that they not only feel comfortable in what they're trying to achieve but that they feel supported in their progress.

This isn't just a strategy that's happening to them, but they are truly equipped to partner with you in achieving the strategy.

Lead with transparency

One thing I’m grateful to have been learning to a whole new level through GitLab is the importance of leading with transparency.

Be transparent as you can. Transparency doesn't mean just telling everyone everything after it's done but bringing them into the process as much as possible.

If you find that you do need to change tack or a milestone needs to move, have that conversation with the team as soon as you can.

Getting buy-in is about ensuring that people are brought into the processes early on so they can help determine what needs to change and roll that out with you. This can be slower than just deciding what you want to do and implementing it, but you’ll get more support and ultimately be far more successful this way.

You'll also bring your team on the journey with you. That means that they’ll be more fulfilled in their roles and the team’s health will be much greater.

You also need to be open to feedback. It can be challenging to roll out a strategy and have people tell you that the trajectory is not the right one. As you're rolling out changes, make sure your teams know that they can challenge your ideas.

Give them the autonomy to find better ways to get results. We hire smart people for a reason – allow them to come up with ways to augment your strategy and make it even better over time.

It’s important to revisit and reiterate your goals often. Even though your internal teams may be working towards the same thing, it can be easy to lose sight of the ultimate goal, so make sure you carve out time to reiterate what you’re trying to achieve, what it means for your teams, and the benefits of getting there.

Celebrate!

Most importantly of all, celebrate! Don't wait until you’ve achieved your ultimate goal – make sure that you find ways to celebrate little wins along the way. When someone finds a better way to get towards a milestone, celebrate that.

At GitLab, peers can nominate each other for discretionary bonuses, which is an awesome way just to say, “Hey, what you did was great!” We celebrate those bonuses in a Slack channel where you can see all the people who are being nominated.

We also have a thank you channel where people can thank their colleagues for, say, a great coffee chat or for going above and beyond in something they did.

I think sometimes we underestimate the value of just stopping and saying thank you to people, and the impact that has on their well-being and how invested they are in the company and the vision of the team.

That’s why at GitLab we make an effort to both celebrate excellence and thank people for going above and beyond in their roles.

Parting thoughts

I hope this has helped you to think about how to set and adapt your CS strategy as your organization moves through times of change. Now I’d like to leave you with a few key takeaways.

Start with a goal and come up with a couple of metrics that are going to get you towards that goal.
Make sure your goals align with customer value and with company value.
Consider how your new strategy will impact the teams involved.
Document everything and make sure it is available to the team.
Be open and humble and available for feedback.
Hope that others come up with better ways to get to the milestones and objectives you came up with.
Celebrate often.

This article is based on a presentation given by Sherrod at the Customer Success Festival in June 2021 when she was Head of Global Technical Account Managers at GitLab.

Catch up on this presentation, and others, using our OnDemand service. For more exclusive content, visit your membership dashboard.