The job description said "Customer Support Representative." For a while, that's what I did — picked up tickets, answered questions, hit metrics, closed them out. It was honest work and I'm not knocking it.
About a year in, I noticed something. A handful of the people on my team weren't really doing that job anymore. They were getting pulled into the messy, ambiguous, cross-functional tickets — the ones that had stalled for weeks somewhere else. They were building little workflows for clients in the platform's custom-code editor. They were the people the Account Managers tagged when an onboarding got stuck. They were closing fewer tickets per week but the things they touched looked completely different on the way out than on the way in.
If "support" is one end of a spectrum, those folks were drifting toward the other end. Solutions engineering. The line is fuzzy, but the difference is real.
The difference in one sentence
A troubleshooter answers the question. A solutions engineer removes the question.
That's the whole thing. Once you see it, you can't unsee it.
If a customer keeps hitting a wall, the troubleshooter helps them get over the wall, every time, ticket after ticket. The solutions engineer asks why the wall is there, designs a workaround that means the wall stops mattering, and ships it. Sometimes the workaround is a custom workflow. Sometimes it's a script. Sometimes it's a process change. Sometimes it's a quiet conversation with the product team that gets the wall removed in the next release.
What changes
This is what's different in the day-to-day, in my experience:
You stop optimizing for tickets-per-week.
Your metric stops being "how many tickets did I close." It starts being "how much risk did I remove from my book of business." Those are different numbers and they reward different behavior. The first one rewards speed. The second one rewards depth.
You start writing things.
Not just replies. Workflows. Snippets. Internal docs. Runbooks. Loom videos. Templates. You start leaving artifacts behind that make the next ticket easier — for you, for your teammates, for the customer. The leverage compounds.
You stop being the bottleneck.
The troubleshooter is, by design, a bottleneck. Every ticket has to come through them. The solutions engineer's goal is to not be the bottleneck — to push the answer earlier in the pipeline, into a doc, into a workflow, into a script the customer can run themselves. If you're still the bottleneck after a year, you haven't made the shift.
The clients start tagging you on things you don't own.
This is the easiest signal. When the Premium Support channels of clients you're not assigned to start tagging you in, asking you to weigh in — that's the market telling you the shift is happening. They're not tagging you because you close tickets fast. They're tagging you because you reliably arrive at the actual answer.
The skill stack
Here's what changed for me, in roughly the order it changed:
- Become a real user of the product. Not a trained employee. A user. Sign up. Build something with it. Hit the limits. Find the bugs. The vocabulary you pick up doing this is the difference between sounding like a script and sounding like a peer.
- Learn enough JavaScript and CSS to be dangerous. You don't have to be a software engineer. You have to be the person who, when a client says "we need this widget to do this thing and the platform doesn't support it," can say "I'll have a snippet for you tomorrow."
- Learn one API well. Doesn't matter which one — the platform you work on most. Be able to call endpoints, write basic requests, understand authentication, debug a webhook. This unlocks more solutions per quarter than anything else.
- Learn the affiliate side of the business. Or the partner side, or the integrations side. Wherever the non-obvious value flows. The territory where most CS people don't go.
- Start running QBRs and pre-sales technical calls. When you can credibly sit in a room with a prospect and walk through "here's how we'd build what you need on the platform," you've crossed over.
You don't need all of these on day one. You need to be moving in this direction.
The mindset shift
The harder part of this transition is psychological. A few things to actively unlearn:
"It's not my account."
The phrase has its place — boundaries are real, ownership is real. But the version that does damage is the version that uses it as an exit. The solutions engineer's instinct is the opposite: if I can move this forward, I will, and we'll figure out attribution later. Done right, this builds trust across the organization. Done wrong, you burn out. Pick the right side carefully.
"That's a product issue."
Yes, and you can still do something about it. Workaround. Runbook. Quiet escalation to the right PM with a specific business case. "That's a product issue" is the troubleshooter's exit. The solutions engineer treats it as the entry to a different kind of conversation.
"I don't know how to do that yet."
Best one of all. The honest version of this sentence ends with "yet." The unhelpful version ends with "so I can't help." There's a year of growth between the two.
What to do this week
If you're a support person reading this and you want to start moving:
- Pick one recurring ticket type that lands in your queue. Write the workflow, snippet, or doc that means you don't have to answer it again.
- Pick one client in your book that you have a good relationship with. Ask them: "what's the thing that bugs you about working with our product that you've stopped flagging because no one's been able to help?" Then try to help.
- Block one hour a week to learn one technical thing about the platform you didn't know last week. API endpoint. Workflow primitive. Custom-code pattern. Compounds fast.
A year from now, if your job feels noticeably different than it does today — different tickets, different conversations, different people asking for your help — you've made the shift. If your job feels the same, you haven't.
One last thing
None of this happens in a vacuum. The reason I was able to make this shift is that I had a management team that gave me the time and trust to learn the product properly, to experiment, to fail in a couple of places before figuring out what worked. If you're a manager reading this — that's the gift. Give your sharper folks runway. Don't fill every hour with tickets. The version of them on the other side of that quarter is worth more to you than the tickets they would have closed.
And if you're an early-career support person reading this and your management isn't giving you that runway: take it anyway. Pick the project. Build the thing. Ship the workflow. Show, don't ask. It tends to work out.
If you're trying to make this kind of shift and want to talk through what to learn first or how to structure your week, drop me a line. Happy to compare notes.