Content
Most CS leaders were told, at some point in their career, that good work speaks for itself. Keep your head down. Don’t play politics. Let the metrics make the case. The org will recognize it.
That advice is the single most career-limiting belief in CS leadership.
Ok, I hate using the word “politics.” It carries baggage that makes most CS leaders tune out before the conversation even starts. People hear it and think manipulation. Back-channeling. Positioning over substance.
That’s not what I’m talking about.
What I’m talking about is organizational awareness. Relationship capital. Strategic communication. The invisible layer of every company that determines whose ideas get funded, whose work gets recognized, and whose career moves forward. Call it what you want. The playbook is the same.
And the CS leaders who don’t engage with it don’t opt out. They just participate badly.
The problem with how CS leaders think about this
Most CS leaders treat organizational dynamics like a distraction from the real work. Something other people do. Something a little beneath them.
That framing is expensive.
The work matters enormously. The org doesn’t make decisions based on work alone though. It makes decisions based on relationships, perception, and trust built over time. Budget decisions. Promotion decisions. Which functions get included in strategy conversations and which ones get looped in after the direction has already been set.
All of that runs through the invisible layer. CS leaders who engage with it deliberately are the ones who shape those decisions. The ones who don’t watch from the outside wondering why CS keeps getting overlooked.
The ones who never learn this end up building great things inside orgs that never fully recognize what they built. The function stays underfunded. The career stalls. The promotion goes to someone who, by every objective measure, delivered less.
The org isn’t unfair. Influence is built. They just never built it.
Here is the playbook nobody gave you.
1. Map the org before you need something from it
Most CS leaders only think about organizational relationships when they need something. A budget approved. A decision reversed. A conversation with the CEO. By that point, the relationship work is already too late.
The first play is to map the org as a regular practice, not a crisis response. Who influences whom. Who has the ear of the CRO. Who the CEO actually listens to when they need a trusted read on something. Which cross-functional leaders are the real decision shapers versus the ones who show up after the decision has already been made.
You don’t need this information when everything is fine. You need it to already exist when something isn’t.
The tactical move: Spend 30 minutes this quarter mapping the three to five people whose perception of CS matters most for your goals in the next 12 months. Then ask yourself how much time you’ve actually invested in those relationships. The gap between the answer you want and the answer you have is your starting point.
2. Build influence across the org, not just inside CS
CS leaders who only have CS relationships have CS influence. That’s a ceiling.
The CS leaders who shape org-wide decisions have relationships across Sales, Product, Finance, and Marketing. The difference is understanding that influence in a company scales with how many people trust your judgment, not how many people know your name.
The relationship with your CRO matters. The relationship with your CFO matters more than most CS leaders realize. The relationship with the Product leader who controls the roadmap your customers ask about every quarter matters enormously and almost never gets invested in until there’s a conflict.
Build those relationships when there is nothing to ask for. Show up curious, not transactional. Ask what they’re trying to solve. Share something useful. Be consistent over time. The relationship that exists before the ask is the only one that works when the ask is real.
3. Make your work legible to the people who don’t see it
CS work happens close to the customer and far from leadership. The conversations, the insights, the risk signals, the expansion opportunities — most of it lives at a layer of the org that the exec team never directly observes.
The move is making your work visible in the language the people above you actually use. Health scores and QBR completion are CS language. Revenue outcomes, retention economics, expansion signals, and competitive intelligence your customers hand you every week that nobody else in the company has access to, that’s business language.
When CS shows up to a leadership conversation with that framing, it stops looking like a function reporting on itself and starts looking like a strategic intelligence source. That’s a very different position to be in when budget conversations happen.
4. Know who will back you publicly before you need them to
There’s a specific relationship most CS leaders never build: the one with someone who will speak up for CS in a room you’re not in.
This is different from having good working relationships across the org. It’s knowing which leaders have enough context on what CS does, enough trust in how you operate, and enough standing in the company that when something comes up in a leadership meeting, they’ll say something that shifts the conversation.
That relationship requires investment well before the moment arrives. It means making sure the right people understand what CS is building, why it matters, and what it would cost the company to underinvest in it. Over time and through consistent communication, not in a single urgent conversation.
One CS leader raising a concern looks like a CS problem. Two or three senior leaders raising the same concern looks like a company problem. The difference is the coalition built before the moment required it.
5. Manage the perception gap deliberately
There is almost always a gap between how capable a CS leader is and how capable they’re perceived to be by the people who make decisions about their career.
Most CS leaders assume this gap closes on its own as results accumulate. It rarely does. Perception is shaped by how deliberately a leader manages it, not passively by how well they perform.
The move is taking ownership of your narrative in the org. Consistent, clear, and credible. Not self-promotional. How you show up in cross-functional meetings. How you communicate CS’s contribution in language leadership understands. How you position yourself in the conversations that determine what happens next for the function and for your career.
The CS leaders who navigate this well never call it managing perception. They call it communicating clearly. The reframe itself is part of the play.
6. Play the longer game than the situation wants you to
The instinct when something goes wrong is to respond fast. Confront directly. Escalate immediately. Force the issue before it gets worse.
That instinct is almost always wrong.
Organizational dynamics move slowly. The conditions that created a problem took months or years to build. The conditions that resolve it take time too. The CS leaders who win these situations resist the urgency the frustration creates and play at the pace the org actually moves.
That means documenting patterns instead of reacting to incidents. Building the coalition before surfacing the concern. Letting behavior become visible to people with more power rather than narrating it. Taking the conversation to leadership when the relationship and the evidence both support it, not when the emotion is highest.
Patience in these situations is not passivity. It’s strategy.
WHAT THIS COSTS CS LEADERS WHO SKIP THE "POLITICS"
The playbook doesn’t feel like real work. It feels uncomfortable, sometimes calculated, occasionally like things you’d rather not have to think about.
CS leaders who never develop this muscle don’t just lose individual battles. They build entire functions that the org chronically undervalues. They get passed over for roles they’ve earned. They watch influence, budget, and recognition go to leaders who, by every technical measure, delivered less.
The work you’re doing is real. Whether it gets recognized depends on whether you’ve built the conditions for recognition to happen.
That’s learnable. And the CS leaders who learn it change what’s possible for themselves and for the function they’ve built.
