The CS Leader's First 90 Days: Why Fixing Things Too Fast Is the Fastest Way to Get Things Wrong

There's something almost adversarial about how CS leadership roles get filled. A company identifies a problem (churn is too high, the team is reactive, the metrics don't tell a coherent story), and they hire someone to fix it. The hire arrives with their own track record, their own frameworks, their own instincts about what good looks like. And then the clock starts.

The pressure to show early progress is real. Boards want signals. The team that's been waiting for leadership wants direction. And the new leader, who was hired partly on the strength of their views about how CS should work, has views they want to express.

What happens next is predictable: within the first 60 days, the new CS leader has made several visible changes: restructured the health score, redefined the segmentation model, introduced a new check-in cadence. The team is adapting. Some of the changes are improvements. Some are lateral moves: different, but not better. And one or two are making things worse in ways that won't be visible for another six months.

I've watched this pattern from the inside more times than I can count. The best CS leaders I've seen don't avoid making changes, but they earn the right to make them first, by spending the time to understand what they're actually changing.

---

The first 30 days: listen, map, don't fix

The temptation in the first 30 days is to fix the most visible problems. Resist it.

The most visible problems are visible for a reason: they've been surfaced by whoever has been managing up, or they're the things that appear in dashboards, or they're what the outgoing leader identified in the handover. They are not necessarily the most important problems. And addressing them first sends a signal to the team about what kind of leader you're going to be: one who runs toward the loudest noise, or one who takes the time to understand the room.

The first 30 days should be spent in listening mode. One-to-ones with every CSM, not to assess performance but to understand perspective. What do they think is working? What do they find frustrating? Where do they feel like the process gets in their way? What do they know about the accounts in their book that isn't in any system?

Alongside the CSM conversations: read the data. Not the dashboards, but the underlying data. What does the actual churn picture look like over the past 12-18 months? What were the patterns in the accounts that churned? How consistent is the health scoring across the team? What's in the CRM and CS platform, and how much of it can actually be relied on?

The goal of the first 30 days is a map, not a plan. A map of what's actually happening: the real state of the team, the real state of the book, the structural pressures that explain why things are the way they are. Most CS motion problems make sense when you understand the history. The health score that isn't trusted has a reason for not being trusted. The playbooks that aren't being followed weren't always ignored. The gap between what CS is supposed to do and what CS actually does reflects decisions, pressures, and constraints that someone made somewhere along the way.

Understanding that history doesn't mean being bound by it. But changes made without it tend to solve the symptom and miss the root cause.

---

Days 31 to 60: define the problem, align on success

The second month is where the listening turns into a point of view. Not a plan, but a shared definition of what the problem actually is, and what success would look like.

This is harder than it sounds. In most organisations, different stakeholders have different answers to both questions. The CEO's definition of the CS problem is usually about churn and NRR. The CFO's version is about efficiency and headcount justification. The sales team's version is about handover friction and closed-lost attribution. And the CS team's version is about capacity, tooling, and unclear expectations.

The CS leader's job in months one and two is to synthesise those perspectives into a coherent problem statement, one that's honest about where CS has been underperforming and where it's been undermined by structural conditions outside its control.

This is also the moment to negotiate on success metrics. What will the business use to judge whether the CS motion is improving? What's the timeframe? What are the dependencies that affect those metrics but are outside CS's remit? Alignment on success metrics in month two prevents a very predictable conflict in month nine, when numbers have moved in some ways but not others and nobody agrees on what that means.

The CS leader who gets this conversation right in month two tends to find month seven significantly more manageable.

---

Days 61 to 90: the first structural change, done with buy-in

By day 60, the new CS leader should have a clear point of view about the single most important structural thing that needs to change. Not a list, but one thing. The thing that, if fixed, makes the largest number of other things easier.

That might be the handover process, the structural gap between what sales promises and what CS inherits. It might be the health score: the signals being tracked aren't meaningful, or the definitions are inconsistent, or the CSMs don't trust the output. It might be the segmentation model: accounts are being grouped in ways that don't reflect the actual support they need.

Picking the one thing requires having done the listening and the mapping. It also requires the political work of building support. A CS leader who arrives at month three and announces a structural change without having brought the team along (even a good structural change) will meet more friction than one who has spent the previous two months making sure people understand why it needs to happen.

The first structural change is a proof of concept. It sets the tone for how the CS leader makes decisions: transparently or opaquely, with the team or at them. It also tells the broader organisation something about how CS will operate. Getting it right, and doing it deliberately, is worth the extra time.

---

What CS Ops changes about this picture

A CS leader arriving into a company that already has a CS Ops function has a significant advantage: they can get to the mapping phase faster. CS Ops should be able to surface the data picture (churn patterns, health score reliability, process consistency) without the CS leader having to piece it together from scratch.

A CS leader arriving without CS Ops (which is the more common situation) has to build the map from raw data and one-to-one conversations. That's still doable, but it takes longer, and it's one of the reasons CS Ops investment tends to have a faster payback in leadership transition scenarios than it might first appear.

The argument for CS Ops isn't always "it will help us run better when things are stable." Often the clearest value is in moments of change: when a new leader is finding their feet, when the book is growing faster than the team, when a restructure is forcing a reassessment of how accounts are segmented. Those are the moments when having a function whose job is the infrastructure of CS (rather than the delivery of CS) makes the most practical difference.

---

Questions worth sitting with

Looking back at the last time your CS team went through a leadership transition, what's the thing the new leader changed too quickly? What would have been better if there had been more listening time first?

As a CS leader (or as someone looking to hire one), how much of the first 90-day plan is about understanding the existing state versus introducing new frameworks? What's the right balance for the complexity of the current situation?

If you had to describe the single most important structural problem in your CS motion right now (the one that, if fixed, would make the most other things easier), what would it be?

---

The short version

CS leaders under pressure to show early results often make changes too fast, before they have a reliable map of what they're changing.

The first 30 days should be spent listening and mapping, not fixing. The second month should build a shared problem definition and align on success metrics. The first structural change belongs in month three, done with buy-in and a clear rationale.

CS Ops accelerates this: a functioning CS Ops team gives a new CS leader a faster, more reliable picture of what's actually happening.

---

Where Pivotal Path comes in

Pivotal Path works with CS leaders at moments of transition, whether that's a new hire finding their feet, a team that's outgrown its original structure, or a business asking whether CS is pulling its weight. We help with the listening and mapping phase, the structural diagnosis, and the first-change design that earns the team's trust rather than burning it.

If you're in the first 90 days of a CS leadership role and want a thinking partner, or if you're building the case for what the CS motion needs to become, we can help.