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
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 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 “?
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.
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.
If you're working in SaaS or commodity products and have to run POCs a lot, you're totally correct.
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?
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.
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.
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
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
In most companies, IT people just started coding and called it DevOps.
Still better than IT folks who refuse to code.
Before that I was working on DEC VAX machines where IT was using DCL.
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.
https://infisical.com/_next/image?url=https%3A%2F%2Fimages.c...
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).
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?
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.
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.
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!
- 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.)
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.
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.
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.
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.
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.
i’m aware that there are limits on the free plan, but as a single user i haven’t hit any crazy restrictions
i got around it by just generating an identity for each project, which was probably a better idea anyway for granularity
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.
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.
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.
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.
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.
Boy do I have some bad news for you...
Great if billing by the hour, and mostly unsustainable for products =3
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 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).
This is very, very wrong. 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.
It requires a more holistic, generalist view, and a degree of customer understanding, empathy, management and conversational skills well beyond typical devops.
