> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt # Technical customer success managers are harder to hire than engineers Canonical URL: https://posthog.com/blog/hiring-technical-csms ## On this page - [What we look for in technical customer success managers](#what-we-look-for-in-technical-customer-success-managers) - [How do you spot these traits in resumes?](#how-do-you-spot-these-traits-in-resumes) - [What do great TCSM candidates look like in interviews?](#what-do-great-tcsm-candidates-look-like-in-interviews) - [How can I tell if I’d be a good (or bad) fit?](#how-can-i-tell-if-id-be-a-good-or-bad-fit) - [What’s changed about hiring TCSMs?](#whats-changed-about-hiring-tcsms) - [Júlia Esteban Edo](https://posthog.com/community/profiles/33236.md) Oct 26, 2026 - [Culture](https://posthog.com/blog/culture.md) Over the last two quarters, 4,345 people applied to our [Technical Customer Success Manager](https://posthog.com/careers/technical-customer-success-manager-americas.md) roles (Americas + [EMEA](https://posthog.com/careers/technical-customer-success-manager-emea.md)). We reached out to 1,702 more (thanks to our Sourcing Queen [Ellie](https://www.linkedin.com/in/eliana-brereton-18495a205/)). This led to: - 479 first calls - 187 technical interviews - 83 culture and motivation interviews - 41 [superdays](https://posthog.com/handbook/people/hiring-process.md#4-posthog-superday) - 12 offers So roughly 1 in 500 people who we heard from or reached out to got an offer. For comparison, roughly 1 in 136 Product Engineer candidates we considered got an offer. Don't let this discourage you from applying. There's no AI automation rejecting these people. We review every application and send every message manually. It's not because we sadistically like rejecting people either. To prove this, here's all the secrets of what I, a talent partner, look for in technical customer success managers and what the candidates that succeed do differently. ## What we look for in technical customer success managers On paper, our customer success team have almost nothing in common. For example: - [Dana](https://www.linkedin.com/in/dana-zou/) went to med school and then fell into program management - [Jake](https://www.linkedin.com/in/jakesciotto) did CS at school and then a bunch of implementation work - [Seb](https://www.linkedin.com/in/murielsebastian/) studied media - and actually did something related to his degree for a while - before getting into a strategy role at a startup. They're quite different profiles, but their similarities are revealed when you talk to them. They share similar traits which helps them succeed at their job. TCSMs at PostHog build relationships with customers by building trust. Trust is built by being honest, fast, helpful, capable, reliable, and a builder ([Jake says it's handsomeness and charm](https://posthog.com/blog/bribing-customers-to-talk-to-me.md), but I'm skeptical of that). Combine these traits with being technical (not just "knowing some Python") and you have a TCSM. When we interview, we care that you have those traits, are technical, and that you're genuinely into the role and PostHog. Basically, we're looking for candidates to show us these things each step of the process. ## How do you spot these traits in resumes? Job titles don’t tell me much. So instead, I look for things like: - **Hybrid backgrounds**. Sales + technical success, implementation + account work, engineering + sales, engineering/customer + a side gig that covers the other half. Even if your title was only one thing, I’m looking for evidence you’ve done a bit of both. - **Things you built**. “Implemented better onboarding for new team members”, “Slack channel summarization bot”, “Product enablement quiz bot”. If you’ve built stuff nobody asked for which solves real problems, add it to your CV! - **What changed for the customer/user, not just what you did**. “Cut onboarding time in half” tells me way more than “managed onboarding for 40 accounts”. It also tells me that you’re outcome-oriented. - **A short, honest tech list**. The tools you’re actually comfy with and relevant to the role, not every logo you’ve ever seen. - **Clean and to the point**. If your CV is concise and easy to read, I already have the feeling you’ll be easy to understand on a customer call and that you have a good instinct for what’s valuable. ## What do great TCSM candidates look like in interviews? - They follow my prompts (heh). They don’t just drop their prepped monologue. They actually listen and understand what I need from this call; they adapt, and they deliver. They can have a human-to-human conversation. - They show confidence in themselves and their story, while being humble - they can talk about their past decisions without being attached to the outcomes. - They’re honest and genuine! They don’t perform or try to fulfill some assumed expectations - they’re just themselves (and yeah, this is easy to say and hard to do when you really want something, but I promise it’s worth it) - They show a high level of introspection and agency. They can reflect on their past experiences and walk me through how they have consciously chosen roles that aligned with what they value at work to the best they could (and can honestly admit when a choice was wrong and why). - They can find this sweet balance of detail and speed. They are naturally good communicators; when you just let them talk, they’re aware of what amount of detail is valuable and what’s just a tangent. So coming back to Dana, Jake, and Seb: quite different on paper, but they all did all five of these on our first call and their CVs followed the patterns above. ## How can I tell if I’d be a good (or bad) fit? I went back through feedback for everyone who made it to offer stage for these roles. Rather than tell you who’d be great, here’s who probably wouldn’t love it here: 1. “I’ll raise a ticket.” If your instinct when something breaks is to hand it off, this might be painful. Our TCSMs start digging. [One of them](https://posthog.com/blog/customer-success-at-posthog.md#1200-pm-accidentally-shipping-product) even opened a PR that got merged within 24 hours. 2. “Ugh, docs.” You don’t need to be an engineer. But if walking a customer’s engineers through weird experiment results doesn’t sound at least a little fun, you’ll be miserable quick. 3. “Where’s the playbook?” We write a loooot down. But there’s still plenty to write (and build: the team made their own quoting tool because the old way was meh). You might be the one figuring that out! 4. “The call went great!” Cool, but did the customer actually set it up? Are they using it? That’s what matters. No QBR decks nobody reads. 5. “Wait, you want me to lower their bill?” Yep. If a customer is paying for stuff they don’t need, we [help them cut it](https://posthog.com/blog/customer-success-at-posthog.md#900-am-the-part-where-we-try-to-reduce-a-customers-bill). One customer cut ~20%, then ended up re-signing at roughly double. Long game > quick win. 6. “Honestly, I just want to code.” Totally fair! That’s a different role, though. 7. “What’s my lane?” Your job in six months will probably look different from today. Some people find that stressful. We’d be bored if we knew exactly what the next six months will look like. Everything about how we interview is [in the handbook](https://posthog.com/handbook/people/hiring-process/sales-cs-hiring.md#customer-success-hiring-process). Other than that, make sure to try PostHog and just show up as yourself. ## What’s changed about hiring TCSMs? When we first started hiring for this role, we leaned towards people who’d owned a book of business before. But as the team’s grown, we’ve realized it’s easier to teach someone renewals and account planning than it is to [teach them to be technical](https://posthog.com/blog/how-to-become-a-technical-csm.md), curious, and a builder. You can’t really teach someone to be curious, sadly. Working in public helps a lot here too. How we run onboarding, handle renewals, or think about expansion… It’s all in our [handbook](https://posthog.com/handbook/customer-success/customer-success.md). So we’ve opened the door to a lot more backgrounds (like [engineers who want to sell](https://posthog.com/blog/being-in-a-sales-role-has-made-me-a-better-software-engineer.md)), which is a big part of why this has become probably the trickiest role I’ve worked on. [We’re hiring](https://posthog.com/careers.md), of course. > PostHog is your product's context layer. With a full suite of developer tools – [AI observability](https://posthog.com/ai-observability.md), [product analytics](https://posthog.com/product-analytics.md), [session replay](https://posthog.com/session-replay.md), [feature flags](https://posthog.com/feature-flags.md), [experiments](https://posthog.com/experiments.md), [error tracking](https://posthog.com/error-tracking.md), [logs](https://posthog.com/logs.md), and more – PostHog ingests and stores all the data agents need to diagnose problems, uncover opportunities, and ship fixes. A [data warehouse](https://posthog.com/context-warehouse.md) and [CDP](https://posthog.com/cdp.md) tie it all together, unifying that context into one source agents can read across. You can steer it all from [Slack](https://posthog.com/slack.md), [the web app](https://posthog.com/ai.md), the desktop ([PostHog Desktop](https://posthog.com/desktop.md)), or your own editor via [the MCP](https://posthog.com/mcp.md).