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.
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.
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.
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.
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
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.
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 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!
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.
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).
And what would that news be? I have successfully doing this for almost 20 years. Yes, it means fewer promotions and less money, but I don't care. I value my sanity over money.
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.
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.
> 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
> 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.
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 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 ...
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.
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.
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
I 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
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.
38 comments
[ 4.6 ms ] story [ 71.6 ms ] threadHonestly 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.
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.
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.
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).
Boy do I have some bad news for you...
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.
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.
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.
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
https://infisical.com/_next/image?url=https%3A%2F%2Fimages.c...
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.
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).
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 ...
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 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
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.