What is a Solutions Engineer?

Nov 4, 2025

I’m job hunting for the first time in almost a decade, and I’m stuck on a surprisingly hard question: what job title should I actually search for? I’ve been a “Senior Atlassian Engineer” and a “Staff Application Engineer,” but the work I’m best at is architecting solutions. Translating fuzzy business goals into something measurable and implementable. Was that too buzzwordy?

Yes, I am an Atlassian SME. Yes, I know Jira and Confluence like the back of my hand. I know the tips and tricks, how to work around the quirks, and what apps are useful. All that. But that’s only half my job. The other half, arguably the harder half, is being a solutions architect.

To do what I do, you spend a lot of time in rooms and meetings with stakeholders who own important pieces of the business. They have titles like “Director of Engineering” and “VP of Software Development,” and they usually come in with a solution already in mind.

You have to listen to what they want, determine what they actually need, identify the problem they’re trying to solve, translate their vague definitions of success into something measurable, and then design a solution that solves that problem. And you have to know when to say no. Sometimes that means telling someone who might make several times your salary, and has the ear of the CEO, that what they want can’t be done, or could be done but won’t solve their problem, or will work in the short term but create a mountain of tech debt later.

This is obviously a parody but, like all good parodies, it’s not that far from the truth.

Then, once you’ve clearly defined the ask and designed the MVP of that solution, you hash out the technical details to implement it. That part still matters, and being an SME definitely helps. But the implementation is usually more straightforward once the workflow problem is actually understood.

The tool is just a container for the workflow. If the workflow is broken, no amount of JQL or fancy apps will fix it.

That first half is where I do my best work. It takes pattern recognition, patience, and a lot of reps. You have to notice when the stated request is not the real problem, when a workflow issue is being misdiagnosed as a tooling issue, and when a “simple Jira change” is about to create a mess six months later.

So that’s why I’ve always considered myself a Solutions Architect. I architect solutions. Most often with the Atlassian suite, sure, but again, that’s not the hard part. The skillset needed to be a good Solutions Architect is pretty universal regardless of the platform the solution will be implemented in. I can ramp up on the platform pretty quickly. I had literally never used Jira before a buddy reached out and told me the little startup he was working for was hiring people who could learn quickly and figure things out.

Do I consider myself a salesperson? Not really. But it seems like “Solutions Engineer” is most commonly a pre-sales role. I get the connection. It’s essentially the same process. You meet with stakeholders, identify their problems, design a solution for them to solve those problems, and the platform that you’re (hopefully) implementing it in is the software or service that your company offers. Regardless of whether the “customer” is a team within the company you work for or a team at another company you want to sell to, it’s the same skillset. Would I be good at it? I think so. But I do know that I would still focus on designing the best solution, not upselling or meeting some quota.

So am I a Solutions Engineer? A Solutions Architect? An Application Engineer? Atlassian SME? Does the title even matter? I’m not sure. Now that I am starting to seriously look around for my next role, talking to recruiters, and interviewing for positions, it’s a question I will be asking myself.

And hey, if your team needs someone to turn ambiguous goals into working systems, let’s talk.

Until next time!