alt.hn

2/6/2026 at 4:45:47 PM

I spent 5 years in DevOps – Solutions engineering gave me what I was missing

 https://infisical.com/blog/devops-to-solutions-engineering

by vmatsiiako

2/7/2026 at 9:15:35 AM

Solution Engineering is a highly sought after role in startups and growth companies. It is an important role in established enterprises too but it won't be seen as an IP role. It is a great escape career path for engineers from pay scale change perspective. The author didn't touch upon that part but there was certainly a big salary increase.

by chopete3

2/6/2026 at 8:51:30 PM

My path went from engineering-aligned (math) to engineering management back to engineering to product to program management to solutions engineering to account executive.

Honestly I had a negative connotation about sales for most of my career, but turns out I really love it. The exposure to different problems every day is awesome and more like a puzzle than work to me. I feel a bit of reverse imposter syndrome though, like I should feel bad that I didn't "make it" as a real engineer. So that's a weird feeling.

One thing I try to do in my company is pull engineers into sales calls and proofs-of-concepts if I can. I think that exposure to both real users and unique environments is important for their growth and novelty in the job.

by ikjasdlk2234

2/6/2026 at 9:43:01 PM

Sales is amazing but if your companies sales people require engineering to build POCs a lot of the times or always have to sell some custom solutions, then it wastes a lot of resources and it usually indicates the company is losing product market fit.

by falloutx

2/6/2026 at 9:51:27 PM

That is true. My current work is in bespoke environments with mainly non-technical buyers who have been burned in the past. Our POCs are pretty minor lifts to build credibility and have worked extremely well.

If you're working in SaaS or commodity products and have to run POCs a lot, you're totally correct.

by ikjasdlk2234

2/7/2026 at 5:46:38 AM

Your company is selling the 'valet service' more than the products.

There are people willing to pay for convenience AND security at the same time (hire someone else to manage the problem, and they're the 'key').

by mjevans

2/6/2026 at 10:35:25 PM

I love hearing this.

My story: mostly business analytics (2005-2022), sales engineering, sales (both at same tech start up), and now running a solo consulting business.

I also really liked sales. Updating a CRM, not so much. But sales allowed me to spend my day talking with people about problems. No day the same, and lots of focus on finding different/better ways to communicate.

In what industries did these roles happen? Same industry/domain or have you changed that as well?

by grvdrm

2/6/2026 at 11:53:49 PM

Domain is all government, but the tech is different across each of them.

I love talking too, part of why I think pre-sales is a lot of fun. And I actually love my CRM work from a data perspective, but my background is in synthesizing data and optimization. Once I turned my sales process into a network optimizing problem, it became extremely interesting to me and imperative to keep the data current.

by ikjasdlk2234

2/7/2026 at 1:06:14 AM

Fair point. I too like the data side of CRM. So many interesting possibilities.

Did you always enjoy talking or did you discover it at some point prior to your current sales role?

by grvdrm

2/7/2026 at 5:53:56 AM

Would you be willing to tell me more about your path to account executive and sales? I am considering such a path myself and it would be wonderful to talk with someone whose done this.

by robertcarter

2/7/2026 at 7:49:55 AM

I hope you like being on call and having to tell management why you're not hitting your number and "forecasting" your way to close the gap.

I also hope you like golf! And drinking!

There can be UNREAL amounts of drinking as an AE.

You'll also be on a plane A LOT. The folks in suits and sneakers waiting first in line to board with their roller bags? Almost all of them are AEs.

Most of your customers will see you as a walking credit card.

You can also make 6+-figure commission checks and deep friendships if the deals are right, so there's that.

by nunez

2/6/2026 at 9:08:05 PM

Can you share one such puzzle?

by esafak

2/6/2026 at 9:42:51 PM

I am a solution engineer mostly on the traditional ML side of things but have good knowledge of K8S/GKE. The most fun I had last year was helping a customer serve their models at scale. They thought it was cost prohibitive (500k inferences/second and a hard requirement of 7ms at p99) and so they were basically serving from a cache which was lossy (the combinatorial explosion of features made it so that to have full coverage you needed exabytes of ram) and was stale prone. We focused on the serving first. After their data scientists trained a New pytorch model (small one, 50k parameters more or less) we compiled to onnx (as the model is small and CPU inference is actually faster), grafted the preprocessing layers to the model so that you never leave the ONNX C++ runtime (to avoid python), and deployed it to GKE. A 8 core node using AMD genoa cpus managed to get 25k/inferences per second. After a bit of fiddling with Numa affinity, GKE DNS replication, Triton LRU caches and few other things we managed to hit 30k inferences per second. If you scale up to the traffic it would cost them few thousands per month, which is less than their original cache approach.

Now they are working on continuous learning so that they can roll out new model (it is a very adversarial line of business and the models get stale in O(hours)). For that part I only helped them design the thing, no hands on. It was a super fun engagement TBH

by marcyb5st

2/7/2026 at 1:41:45 AM

Are they paying you as well as your comment makes it sound? That was a ton of lingo and I'm used to lingo!

by Apofis

2/7/2026 at 8:12:38 AM

Yeah :) happy on the money front. I didn't mention this earlier, but I'm a Googler and my role is to make sure that big customers are as happy as possible on GCP. And Google still pays well (talking with my SWE friends my total comp lands around the middle of the pack, perhaps a bit fewer stock grants). I was a SWE (also at Google) before, so maybe they didn't change my comp too much in the new job family. I don't know as those things are mysterious.

