I spent 5 years in DevOps – Solutions engineering gave me what I was missing
infisical.comI realized a decade ago at 40 if I wanted to still stay relevant, make more money, not go into management and not still be trying to compete with 25 year olds based on how well I could reverse a b tree on the whiteboard, I had no choice but to get closer to “the business”.
I got a job in cloud consulting specializing in app dev - “application modernization” at AWS (mid level L5) in 2020. Took advantage of every opportunity to put myself in front of the customer virtually and physically.
Learned through osmosis how the senior consultants, engagement managers (project managers) and account managers operated.
Got Amazoned almost 4 years later and became a staff consultant at a 3rd party firm (equivalent to a senior at AWS or GCP) and while I lead “delivery” projects, I’m still learning how things work at the next higher level of the funnel - pre sales. The level of ambiguity is high by the time it gets to me. But at least sales has narrowed down what high level business outcomes the customer wants.
My thesis is the closer I get to both the revenue drivers and where people skills matter, the less ageism is a factor and experience is actually rewarded and the harder it is to be outsourced, commoditized or replaced with AI. I’ve been concerned about commoditization for over a decade and that definitely happened on the enterprise dev side
How would one go from devops or sre management to a customer facing pre sales role like you described?
I thought sales was a separate career path.
I relate 100 percent to your realization about competing with 25 year olds on Leetcode. I'm comfortable, but I realize finding a new job is harder than ever, even though I am as valuable as ever - they want me not only to have proven I can 10x a company managing infra and people (I did and have), but they expect me to spend my weekends coding, and not just coding but coding esoteric algorithms than no one uses outside of academia.
And meanwhile there's an enormous amount of messages here on HN about how managers are useless and mean.
It's a weird spot to be in, so I'm opting for trying to prepay mortgages as quickly as humanly possible before I'm unemployed forever and have to call it retirement (and which might have to take place in a cheaper foreign country).
I too am working on my out of the country back up plan. My wife and I are going to one of those countries for 5 weeks in a couple of weeks. We have already looked into residency requirements as a Plan B.
I am just starting to get a peek under the cover for sales. If I understand it correctly.
- “Someone” is hustling to make first contact with the customer or if you are a partner of one of the cloud providers, they send customers your way. I have no clue how this part works.
- The SA talks to the potential client enough to get high level business requirements to shape the contract. I’m not an SA. But there is a certain AWS speciality where I’m usually pulled in at this phase. We are trying to build expertise around this specialty. My former mentee is an SA at AWS so I know how they operate.
- After the contract is designed, I work with sales to understand the opportunity and I am the first person that does a deep requirement analysis - the business case is known, the technical requirements are ambiguous. I am responsible for getting the requirements and doing the design, talking to the technical guys, finance, security and the business folks to make sure their needs are met.
- then I lead the project, before AI, I would have needed a couple of people on the project. Now I can do it myself most of the time. It was never lack of knowledge, there are only so much I can do myself.
To your second question, the last 2016-2024 when I set on this path is a lot different than it is now.
I guess the best way is to work backwards from where you want to be to where you are.
1. How often do you know the business requirements in advance compared to how often are they given to you?
2. The money and the opportunities are in leading migrations. There are very few decent paying hands on keyboard “doers” those are easy to outsource. I lucked up that I got my job in a division that does care about “developers who know cloud and can lead implementations”
3. How are your project management skills? The ugly truth is PMs are useless when it comes to tech projects, you are the one that has to have the proper context to know dependencies, how to break things down, critical paths, etc.
4. Have you led implementations larger than what you can do yourself? Hands on keyboard folks are a dime a dozen and companies can pay them a fifth of what they pay you.
5. How are your presentation and communication skills? Can you explain what you did to someone non technical but knows their business, sonríe who understands technology but not what you did and someone who knows the technology and wants to know why you made the decisions you made?
6. Do you have experience juggling conflicting stakeholder agreements
7. How is both your small talk and business speak - “adding on to what Becky said”, “finding alignment”, “a single pane of glass”, “taking things to the parking lot”, “we aren’t solutioning yet, let’s talk about your business opportunities and challenges “?
is there anyway you'd be willing to field a few questions from a soon to be cs grad interested deeply in this specific career path after realizing they'd been doing it in a way for free already. good experience, but unconventional experience who aspires to a position similar to yours?
Everyone I know who has done it, started out as a developer, moved up to a tech lead position and while doing so learned soft skills and presentations and gut real world experience with designing systems and then moved into consulting.
It’s from my seeing the lay of the land in 2026 almost impossible to get a full time job in a consulting company starting out of a college with just an undergrad doing something technical - unless you are in one of the cheaper countries to hire from.
Most besides the WITCH companies use the business models of hire people in the US for the customer facing roles and hire people in cheaper countries for the Lower level roles.
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.
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.
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.
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').
I'm wondering about that. I think with the advent of AI, we might see a new kind of successful software company - one that doesn't sell a single solution to many customers, but instead has the building blocks, prompts (agents skills etc) & processes to quickly build very custom solutions for each customer - using a new blend of engineers that are not exactly "customer support" nor traditional "sw eng", but more around the emerging "forward-deployed engineer" role.
Sometimes, but if your product is a platform (or anything beyond a niche solution in a broader problem domain) then you're going to spend some time showing people how to make it work best for them.
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?
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.
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?
How do you get to sales from engineering? Must it take place laterally in the same company, or did you sell yourself differently to recruiters, or did you know someone?
A fairly easy role to help bridge that gap is to work in a consulting company as a technical IC. The sales team is always looking for technical folk to help build more robust and achievable projects as well as provide a more accurate estimate for number of resources and amount of time the project will take. They need someone who can push back on impossible client demands and help the sales team understand what those are and why. Ideally in these scenarios a senior tech person would be helping build out the proposal and plan for a project they will actually run and execute on. This gives the client continuity throughout the process and in the course of working within the client environment you’re in a great position to spot other problem areas the client struggles with and help build proactive proposals to help the client address them.
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.
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.
Can you share one such puzzle?
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
Are they paying you as well as your comment makes it sound? That was a ton of lingo and I'm used to lingo!
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.
> 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
Yeah.
In most companies, IT people just started coding and called it DevOps.
Still better than IT folks who refuse to code.
Smart IT people were automating things with Perl and later Powershell since I started professionally working in Windows shops in 2000.
Before that I was working on DEC VAX machines where IT was using DCL.
Yeah, but I studied with a bunch of guys who said they'd go into IT, because they hated coding.
You can hate coding and be an excellent network engineer or even DBA.
I'm an infrastructure guy and I learned to code, but I don't code today. The other poster who talked about good people in the old days using Perl and suchlike tools is right. Competent people care about automation.
But there are all sorts of automation tools that don't require knowing how to write object oriented code or do a ton of code reviews. Terraform is one - it's yaml, and the complexity is one of design patterns. Another is Ansible. GitHub Actions. Many many more.
Let me throw out a grenade. Software developers often over estimate their capabilities in technology. Because a person is an expert in Ruby or Go, and on the weekend they stood up a hosted app on ECS, now magically they're geniuses and understand DevOps.
False. DevOps engineering, network engineering, DBA, and a lot of other non-developer jobs take 5-10 years to get right.
Hopefully I've slammed our Leetcode hiring practices, but really I'm just venting at this point.
It’s a red flag anytime I see a company with a dedicated “database administrator” usually they want you to put all of your business logic in stored procedures and have a dozen GetCustomer_n copies for versioning.
What can a modern operations person do that can automated anything via coding?
BTW: I am “expert” in cloud by any definition (did at a startup, worked at AWS ProServe, staff consultant at a 3rd party consulting company) and I develop. How hard do you really think it is for someone with a developer mindset to learn how system design works at scale and bring their same developer mindset to infrastructure as code?
It took me exactly 2.5 years from opening the AWS console for the first time to being hired at AWS.
Everyone in my division at my current company at my level can hold their own as either a developer or a “senior cloud engineer”. We just find infrastructure babysitting incredibly boring
Half the reason I learned cloud was not because I didn’t want to manage servers - I didn’t want to deal with server administrations.
>BTW: I am “expert” in cloud by any definition (did at a startup, worked at AWS ProServe, staff consultant at a 3rd party consulting company) and I develop. How hard do you really think it is for someone with a developer mindset to learn how system design works at scale and bring their same developer mindset to infrastructure as code?
It depends! Do you mean clicking in the AWS console and spinning up infrastructure? It takes a few days.
Learning terraform/CloudFormation so it's repeatable? Probably a few weeks.
Kubernetes design patterns and troubleshooting? I feel like it takes at least a few months of hands on and theoretical.
To build infrastructure that lasts, is monitored with an APM as well as infrastructure specific tooling (not Cloudwatch) has cost dashboards set up to account for workloads across a dozen product lines (not Cost Explorer), has a CI CD pipeline automation for hundreds of repos including automatic onboarding of new ones, understands cloud security enough to have designed a tight perimeter with some automation around detection and remediation, has strong network level knowledge and knows how to deal with external vendor/client connectivity options (since you have to adapt to their limitations or demands)... Instead of server babysitting, you know in advance how to prepare the inevitable situation where workloads need to scale, and already have tooling and horizontal and vertical auto scaling either automated or ready to go...
If you know these things after 2.5 years, and I say this fully seriously, you are in some sort of .5 percent elite in this industry and deserve something like 1M a year, or you should be leading something huge.
Otherwise there's a risk here that you don't know what you don't know, which was my original point about over confidence by software engineers when it comes to infrastructure.
You did see the part that I worked at startup for 2.5 years, then worked at AWS ProServe for almost 4 and now work at a third party consulting company as a staff consultant leading cloud + app dev hybrid projects?
I turned down a job where the position was going to be created for me by a former coworker at AWS who is now a director at a well known non tech F500 company where I would be responsible for a multi year migration and modernization strategy that would have paid about 30% more than I was making at AWS.
I really hate babysitting infrastructure and lift and shifts so much I turned it down and took a job that paid the same as I was making at AWS. That’s just how much more I enjoy the hybrid cloud + app dev roles.
I deal strictly with AWS on the infrastructure side, the minute I’m working on a large assessment (those huge 50 page requirement docs) and they mention hybrid, or anything outside of AWS, I bring in someone who actually likes that stuff. As I do when I see it’s going to be a migration.
The other side of my job is to actually do hands on app dev + cloud either doing it myself for small projects or leading larger ones.
I’m also not the person who is going to be on call or monitoring, that’s for the young folks.
My last three projects were using the CDK, Terraform and CloudFormation respectively
I'm with you on the avoiding tedium, on-call and monitoring and overall Operations pieces of it.
There's an infrastructure creation aspect where you're creating automation systems and passing it along for others to maintain. I personally think that's a sweet spot.
Everything you said here I relate to, it seemed like you were arguing that infrastructure design and systems engineering is just "app dev ++" as opposed to a collection of skill sets that take years to learn.
It's no different than AI slop if someone thinks cloud automation is just another programming framework to learn. I've worked exactly in 0 companies that got it right when it came to intelligently designed, bullet proof systems. Some of the slop and chaos is so bad it takes big new projects and smarter hires to repair it.
What in god's name is the meaning of the image on their homepage? It looks like a conceptual, digital rendering of a colonoscopy.
https://infisical.com/_next/image?url=https%3A%2F%2Fimages.c...
:D Yes, we demand an explanation!
> 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.
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).
How can I pay you to tell me your secret path to consulting in DevOps?
I'd love to do this or SRE type consulting. However, every organization I've worked with (including finance and government) use big name big business consulting shops, supposedly for liability reasons, and it would be impossible to get a small consulting contract unless you had family members in the C suite.
Moreover, what stops that remote devops from taking place with highly qualified Hungarian or Polish or Portuguese engineers for 40 percent of the rate?
To a first approximation, no big company wants to deal with independent contractors.
My two anecdotes:
About a decade ago, I was leading a project and the director wished he could have “another me”. I told him about a guy who I had worked with who would be good. He wanted $80/hour. My director liked him. He wouldn’t pay my friend $80/hour as an independent contractor. But he would pay a consulting company $110/hour to hire him and then he work for us and he would still get his $80/hour.
Second anecdote: when I was between jobs for a month, a former CTO wanted me to do a side project for him - same situation, he wouldn’t pay me directly because of liability reasons what I wanted. But I reached out to the same consulting company and made the same deal. That went through immediately.
> Moreover, what stops that remote devops from taking place with highly qualified Hungarian or Polish or Portuguese engineers for 40 percent of the rate?
If your value add is only tactics and not strategy, you’re going to have a hard time getting decent rates consulting or even working for consulting companies.
I work in consulting now. I get paid - decently - while I do hands on work, I can also lead projects and do more strategy type projects.
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.
Can relate a lot. I started off as a SWE but am pursuing a support role for similar reasons.
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!
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.)
I should probably date myself, most of this wasn't true 10+ years ago. forward deployed/field, yep, Palantir has kind of owned that. Solutions Architect has definitely been cross functional for a long time, but solutions engineer is a title that I am pretty confident was post-sales first. I A/B tested the title back in 2014 between Product Analyst (candidates too junior), Support Engineer (too much IT/back office support, not enough experience w/ paying customers). Solutions Engineer hit a sweet spot and brought in the best candidates: Generalists who aren't really sure what they want to do, but with broad access to code/product/engineers and customers eventually find a speciality they like.
Because these folks are problem solvers, the title brought a reputation which is exactly why the sales folks wanted to co-opt the title. It conveyed trust and experience. When used well, it's still a good fit in pre-sales for building out POCs and delivering value, but more often than not, it's just sales engineering where they're qualing out potential customers that aren't worth the time of the sales team. Which is fine, except that this is MY title :)
To be clear, I take this a little personally as I was an early adopter of the title. It's kind of like those folks that get annoyed when you're a fan of a band that they liked before you ever heard of them, I admit it.
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.
Agreed - its total sales engineering as he described it.
Use " Solutions architect " maybe instead ?
That title has long been used as a post sales analyst (custom work for $)
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
> 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.
It's always nice when the customer wants to improve the process/product, it can overcome internal friction that had prevented making things better.
I worked for 7 years employed by a high throughput computing facility at a large university as a combination of solution engineer/software architect. I got paid to network with faculty, listen to their problems, pitch them ideas and implement POCs, then help them iterate and scale.
If the management of the department hadn't been so catastrophically bad, it would have been the ideal job. Working more traditional software engineering roles afterwards was frustrating, I missed the freedom. Even as a tech lead, it just felt like managing plumbers. I love creativity and exploration, nuts and bolts are incidental.
Some people mentioned to me that going Solutions Engineer was a good way to get more non-technical/business skills.
I saw a few SEs starting their own companies later, seemingly because their SE roles "trained" them for the business side of things.
I considered doing this myself; however, I'm a freelance software engineer and technical writer. More a jack of all trades than someone with major skills in one category of software engineering.
A jack of all trades is preferable as a solutions engineer.
side note, i absolutely love Infisical’s self-hosted offering. it’s really easy to get set up with and aside from a few minor problems with their Universal Auth, i had it working in production in just a few days. it’s made secret management a lot easier, especially across different environments!
i’m aware that there are limits on the free plan, but as a single user i haven’t hit any crazy restrictions
Really glad to hear that! What problems did you have with Universal Auth?
upon remembering, it was actually just Token Auth - for some reason, when i created a machine identity in my parent organization, tbe CLI would always return a 403 for any project ID, regardless of whether i gave the identity the adequate permissions.
i got around it by just generating an identity for each project, which was probably a better idea anyway for granularity
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
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).
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.
Best job in the world.
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.
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.
@cootsnuck, if I didn't really love working with the people/company I'm at now, I'd also start my own consulting company.
Once I realized you really only need 3-5 consistent customers (well, you only REALLY NEED one customer), and you can generally keep customers and employees happy by responding quickly and doing what you say you'll do (aka not taking on work you can't handle) I'm confident I could branch out on my own if I ever wanted to.
Yes... and also it pays pretty damn well if your company sales team is winning. Incentives are aligned.
My experience in a “product company” - Pre-sales solutions engineer - the original problem solver. Professional services - post-sales firefighter :)
Inspiring article. Well written. Totally feeling it!
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.
Thank you. Can't upvote you enough for the info.
My pleasure!
I forgot one more thing. Your technical aptitude carries less weight as an SE. Getting the technical win at a customer is what you're evaluated on.
Since you're almost always working with engineers and technical stakeholders at the customers you're selling to, you need to be able to talk the talk to fit in, gain their trust and help them see the value of what you're selling.
But those skillets alone won't get the technical win. This is where the sales part of sales engineering matters, and it matters a lot.
A quick example: a common mistake many new SEs coming from consulting make while giving demos is showing customers everything about a product step-by-step instead of showing them only what the customer said they care about (which you, hopefully, learned in the initial discovery call) and/or what they need to see (because other similar customers usually care about those things).
The former comes very naturally to consultants, as that's a big part of the job, but giving demos this way makes it much easier to NOT show what the customer needs to see AND increases the likelihood of you showing a deficiency in the product that can reduce interest or, if it's bad enough, kill the deal.
You won't come across those kind of skills unless you (a) founded a company and try hard to build business or (b) work in sales. But these skills make or break SEs.
Even more gems than the previous post!
Btw, not sure if you're aware, your 2 resumes are linked to the same content
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!
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.
This sounds very adversarial to me. I’m glad our devops team doesn’t think like you.
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?
If you have a “DevOps team” - they are operations and you aren’t getting any of the benefits of a DevOps mindset
Meh, real life is a bit more complicated than a manifesto.
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?
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”.
It very much was possible in 2001. In 2001 we automated updating and automating our 15 or so Windows job runners with Perl and the Win32:: module.
No large enterprise by 2001 was walking up to individual PCs and updating computers by walking around and sticking CDs/DVDs in each computer and they were definitely making sure our on prem SQL Server and later MySQL database wasn’t having issues using dashboards and alerts.
That was very much present in 2001 except it was two separate teams: qa and sysadmins
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
> 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.
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:
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).if (should_never_happen) { log.error("owner=wombat@example.com it happened again"); }It truly depends on the type of DevOps experience. I've avoided firefighting DevOps roles my career and I enjoy it. Having the space to step back and design intelligent dependent systems is satisfying.
> I like writing code ... ONLY!
Boy do I have some bad news for you...
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.
DevOps is secretly spiral development.
Great if billing by the hour, and mostly unsustainable for products =3
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).
> 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.
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).
> I'd still classify what they're doing as DevOps type of work.
This is very, very wrong. Why do you think that?
> Why do you think that?
The OP wrote:
> As an SE, I'm exposed to everything. Customers running Kubernetes, ECS, Lambda, bare metal, air-gapped environments. AWS, Azure, GCP, hybrid setups. CI/CD in Jenkins, GitHub Actions, GitLab, CircleCI. I have to understand their environment well enough to actually help them, so the learning is constant. The stagnation I felt in DevOps? Gone.
These are all things I deal with in my day to day as well in a DevOps / Infrastructure / Platform type of role. I mean, not literally everything like air-gapped environments since the companies I work for don't have that but it's all things in that category of line of work.
The only difference is I usually don't interface directly with the company's customers of the services being built. It's more like the company's staff are my customers because I'm working with developers, management and sometimes other parts of the business on ways to help optimize their workflows which all funnel back to helping create a better end customer experience.
devops means a lot of different things to different people
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?
Help me understand this 'embedded in developer teams' in a larger company. Do you have no central infrastructure with centralized tooling, alerting, standards and knowledge?
Team A has a devops engineer, Teams B through F have one, how do they have any capacity to pursue long term strategical projects, save money and operational effort with centralized hosting and tooling, and basically have some autonomy, when they are enslaved to a Scrum Master and some hokey pokey Fibonacci numbers and T Shirt Size nonsense having to argue priorities in every Sprint against people who don't care about operations?
That's what embedded devops is to me - an operational role enslaved to dev leads, the poor guy who has to troubleshoot a failed release while the devs are at the bar.
Unless my straw man is wildly off, no thanks to that embedded stuff.
That’s exactly what it means , a person who reports to the infrastructure team who decides standards and is embedded with the devs as part of the project.
If you are just throwing things over the fence - you’re an “operations” team and get none of the benefits of DevOps
Understood, but so far what I observed is the embedded devops pressured/saying Yes/beholden to a PM running sprints, and the central infra team management constantly has to intervene to protect the embedded devops engineer politically.
Maybe my experience is a rare example, but my conclusion so far is that it's tricky to prevent this painful situation, and requires vigilance.
And once you have the infra team saying no all of the time and being antagonistic - you’re back to old school operations and you aren’t a DevOps shop.
But if they never say no, how do you maintain central infrastructure standards?
If you say yes all the time, I feel like that's how you turn devops into Ops monkeys who are reactive, since people are operating on Sprint timelines instead of optimizing for long-term stability.
Looking through the AWS lens because that’s the one I know.
The goal of the centralized ops team is to put just enough guardrails on the Organization (a group of AWS accounts) to keep the company in compliance - no public access S3 buckets, no one has organization::* permissions, set budget limits per account or organizational units etc, establish budget thresholds (or in the case of Isengard - AWS’s account vending machine - you can do almost anything except spin up an Oracle DB) . Let each team be responsible for their own deployments, monitoring, etc. For the most part, the top level operations department should be responsible for the Organization, setting up service control policies, Security monitoring and then the embedded DevOps person should be an SME not the department of “no”.
If you make the dev team a long with the embedded ops person responsible for their account/monitoring and they get called once a twice, they will figure it out
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.
Rule #1 is never make assumptions about anyone on the internet…
In the past 8 years I’ve led the architecture of a startup - cloud + app dev. Then spent almost 4 years working at AWS ProServe involved with large cloud + app dev “cloud application modernization” projects and now 2 years doing the same as a staff level consultant at a 3rd party consulting firm. I think I’ve seen my fair share of how large private companies, startups, government organizations and colleges work.
A lot of my projects pre AI involved bringing modern DevOps practices to an organization - convincing operations to use IAC and best practices and have them more embedded into the dev teams.
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.