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 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 could best be described as engineering solutions: translating fuzzy business goals into measurable outcomes and architecting the path to get there.

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

To do what I do you need to spend a lot of time in rooms and meetings with stakeholders. Much of the time these stakeholders are a lot more important than you. They have impressive titles like “Director of Engineering” and “VP of Software Development.” You have to listen to what they want, determine what they actually need (which is often not what they think they need), identify the problem they’re actually trying to solve, the bottleneck or pain point they’re facing, translate their vague definitions of success into something identifiable and measurable, and then design a solution that solves that problem. You have to know when to say no, when something is a bad idea, and be comfortable 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 but actually won’t solve their problem, or will work in the short term but cause a mountain of tech debt later. I actually find it’s best to really narrow down the problem and what the solution looks like before you even begin to talk technical details.

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

Then, once you’ve designed the MVP of that solution (you should never assume you have the perfect design up front, it should always be an iterative process), you go and implement that solution. Which is the easy half and, let’s be honest, something that you probably don’t need to be an SME to do. Sure it helps, but more often than not any reasonably technically apt person can Google around, read documentation, play around in a test environment, and figure out how to implement whatever it is that you’ve designed.

I am REALLY good at that first half. And it’s not a thing that just anyone can do. It’s not a thing that you can watch some YouTube videos or read some docs and figure out. It’s the kind of thing that you can only be good at by having the right personality and just doing it a lot. 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(s) that 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 to me and told me the little startup he was working for was hiring smart bodies to be Atlassian Consultants.

Do I consider myself a salesperson? No. But it looks 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 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, 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!