Customer Success to Solutions Engineer: What 20 Job Postings Actually Say

By Tim O. | Published October 28, 2026 | Updated October 28, 2026

If you work in customer success at a software company, you have probably watched a solutions engineer run a demo and thought, "I could do that." You might be right. But the job postings tell a less comfortable story than most "CSM to SE" articles, and it is better to hear it now than after 40 applications.

I work on the post-sales side as a customer success engineer. Over the years I have also run technical demos, sat in discovery calls and supported solution evaluations. So I know which parts of customer success carry straight over and which parts feel nothing like it.

To check my experience against the market, I read and coded 20 open solutions engineer and sales engineer postings at 20 US software companies on October 28, 2026. You can download the dataset. Every number below comes from that sample.

The short answer

• Not one of the 20 postings named customer success as a qualifying background. Five (25%) accepted adjacent post-sales experience: technical account management or consulting.
• 16 of 20 (80%) listed prior SE, pre-sales or "similar customer-facing technical" experience in their requirements. That "or similar" is your opening, but you have to make your experience read as technical.
• The realistic route for most CSMs is internal or stepped: move into pre-sales at your current company, or go CSM to a technical post-sales role (TAM, CSE) to SE.
• The upside is real. Of the postings that disclosed pay, the median base range ran from $149,000 to $213,000 (5 postings).

What a solutions engineer actually does

A solutions engineer (also called a sales engineer or pre-sales engineer) is the technical half of a sales team. The account executive owns the relationship and the number. The SE owns the technical answer to one question: will this product solve this buyer's problem in their environment?

The postings agree on what that looks like:

Source: my count of 20 postings checked October 28, 2026. Full dataset.

Two things stand out. First, the core of the job is demos and technical evaluations, not slides: 19 of 20 postings mention running a proof of concept or evaluation. Second, certifications barely register. Only one posting named any (AWS, Salesforce or MEDDIC, listed as preferred examples). Employers want proof you can do the work, not a badge.

Minimum experience ranged from 1 to 12 years (median 5, where stated). The entry points exist: one security company was hiring a "Sales Engineer I" at 2+ years, and one data company at 1 to 3 years.

What transfers from customer success

These are skills you already use every week, even if your job title hides them.

You know how customers actually use the product. SEs who came up through sales often know the pitch better than the product. You know where it breaks, which integrations cause tickets, and what a healthy deployment looks like. That makes your demos more credible.

You already handle technical stakeholders. If you have walked an architect through a rollout or calmed down a director after an outage, you have done the hardest soft-skill part of the SE job.

You already tell value stories. QBRs and renewal decks are value storytelling with data. A good discovery-to-demo flow is the same story, told before the purchase instead of after.

You already work in a cross-functional triangle. CSM, support and product is not so different from AE, SE and product.

The first time I ran discovery with a prospect, instead of a customer, I was surprised by how little they volunteered. A customer describes the outage because they need it fixed. A prospect can give you one meeting and a vague pain, then wait. I had to ask what their environment actually looked like before I had a demo worth showing, and the questions I use in a QBR did not get me there.

What does not transfer (the real gap)

This is the part most "CSM to SE" articles skip, and it is why 80% of postings ask for pre-sales or similar experience.

1. Running technical evaluations. Nineteen of 20 postings mention proofs of concept or evaluations. A POC has success criteria, a deadline and often a competitor running the same test. You win or lose it. If you have never owned one, that is the first gap to close.

2. Building the demo, not just giving it. Many CSMs can deliver the standard demo. SEs build a demo around one buyer's environment, often in a sandbox they set up themselves. That is where APIs (55% of postings), cloud (50%) and scripting (40%) come in.

3. Discovery with a buyer who owes you nothing. In customer success, the customer already bought. In pre-sales, the buyer has no obligation to tell you anything, and the AE needs the technical reason to win from one call.

4. Working next to a number. SEs usually support a sales team's quota, and pay often includes variable compensation. Where postings disclosed on-target earnings (5 postings), the median range ran from $200,000 to $240,000. That upside comes with pipeline pressure customer success rarely feels.

Your 90-day plan

This is what I would do with a customer success background.

Days 1 to 30: get close to pre-sales.

• Ask your SE team if you can shadow two discovery calls and two demos. Write down the questions they ask, not the slides.
• Tell your manager you are interested in pre-sales. Internal moves skip the "prior SE experience" filter that 80% of external postings apply.
• Volunteer for any technical evaluation, expansion POC or competitive bake-off on your accounts. This is the experience the postings ask for.

Days 31 to 60: build the technical floor.

• Learn enough about APIs to automate one task you already do, such as pulling account data from your product's API.
• Learn one cloud platform well enough to draw your product's architecture on a whiteboard.
• If you prefer structured learning, the courses below cover exactly these skills.

Days 61 to 90: build evidence you can show.

• Build one demo environment for your product (or a public product in your space) that solves a specific buyer problem. Record a 10-minute walkthrough.
• Write up one technical evaluation you supported as a short case study: the requirement, what you tested, what happened. Remove anything confidential.
• Run a mock discovery call with a friend in sales and ask for blunt feedback.

When you interview, that recording and case study turn "similar customer-facing technical experience" from a stretch into a fact.

Is SE the end of the road?

For some people it's a stepping stone. Solutions engineering is a common route into solutions architecture and forward deployed engineering. If you want to go further, read the solutions architect roadmap and the forward deployed engineer guide. If you are deciding between staying technical inside customer success and moving to pre-sales, start with the technical customer success manager guide.

How I counted

I collected 20 open US solutions engineer and sales engineer postings from company career pages, mostly on Greenhouse, Lever and Ashby, on October 28, 2026. One posting per company: security (7), observability and developer tools (4), data and AI (4), and SaaS and AI apps (5). I excluded postings that turned out to be post-sales onboarding or support roles, and listings that had closed. I marked a skill as present only when the posting text said it.

Limits: 20 postings is a snapshot, not a census. The sample leans toward startups and scale-ups that use those platforms; large companies are under-represented. Pay figures come from only 5 postings each for base and on-target earnings. Postings are not hires. Download the CSV to check my work.

Some links in this article are affiliate links. If you buy through them, CareerPivoting earns a commission at no extra cost to you. I only link to courses that teach a skill the postings above actually ask for.