I became a technical CSM with ZERO training. You can too.

I’m Ella, I’m a technical customer success manager (CSM) at PostHog. I’m not an engineer. I did seven years in sales before moving into customer success, and I've been in customer success for about four and a half years now.

I have no computer science degree, and before joining PostHog I'd never shipped production code that a real team depends on. So, if you think you've missed the boat on becoming technical because you didn't come via an engineering degree or background, you haven’t.

Becoming "technical" in sales, account management, or success doesn't require attending a course or a bootcamp. It requires habits.

When a customer asks something technical, try to answer it yourself before forwarding it to an engineer. This isn’t the norm in most customer success roles, because it’s riskier and takes longer, but it’s the habit that turned me into a genuinely technical CSM.

That’s the TL;DR, for the long version, keep reading.

1. Work on a technical product (in a non-technical role)

This was the most impactful move I made. If you're coming from a non-technical background, walking straight into a technical CS role is hard, especially from sales. This gives you a much better start towards a deeper technical understanding.

For me, the way in was data. My first CS role was helping customers with a semantic layer, and most of the teams we worked with had never heard of one, let alone built with one. I had to be able to explain it to our customers, first at a high level (why semantic layers are important) and then progressively in more depth as our customers became more familiar with this approach.

The buyers were also highly technical – i.e. data teams, engineering managers, frontend and backend teams were involved. When your main point of contact with a customer is an engineer, you have to learn how the technical pieces fit together if you want to have any credibility.

2. Join a lean team makes you figure it out

The other thing that made me technical was not having anyone to fall back on. We were a small team, so no free engineer was sitting around waiting for my questions. It was faster to investigate questions and issues for myself, which also meant I learned faster as well.

When you’re a small team, you naturally want to limit how many questions you’re firing to the engineers. They are a precious resource, so you want them to see you as a good partner for them, as well as your customers.

In my experience, when engineers see you’re trying to get a handle on the technical stuff and answer questions for yourself, they really like that and are much more likely to jump in when you do need them. They trust you’re coming to them having already made some headway on the issue.

If you're on a big team with plenty of engineering support, you have to create this constraint for yourself. Before you escalate something, ask whether you could just work it out. Even if you can’t solve the whole thing yourself, digging into it means you’ll actually understand the solution when you do get it, rather than just applying a fix you don’t understand.

3. AI makes this easier than ever

So, not an original hot take, but it's important to call out, because 1) it's true and 2) most people are doing it wrong. I'm vibe coding, not hand-writing React, but being willing to vibe code at all already puts you a few steps ahead of most people in this job.

The key is to make sure you’re building something you actually use: vibe coding a little page that solves one problem and then never touching it again won’t teach you much, and this is what most folks are using AI for today.

Instead, you should build something end to end that solves a real problem you have, and then use it day after day. In my previous role, I built our whole customer success platform myself, because we didn't want to buy a tool and I wanted something that fit the systems we already had.

What’s important about what you build is that when you’re using something regularly, it will definitely break. And when it does, you have to work out why, and that's when the real learning happens. My troubleshooting was Claude + curiosity + slowly learning where to look when things went wrong. It helped that I was already digging around in the browser console with customers day to day, so I had a feel for where things tend to break.

4. Become a jack of all trades, not a master

People assume technical CSM means you need to be a data whiz, have hand-coded an app in React, and understand distributed systems. You don't.

If you are a master in a particular area, that will absolutely help. Your fellow CSMs and customers will likely be very grateful for your expertise! But what the job actually needs is:

1. A solid base
2. The ability to adapt when a customer throws something unfamiliar at you
3. Enough curiosity to keep learning and to care what your customers are doing

Your job is to understand how the pieces fit together and be an expert on how they can get the most value from your platform (which, yes, if you're lucky and you work somewhere with high trust, can also mean shipping bug fixes and features to production).

If the above sounds like you – curious, stubborn about working things out, and excited about technical concepts – technical customer success might suit you. Oh and PostHog is hiring for this exact role right now. Wow, what a crazy coincidence.