Also, not all projects are this fun. Sometimes is solving the same problem over and over or working with customers that aren't tech savvy and there is a bunch of politicking and "fluffy" stuff.

by marcyb5st

2/7/2026 at 7:25:55 AM

My path was opposite...

Started in early 200x sysadmining Linux boxes. Moved to an MS gold partner that started with 6 employees and ended up with 45 by the time I left. So you can imagine the kind of work and solutions we did, started with mom and pop, ended up doing email systems for a 20k user system, also picked up vmware/sphere, perl scripting a big monitoring system for over a year and hacking old binary only legacy software to extract data, lots of extremely varied short term projects.

Then got onto the "Solutions Architect" career path. Did that for 6 years ending up in a big telco. I ended up being bored out of my mind just doing designs/tech sales/delegating all the "real work".

I decided to go into Devops and switch to contracting at the same time. I now realise that was over 10 years ago now.

I couldn't be happier with my job since then. It's 100% remote, It's hands on troubleshooting when things go horribly wrong, it's solving hard problems with automation and in last 2 years lots of AI when the clients decide to rip out a huge amount of integration and switch clouds/other software and so on every 2 years :-)

It pays a little less and definitely has less prestige than "Solutions" for a huge telco (and I no longer wear a suit at work), but I can definitely see myself being happy doing that for next 10 years (if the role still exists then).

by Roark66

2/7/2026 at 5:25:41 AM

> answer the same support questions. Repeat.

This is not devops, this is someone managing yaml to allow an org to avoid doing devops.

Devops is practiced by everyone. If there are people asking the same questions over and over there is a feedback loop / education / automation problem and THAT is the part that makes a job devops.

by zingar

2/6/2026 at 11:44:22 PM

The part about interacting with people really resonates with me. I went from a support and repair position to a SWE role. It should have been great. But I burned out really quickly because the contributions I was making were going off into a void (from my perspective). I didn't see our customers engaging with what we built so I had almost zero job satisfaction.

I moved into another support role sort of by accident when I really wanted a sysadmin job but didn't have the years of experience needed to get through the door. I found out (again, by accident) that engaging with our customers directly gave me the feedback and sense of accomplishment that I was missing. I now know that it's an essential component for me. I'm much happier having figured that out.

by alsetmusic

2/7/2026 at 1:20:54 AM

Can relate a lot. I started off as a SWE but am pursuing a support role for similar reasons.

by meken

2/7/2026 at 5:28:32 AM

> Part of it was repetition. My days had become predictable: check the dashboards, respond to tickets, debug whatever broke overnight, push some Terraform, go home. Maintain the HashiCorp Vault clusters, manage the secrets pipelines, answer the same support questions. Repeat. The work that used to feel engaging had become routine.

This isn’t “DevOps”. This is “IT Support”.

But honestly, if you aren’t embedded into a team where developers and infrastructure folks are working together - you aren’t doing anything differently than old school operations people did 25 years ago

by raw_anon_1111

2/6/2026 at 9:04:51 PM

