The first CS hire: what you actually need versus what you think you need

The conversation about making a first CS hire usually starts in the wrong place. A founder or sales leader notices that customers are struggling, not enough to churn yet, but enough to require more hand-holding than the team can sustain. The response is to hire someone to do "customer success." The job description goes up. It asks for someone who is "proactive and reactive," "data-driven and relationship-focused," "experienced with enterprise accounts and comfortable in a startup environment." And the salary range is set for a mid-level generalist.

The problem isn't the hire. The problem is the role. That description isn't a CS hire. It's a rescue attempt.

---

What you think you need

When teams make a first CS hire reactively, they're usually hiring for relief. The job is to take the inbound volume that nobody else wants to own: the support questions, the onboarding calls, the renewal anxiety. Someone calm, capable, likeable. Someone who can hold the relationship while the product catches up.

That person exists. They're useful in the short term. But they solve the wrong problem, because the thing driving the volume isn't that there isn't a CS person. It's that there's no CS motion. No defined onboarding path. No signal for when a customer is struggling before they say so. No handover protocol from sales. No agreed definition of what success looks like at sixty days.

A hire who can handle volume doesn't build the motion. They absorb it. Six months later, they're overwhelmed, customers are still inconsistently onboarded, and the team is wondering whether CS is working.

---

What you actually need

The first CS hire at a growing SaaS company needs to be able to do two things simultaneously: be in front of customers, and build the infrastructure that makes CS sustainable beyond one person.

That's a different profile from "reactive generalist." It's someone who can do account management (run the calls, handle the relationships, hold the renewals) and who thinks structurally about how those processes should work. Someone who, after three months of doing onboarding manually, writes the playbook instead of just doing onboarding again. Someone who looks at a CRM full of unstructured notes and asks what data they actually need to track.

This person is harder to find and more expensive than the reactive generalist. They're worth it, because the alternative is hiring reactively, watching the function fail to scale, and then trying to retrofit structure around an overwhelmed team.

The simplest proxy for this profile: ask them what they'd build in the first ninety days. If the answer is mostly about calls and relationships, they're a CSM. If the answer includes "I'd map the current onboarding journey and identify where customers are getting stuck, define what good looks like at day thirty and day ninety, and build a CRM view that tells me which accounts need attention before they tell me". That's closer.

---

The scope question

One of the things that goes wrong with first CS hires is unclear scope. They end up owning whatever doesn't fit anywhere else: support tickets, billing questions, feature requests, QBR logistics. Not because that's a good design, but because it's the path of least resistance.

Before hiring, it's worth being honest about what's actually in scope and what isn't. CS is not the same function as customer support. It's not the same function as sales ops. It's not the same function as solutions engineering. A first CS hire who is drawn into all of those simultaneously can't build a function. They can only react to whatever is most urgent.

The scope question is partly about headcount (if you need a support function, hire for a support function separately from CS) and partly about internal alignment. Does sales know there's going to be a handover process, and do they have any say in how it works? Does product know that CS is the channel through which customer feedback should flow? Does leadership understand that CS needs to operate proactively, which means the CSM can't be on call for support tickets all day?

Getting alignment on scope before the hire saves a significant amount of pain afterwards.

---

The sequencing reality

Most companies make their first dedicated CS hire later than they should and earlier than they have the infrastructure to support a CS function properly. The hire arrives, finds no defined onboarding path, no CRM hygiene, no agreed handover from sales, and no clear success criteria, and gets to work building all of that while also managing accounts.

That's not ideal, but it's normal. The question is whether you hire someone who can build under those conditions, or someone who needs the infrastructure to already exist. The former is rarer and more valuable. The latter will struggle and leave.

The honest conversation before making the hire: what does this person have to build themselves, and what will you build with them? If the answer is "pretty much everything," the profile needs to reflect that.

---

Questions worth sitting with

• Is the driver of your first CS hire reactive (volume, complaints, renewals at risk) or proactive (you want to build a motion before you need one)?
• Does the person you're hiring have experience building CS processes, or experience working within them?
• Before the hire starts, do you have a clear answer to "what does success look like for a customer at ninety days post-onboarding?"

---

The short version. First CS hires often get made reactively and scoped incorrectly. The hire you need is someone who can manage accounts and build the infrastructure that makes the function scale, not just absorb the volume. That's a harder profile to find and requires more internal alignment upfront, but it's the difference between hiring once and hiring twice.