In most CS roles, your customer profile is relatively stable. You learn the persona, you learn the pain points, you build muscle memory. After a while you can walk into a renewal conversation and read the room before the first slide loads.
Then someone hands you a book written in a different language.
When I took on the Dropbox Sign API book alongside a Core Dropbox enterprise portfolio, I didn't fully appreciate how different the two worlds would be. On paper it seemed additive — same parent company, similar contract structure. In practice, I had stepped into two parallel universes that happened to share a logo.
The Audience Divide
The fastest way to explain the gap is to look at who I was talking to on each side.
Sign API · Developers & Builders
- Engineering leads, backend developers, CTOs at mid-market SaaS companies
- Primary question: "Does this endpoint do exactly what I need it to do?"
- Value is measured in milliseconds, error rates, and lines of code saved
- Trust is built by being technically credible — or at least technically honest
- Business context matters, but only after technical fit is established
- QBRs sometimes happen on Slack threads with code snippets attached
Dropbox Core · IT Admins & Enterprise Buyers
- IT Directors, Procurement leads, VPs of Operations, CIOs
- Primary question: "Will this reduce my team's overhead and keep my data secure?"
- Value is measured in seats, compliance coverage, and change management cost
- Trust is built through reliability, clear escalation paths, and not wasting their time
- Technical depth is table stakes — what they want is business judgment
- QBRs have executive sponsors and require 10-slide decks prepared two weeks out
Looking at that side by side now, the difference seems obvious. At the time, I was in the middle of it — trying to context-switch between a Postman collection and an executive business review deck, sometimes on the same afternoon.
The Technical Ramp Was Real
I won't pretend the Sign API learning curve was easy. REST APIs were not new to me — I'd supported technical users before, and my background includes work that required reading schematics and understanding system architecture. But understanding how an API works and being able to answer a developer's nuanced question about webhook retry logic or OAuth scoping at 9am on a Tuesday are different things.
I did what I've always done when I enter an unfamiliar technical domain: I got into it hands-first. I ran through the documentation. I set up test calls in Postman. I read the support tickets I couldn't answer yet and worked backward from the resolutions. I asked the solutions engineers every question I had — including ones that probably made me look like a beginner — because I'd rather look like a beginner for two weeks than appear knowledgeable and actually be dangerous.
I treated the API documentation like a product I was being onboarded to. I made a personal glossary of terms that kept coming up in tickets. I scheduled 30-minute sessions with two engineers just to ask "what's the thing our customers get most confused about — and why does that confusion make sense from their perspective?" That last question always unlocks the most useful mental model.
Within a few months I could hold my own in technical conversations. Not at an engineering depth — I never claimed that — but at the level where I understood the customer's problem clearly enough to ask the right questions, route correctly, and represent their technical reality back to the internal team. That's the CSM job.
The Unexpected Transfer
Here's what surprised me: the things that made me effective with IT admins transferred almost directly to developer customers — and vice versa — even though the surface looks completely different.
With admin-side enterprise customers, I had learned to do one thing very well: find out what success looked like to them, not to the product team, not to my quota model. Admins don't care about features. They care about whether this thing creates more work or less. They care about whether their team will actually use it. They want a CSM who thinks like an operator, not a salesperson.
Developers, it turns out, want exactly the same thing — just expressed differently. They don't want a product demo. They want to know if this integration will make their architecture cleaner or messier. They want a CSM who has read the docs, who isn't going to send them a PDF when they asked a technical question, and who actually remembers what they told you last quarter about their migration timeline.
The Principles That Held
When I reflect on what actually drove retention and expansion across both motions, it wasn't the technical expertise — though that mattered. It was a set of postures that I had developed over time and that proved strangely context-independent.
What I'd Tell a CSM About to Cross That Line
If you're moving into a technical CS motion from a non-technical one — or vice versa — my honest advice is this: the technical ramp is real and you should take it seriously, but don't let it convince you that you're starting from zero. You're not.
The skills that made you good at the human side of this work — listening carefully, building trust under pressure, advocating for your customer in rooms they're not in — those travel. They travel across personas, across product categories, across company sizes.
What the technical ramp gives you is the ability to ask better questions. And if you're already good at the human part, better questions compound quickly.
I came out of that period a different kind of CSM. Not a smarter one, necessarily — but a more adaptable one. And in a field that keeps changing what it needs from us, I'll take adaptable over specialized every time.
This is part of an ongoing series of posts about what actually works in customer success — the things that hold across motion types, company stages, and customer personas.