I really loathe that sales engineers stole the term Solutions Engineer which was previously used to basically mean support/services engineer (technical generalist), a mostly post-sales role. It's pedantic, but I watched it happen in real time, my company's HR even asked if we could change our team titles to help out the sales team since they wanted the more appealing title to use.

The reason it annoys me so much is that it makes it harder to find post-sales technical generalists as the top of the funnel ends up filled with pre-sales people.

Congrats to OP for finding something they like though!

by codezero

2/7/2026 at 4:43:47 AM

In my experience, it just entirely depends on the company. Different companies will use the same title and they can have wildly different mixtures of pre vs post sales involvement. My career has all been customer/client facing technical roles. Titles range from:

- support engineer

- solutions engineer

- sales engineer

- applied engineer

- forward deployed engineer

- solutions / sales architect

- field engineer

And that's leaving out titles that avoid calling someone an engineer who is still entirely technical, has to code, has to deploy, etc. but deals with clients.

I will say though that roles that want pre-sales focused engineers typically are pretty picky about people who have the sales-facing experience. So it shouldn't be too hard to avoid those roles if you're wanting a role focused almost entirely on post-sales.

(I say that, but I do know that if a company lacks pre-sales dedicated engs then other engs definitely can get roped into it. I know a guy with a PhD in ChemEng that basically is the director of research at his company and has had to wear a "sales eng" hat quite a bit in his role.)

by cootsnuck

2/7/2026 at 5:33:50 AM

Top of the funnel should be pre-sales. Our sales folks are usually juggling eight or nine opportunities, trying to get contracts signed, in our case working with AWS to help get funding, flying to customers sites, etc.

I am post sales, billable staff consultant who leads projects. I’m “delivery”. I focus on one project at a time and dig deep into requirements and the implementation and/or strategy docs.

by raw_anon_1111

2/7/2026 at 7:15:24 AM

Agreed - its total sales engineering as he described it.

by bigtones

2/7/2026 at 2:08:41 AM

Use " Solutions architect " maybe instead ?

by Melatonic

2/7/2026 at 4:19:52 AM

That title has long been used as a post sales analyst (custom work for $)

by codezero

2/7/2026 at 5:36:14 AM

At AWS at least, an SA is free for a client and ci e them advice - not allowed to give a customer code.

ProServe consultants (full time employees) are never called SAs

by raw_anon_1111

2/7/2026 at 1:25:56 AM

> But for me, it was missing something I didn't know how to name until I found it: the chance to be technical and connected.

I genuinely throught this was impossible for a very long time. In my SWE roles I’ve mostly felt disconnected and isolated.

I resigned from my last dev job and started working in donut and coffee shops. I loved it.

I’m pursuing Support Engineer roles now hoping it will provide the human focus that was missing prior.

by meken

2/6/2026 at 9:24:54 PM

Wow, I think I’d love this job. Nothing more interesting than learning about lots of different unique problems from different industries. And totally get the fear of losing technical edge

by maxaw

2/6/2026 at 11:51:21 PM

Word of warning: at some companies “solutions engineer” just means “demo monkey.” The sales people don’t really know how the product works or how to use it, so you are brought in to do the demo and answer questions and that’s about it (and you’re compensated much less well than the sales people).

by mikeocool

2/6/2026 at 9:22:42 PM

It's always nice when the customer wants to improve the process/product, it can overcome internal friction that had prevented making things better.

by axus

2/6/2026 at 9:54:12 PM

I'd still classify what they're doing as DevOps type of work. It just happens to be a wider spectrum of things vs their usual "write YAML" in that 1 role. Sounds like the original poster found a more enjoyable role with the same title?

I do a ton of different things every day and have been for the last ~10 years, all in the neighborhood of DevOps'ish type of tasks. I've written about 120+ of those tasks at https://nickjanetakis.com/blog/120-skills-i-use-in-an-sre-pl.... I do agree, it is fun to mix it up in your day to day (IMO).

by nickjj

2/7/2026 at 1:33:54 AM

> I'd still classify what they're doing as DevOps type of work.

This is very, very wrong. Why do you think that?

by antonvs

2/7/2026 at 4:29:54 AM

devops means a lot of different things to different people

by jeron

2/7/2026 at 5:37:51 AM

If you are a “DevOps engineer” - how is what you are doing any different from operations folk 25 years ago if you aren’t working with developers and embedded into their teams?

by raw_anon_1111

2/7/2026 at 8:12:54 AM

Why are you assuming that devops engineers aren’t embedded in development teams?

The problem you’re suffering from is assuming that the limited range of situations you’re familiar with is the same as what everyone else is doing.

by antonvs

2/6/2026 at 11:37:35 PM

Nope. Devops != any sort of pre-sales/post-sales/solution engineering.

It requires a more holistic, generalist view, and a degree of customer understanding, empathy, management and conversational skills well beyond typical devops.

by bobanrocky

2/6/2026 at 9:27:10 PM

Best job in the world.

by lateral_cloud

2/7/2026 at 2:39:11 AM

1000%. When the sale doesn't go through, it's the salesperson's fault. When the product doesn't work, it's the "real" engineer's fault. When everything works, the client gives you a high five.

If you don't know the answer, you can ask one of the "real" engineers.

As long as you show up with a smile on your face and the demo kinda works during the call, you're 10/10.

At FAANG companies, you generally get paid at a level above your technical role; for example, if you have a mid-level engineer's coding ability but can also talk to customers, you'll generally be paid a senior engineer's salary.

Some days, I don't understand why everyone doesn't want this job. But then I'll talk to the product engineers on my team, and they'll thank me for talking to the customers so they can focus on coding. I think it's really a personality/preference thing.

by jameshush

2/7/2026 at 4:49:27 AM

Yup, it is. It's my bread and butter too. So much so I decided to just do it for myself and start my own consulting company.

Being a solutions engineer at the right companies means you get to be one of the few people with full end-to-end visibility of the entire lifecycle of both a client and the technology adoption, deployment, optimization, maintenance, etc. process. And you'll get to see it dozens or hundreds of times for a variety of clients across industries. Again though, totally depends on the company.

by cootsnuck

2/7/2026 at 7:16:44 AM

Yes... and also it pays pretty damn well if your company sales team is winning. Incentives are aligned.

by bigtones

2/6/2026 at 9:29:37 PM

My experience in a “product company” - Pre-sales solutions engineer - the original problem solver. Professional services - post-sales firefighter :)

by pisipisipisi

2/6/2026 at 9:41:29 PM

Inspiring article. Well written. Totally feeling it!

by korijn

2/7/2026 at 6:09:20 AM

> I started dreading the monotony of it all... My days had become predictable: check the dashboards, respond to tickets, debug whatever broke overnight, push some Terraform, go home. Maintain the HashiCorp Vault clusters, manage the secrets pipelines, answer the same support questions. Repeat. The work that used to feel engaging had become routine.

Why are you checking dashboards (pull/polling) instead of building alerting (push), so that you do not need to check dashboards as a matter of routine? If the tickets are dealing with the same problem again and again, why aren't you building a self-service platform to let your users handle these problems by themselves (especially now that LLMs are making this much more trivial to build)?

Author sounds like he had poor technical management who didn't understand DevOps (let alone DevSecOps) and turned it into an operations role.

Everything that the author likes about Solutions Engineering, I get from a DevOps role, from collaborating with other engineers in my company to make them more agile, productive, and take better ownership in production. Too many engineering teams fall into a trap of not being allowed to focus on any non-functional work (gotta ship revenue-generating features!) and LOVE it when someone like me comes along, who doesn't answer to Product, and can help them out on the non-functional side. I get to talk to "customers" as much as I want, in a role where I can just walk up to them and not need to communicate over Zoom or with significant plane travel.

Author should have considered trying to just find a different Platform Engineering role.

by solatic

2/7/2026 at 7:29:17 AM

I made the jump into SE (sales/solution engineering) three years ago after a long career as a SRE/systems/software engineer (the kind that found any excuse to break out ilspy, windbg, gdb and/or tcpdump on the job) and have a love-hate relationship with it.

This is a long post, but SEs are underrepresented here despite us being a big part of the sky high valuations that many companies on here have gotten, and it's a job that is still somehow not well known or understood.

I LOVE the travel. As someone whose happy place is seat 20F on a United 738 and a rental EV waiting on the other side, the random travel requests give me so much life. I enjoyed the 4 on, 3 off travel life as a consultant as well, but being asked to fly in for a meeting or two and get time to myself the day before is so much better. In fact, this is probably THE reason why I haven't gone back into the FTE world. Travel budgets for engineers are generally pithy.

I LOVE not having to answer to a Jira backlog. I can (and do) still ship PRs back to product if it makes sense for the customers I'm supporting, but my performance comp isn't tied to that. Interestingly enough, we are also not forced to use AI when coding for the same reason (though using it to understand what our customers are being increasingly asked to use is important, so I do sometimes).

Speaking of comp, I LOVE how transparent our comp packages are. The base salary is usually competitive with a high Senior/low Staff SWE, but unlike these roles, we don't get very many RSUs. What we do get is commission. The more we sell, the more we make. No black box bonus pool allocation nonsense. Some SEs can take in Staff+ total comp some years if they and their AE close a whale of a deal because of this. What's better about comp as an SE is that it's usually not regional. This makes the position super lucrative for engineers in LCOL/MCOL cities who don't mind getting on a plane every so often.

We also get a lot of time and space to tinker with the products we're selling when we're not out in the field (since we usually have to know them front to back; it's not uncommon for SEs to know more about a product than engineering or even Product). Most good SE managers will absolutely support you blocking off time to build, which is awesome!

Interviews are also WAY more than chill than those for SWE. No LC grinds. The hardest part is usually the tech panel (which is easy if you're good at presenting and explaining technical things in an accessible way).

So now onto the not so fun parts.

You are usually tied to a non-technical account executive (salesperson). The nature of that role attracts lots of...interesting people. Your entire existence as an SE hinges on how well you get along with your AE. A great relationship makes SE the best job in the world. Anything else makes it somewhere between a slog and hell on earth.

This is also a sales job at the end of the day. There's lots of talking and socializing involved. Not nearly as much as an AE, but doing happy hours and dinners sometimes comes with the job. As a massive introvert who often wants nothing more than to read Hacker News over a nice beer in sweet solitude at the end of an intense workday, you can probably imagine how draining these events can be.

Then there are the demos and POCs: the bread and butter of the role. Depending on where you are, you might be giving the same demo handfuls of times per day. These can be made more fun by working in investigative questions about the customer you're presenting to to learn more about them and why they need what you're selling (also called "discovery"), but some AEs won't give you that space. Feeling like your job is replaceable isn't great (even though it's not replaceable at all!)

There also isn't much upward mobility in this vertical. You can go a lot of places OUTSIDE the SE track given the cross-cutting nature of the job (Product, CTO, AE, and even back into engineering are common paths), but scope as an SE is narrower than the SWE path, as, again, its a sales job. (That said, getting into the Principal SE track usually involves talking at big shows and brand building like writing books, skills that are very useful if you want a heavy hitting job elsewhere or want to be the kind of person that gets paid to keynote conferences).

Many of the thought leaders in the SE space are technical but have lost their edge. Many of them are closer to sales than engineering. Some literally sell their presales methodologies and don't do technical stuff anymore. Great if you want to move away from that career; less so if you don't. More engineering-biased people might feel out of place initially.

Skill atrophy is also very real, counter to OPs observations. You can get away with minimal learning once you know what you're doing and have your demos locked in. It takes a while to get to this point, but once you're there, you can give a demo point blank a any time and are familiar enough with your product to lead a POC start to finish without blinking. This combined with not having time to "deep" learn due to meetings, demos and POCs can lead to skills slipping away.

Finally, that time to tinker can be hard to get if you're in a patch of heavy sales activity. This is felt the hardest when you join a new org and are sent into the field straightaway. This is often why so many SEs are usually former consultants of that product or ex-customers: shorter ramp-up time.

This can make it difficult to get back into a pure engineering role if SE doesn't work out. You won't have enough day to day experience to make hiring managers feel comfortable in bringing you on, which is a massive disadvantage in this market.

All in all, it's an awesome and somewhat safe career path that is a front row seat to how the money comes in, but it's heavily situational and probably not a fit for more introverted folks.

by nunez

2/6/2026 at 10:04:15 PM

I am a software developer. I went to college to learn software development. Two years ago, they tried to tack DevOps on to my job description. I told them "no thanks", then had to find another job. I found one and am MUCH happier not having to do that DevOps crap. No offense, but it a soul-draining undertaking, and I like writing code ... ONLY!

by NoSalt

2/6/2026 at 11:19:50 PM

I have a different opinion. :) DevOps is great feedback to the engineering team.

Too many alarms or alarms at unsocial hours? The engineering team should feel that pain.

Too hard to push? The engineering team should feel that pain.

Strange hard to diagnose alarms? Yep, the engineering team should feel that pain!

The feedback is very important to keeping the opex costs under control.

However, I think the author and I have different opinions on what DevOps is. DevOps isn't a full time role. It's what the engineer does to get their software into production.

by jpollock

2/6/2026 at 11:32:24 PM

The only folks who like devops are those that haven’t touched anything else, or are scared to move out of that molehill. Try it once .. is my advice

by bobanrocky

2/7/2026 at 12:14:49 AM

I think there are different definitions of DevOps.

I see a difference between a more definite operations team (SRE) vs an engineering team having responsibility for how their service works in production (DevOps).

DevOps is something that all teams should be doing - there's no point in writing code that spends it's life generating problems for customers or other teams, and having the problems arrive at the owners results in them being properly prioritized.

In smaller orgs, DevOps and SRE might be together, but it should still be a rotation instead of a fulltime role, and everyone should be doing it.

Engineers who don't do devops write code that looks like:

  if (should_never_happen) {
    log.error("owner=wombat@example.com it happened again");
  }
Where the one who does do devops writes code that avoids the error condition entirely (usually possible), or decides what the code should do in that situation (not log).

by jpollock

2/7/2026 at 1:02:00 AM

> The only folks who like devops are those that haven’t touched anything else, or are scared to move out of that molehill.

IDK I've been called everything from: SysOp, SysAdmin, Network Engineer, Systems Architect, Solutions Engineer, Sales Engineer, Platform Engineer, etc. Half of those at different companies are just "DevOps" depending on the org.

by esseph

2/7/2026 at 1:35:46 AM

This sounds very adversarial to me. I’m glad our devops team doesn’t think like you.

by antonvs

2/7/2026 at 1:44:10 AM

In my career, DevOps was never a separate organization. It was a role assumed by the code owners. SRE (is it up, is the hardware working, is the network working?) was separate, and had different metrics.

Having separate teams makes it adversarial because both orgs end up reporting into separate hierarchies with independent goals.

Think about the metrics each team is measured on. Who resolves conflicts between them? How high up the org chart is it necessary to go to resolve the conflict? Can one team make different tradeoffs on code quality vs speed from another, or is it company-wide?

by jpollock

2/7/2026 at 5:43:27 AM

If you have a “DevOps team” - they are operations and you aren’t getting any of the benefits of a DevOps mindset

by raw_anon_1111

2/7/2026 at 5:56:34 AM

Meh, real life is a bit more complicated than a manifesto.

by antonvs

2/7/2026 at 6:10:30 AM

It’s not about just a manifesto, at the startup I worked for before getting into consulting 6 years ago - cloud + app dev - it was much more affective for the team who did the work, to create their own IAC based on a standard.

What’s the difference between a “DevOps team” in 2026 than “operations” in 2001?

by raw_anon_1111

2/7/2026 at 8:10:25 AM

The difference is what they do. Assisting other teams with creating fully automated build and test pipelines. Managing infrastructure using automated systems. Identifying issues in production systems that other teams should look at, down to a level of granularity that wasn’t really possible in 2001.

> affective

You mean “effective”.

by antonvs

2/7/2026 at 5:41:55 AM

I am first and foremost still a software developer as far as my hands on keyboard job. I absolutely love being able to set up my own infrastructure without depending on glorified system administrators who call themselves “DevOps Engineers”. It’s all just code at the end of the day - setting up infrastructure involves writing yaml, HCL or actual code (CDk).

by raw_anon_1111

2/7/2026 at 2:46:56 AM

Same thing happened to me at a company several years ago. It felt like they wanted me in two roles but were only paying me for one. Didn't take long for me to jump ship after that.

by booleandilemma

2/6/2026 at 11:34:59 PM

DevOps is secretly spiral development.

Great if billing by the hour, and mostly unsustainable for products =3

by Joel_Mckay

2/7/2026 at 8:28:53 AM

[dead]

by gogasca