I would like to believe that with ZIRP over, for now, we’ll see devfluencers and devrel wither up and blow away so that we can all get back to evaluating technology on its merits instead of the number of pageviews it has–friendlysock says, pretending that this has ever been the natural order of things–but instead I think we’ve created a cottage industry of soothsayers and silver-tongued dev-washed content creators that is self-sustaining and will plague the rest of us for some time to come.
What do sales engineers do? I ask as a genuine question.
In my experience they accompany sales people and pretend to answer technical questions then repeat the same thing if asked a follow up. In the company I work at they also demonstrate the product because actually learning to use the product is beyond the capabilities of the salespeople.
I think a more generous definition would be that “Sales Engineers” perform development that facilitates sales: often building proof-of-concept demos using a product in order to showcase it to a targeted potential customer or prove it can suit a customer’s needs. In a small team, this could certainly be the responsibility of the salesperson themselves, but in a large enough organization there is room for specialization, just like many other roles.
If that’s the case, can devrel be called “marketing engineer” specialization?
It would fit in the article as well, the author calls for devrels to “be more professional” in a sense, and have more metrics to show.
It would even fit with their observed market changes. People spend less on marketing when the money is short. Anecdotally, my co just fired off a bunch, including the marketing team. (We didn’t even have devrels so this was the “traditional” marketing that was let go.)
Company specific. I’ve worked with solid Sales Engineers who genuinely were contributors to the codebase and would do things like maintain client libraries etc.
Hi there, I’ve been in basically all of the following roles in my time at Stripe – Sales Engineering / Solutions Architecture / Customer Engineering / Partner Engineering / Integration Engineering. These are all differently evolved Pokémon from this core function.
Their purpose and the skills necessary is going to vary depending on the product being sold. If you want to be an architect at Cisco, you need to know the basics of networking and probably very little about software. At $CLOUD_COMPANY, you’d need to configure lots of different services/infra for the needed use case. If you are an architect at any API company (like Stripe), you need to understand HTTP but probably also the core parts of API services in addition to all the real world impacts of issuing a single POST request.
Fundamentally, the role is to make sure that the product you have will work for them and the user believes this to be the case. This is important because companies have all sorts of hurdles internally to successfully adopt a new service. A Solutions Architect along for the ride helps multiple technical people across that organizational web understand what problems your product is helping them solve.
Next, the job is to make sure your product successfully connects with the systems of your user. No product no matter how great is going to work 100% of the time with the systems and legacy infrastructures that are out there the world. That last mile gap can be quite expansive at times. Solving this gap sometimes means working with engineering teams to architecture their future, sometimes it means advocating for or adding additional features at the edge, sometimes it really is just an issue of educating users about the product (I’ve explained the benefits of UTC in the Stripe API for instance, many more than zero times).
In my experience they accompany sales people and pretend to answer technical questions then repeat the same thing if asked a follow up.
I promise you, there exists organizations where these folks never pretend to answer questions. They really do answer them!
In the company I work at they also demonstrate the product because actually learning to use the product is beyond the capabilities of the salespeople.
I would argue that this isn’t a property of uppercase Salespeople. I’ve seen sales folks do some pretty fantastic demos or explain very complex topics without breaking a sweat. A great sales engineer also supports the account team around them and acts as a force multiplier, people generally want to learn and improve and so a technical educator who uplifts their team around them is a great resource for sales teams.
Reminds me of when Salesforce flew out a team for a sales meeting that included 3–4 “solution engineers” who answered nearly every technical question with either “there are multiple [unspecified] ways to do that” or “you’ll need to hire an implementation consultant”. I have no idea what their actual job is, but it didn’t seem to be engineering solutions.
With a small sample size, that company is probably one of the worst offenders of lowering the bar for this function.
I think the technical sales role is also diluted in companies that have “walled-garden” or “architecturally discrete” runtimes or systems, companies like Salesforce, large ERP systems, ServiceNow, etc. For example, Salesforce and their leverage in the market can basically say “it’s going to work this way, and if you don’t want it to, well that’s on you” many other companies don’t have that sort of negotiating power.
As well, their systems are so vast that you can be safely entombed in them and their vagaries such that you can successfully explain how the technical workings work, but would have no idea how to write “Hello World!” or explain HTTP.
My impression was they were just completely baffled by having a customer that was a software company itself. We didn’t want an implementation consultant, we just wanted to know how to implement things.
Out of desperation, we eventually did hire an implementation consultant, not to implement, but just to act as the developer support function that Salesforce apparently doesn’t have. I asked them how the heck they got developer support themselves, and the answer seemed to be that they didn’t.
The product / services catalog is so vast that you basically need a guide who knows all the paths to get to your end goal. Along that path are pending deprecations, new but untested components, long-untouched SDKs, etc etc.
Out of desperation, we eventually did hire an implementation consultant, not to implement, but just to act as the developer support function that Salesforce apparently doesn’t have.
And is a good example of the symbiotic ecosystem that thrives beneath them.
A good sales engineer assures the customer that there are competent technical people at the company. Specifically, they can relate the capabilities of the software to the exact problems faced, actually answer the technical concerns, and excite the customer engineers.
If the sales engineer ducks the technical questions then you should reconsider that company.
forced startups to prioritize sustainability over growth at all costs
Good. The “growth at all costs” model is toxic and gave rise to truly horrifying applications of tech. It should never have happened and I hope it never happens again.
The traditional model, reliant on soft metrics and long-term value propositions, can’t survive unchanged.
Long-term value propositions is exactly what you prioritise when you care about sustainability, though…
The “growth at all costs” model is toxic and gave rise to truly horrifying applications of tech. It should never have happened and I hope it never happens again.
I have some bad news for you about the tech industry, capitalism and the current AI bubble.
I agree with the author that DevRel is very hard but also potentially really rewarding. I did this for nearly two years and I think to be truly great you need a lot of things going for you. Technical skills, a high bar for design, charm, community-engagement, and serious speaking skills. It’s very demanding and it’s a lot of spotlight while your skills diminish as you are no longer in the thick of things. One of the reasons I recall Kelsey Hightower stepped away from these kinds of roles.
One thing I didn’t see mentioned was that DevRel and company branding go hand in hand. I enjoy what @leerob has done with Vercel, and what @iconicbadger has done for Tailscale, or even originally with Jono Bacon and Ubuntu. These people are the ‘face’ of those companies for lots and lots of people and that it kind of elevates them in a way.
Another change since the first steps of DevRel is the rise of programming/dev influencers such as Primeagen, TJ Devries, BashBunni, etc - they’re another source of content for developer communities that are going to share opinions on things. Not having a strategy with how you engage with these self-organizing communities will probably hurt you!
Overall, though I think we’re still in prime territory for having DevRel, one only has to look to OpenAI and Anthropic to see the power that role has with products relatively very few people understand.
I would like to believe that with ZIRP over, for now, we’ll see devfluencers and devrel wither up and blow away so that we can all get back to evaluating technology on its merits instead of the number of pageviews it has–friendlysock says, pretending that this has ever been the natural order of things–but instead I think we’ve created a cottage industry of soothsayers and silver-tongued dev-washed content creators that is self-sustaining and will plague the rest of us for some time to come.
What do sales engineers do? I ask as a genuine question.
In my experience they accompany sales people and pretend to answer technical questions then repeat the same thing if asked a follow up. In the company I work at they also demonstrate the product because actually learning to use the product is beyond the capabilities of the salespeople.
It varies a lot by the company. Some just do demos, but depending on the product and the complexity there can be a lot more involved.
I’ve done a sales engineering (“solutions architect”) role for complex HW and SW products, and among other things my job included:
I think a more generous definition would be that “Sales Engineers” perform development that facilitates sales: often building proof-of-concept demos using a product in order to showcase it to a targeted potential customer or prove it can suit a customer’s needs. In a small team, this could certainly be the responsibility of the salesperson themselves, but in a large enough organization there is room for specialization, just like many other roles.
If that’s the case, can devrel be called “marketing engineer” specialization?
It would fit in the article as well, the author calls for devrels to “be more professional” in a sense, and have more metrics to show.
It would even fit with their observed market changes. People spend less on marketing when the money is short. Anecdotally, my co just fired off a bunch, including the marketing team. (We didn’t even have devrels so this was the “traditional” marketing that was let go.)
Company specific. I’ve worked with solid Sales Engineers who genuinely were contributors to the codebase and would do things like maintain client libraries etc.
Hi there, I’ve been in basically all of the following roles in my time at Stripe – Sales Engineering / Solutions Architecture / Customer Engineering / Partner Engineering / Integration Engineering. These are all differently evolved Pokémon from this core function.
Their purpose and the skills necessary is going to vary depending on the product being sold. If you want to be an architect at Cisco, you need to know the basics of networking and probably very little about software. At $CLOUD_COMPANY, you’d need to configure lots of different services/infra for the needed use case. If you are an architect at any API company (like Stripe), you need to understand HTTP but probably also the core parts of API services in addition to all the real world impacts of issuing a single POST request.
Fundamentally, the role is to make sure that the product you have will work for them and the user believes this to be the case. This is important because companies have all sorts of hurdles internally to successfully adopt a new service. A Solutions Architect along for the ride helps multiple technical people across that organizational web understand what problems your product is helping them solve.
Next, the job is to make sure your product successfully connects with the systems of your user. No product no matter how great is going to work 100% of the time with the systems and legacy infrastructures that are out there the world. That last mile gap can be quite expansive at times. Solving this gap sometimes means working with engineering teams to architecture their future, sometimes it means advocating for or adding additional features at the edge, sometimes it really is just an issue of educating users about the product (I’ve explained the benefits of UTC in the Stripe API for instance, many more than zero times).
I promise you, there exists organizations where these folks never pretend to answer questions. They really do answer them!
I would argue that this isn’t a property of uppercase Salespeople. I’ve seen sales folks do some pretty fantastic demos or explain very complex topics without breaking a sweat. A great sales engineer also supports the account team around them and acts as a force multiplier, people generally want to learn and improve and so a technical educator who uplifts their team around them is a great resource for sales teams.
Reminds me of when Salesforce flew out a team for a sales meeting that included 3–4 “solution engineers” who answered nearly every technical question with either “there are multiple [unspecified] ways to do that” or “you’ll need to hire an implementation consultant”. I have no idea what their actual job is, but it didn’t seem to be engineering solutions.
With a small sample size, that company is probably one of the worst offenders of lowering the bar for this function.
I think the technical sales role is also diluted in companies that have “walled-garden” or “architecturally discrete” runtimes or systems, companies like Salesforce, large ERP systems, ServiceNow, etc. For example, Salesforce and their leverage in the market can basically say “it’s going to work this way, and if you don’t want it to, well that’s on you” many other companies don’t have that sort of negotiating power.
As well, their systems are so vast that you can be safely entombed in them and their vagaries such that you can successfully explain how the technical workings work, but would have no idea how to write “Hello World!” or explain HTTP.
My impression was they were just completely baffled by having a customer that was a software company itself. We didn’t want an implementation consultant, we just wanted to know how to implement things.
Out of desperation, we eventually did hire an implementation consultant, not to implement, but just to act as the developer support function that Salesforce apparently doesn’t have. I asked them how the heck they got developer support themselves, and the answer seemed to be that they didn’t.
The product / services catalog is so vast that you basically need a guide who knows all the paths to get to your end goal. Along that path are pending deprecations, new but untested components, long-untouched SDKs, etc etc.
And is a good example of the symbiotic ecosystem that thrives beneath them.
I am sorry to hear about your experience.
A good sales engineer assures the customer that there are competent technical people at the company. Specifically, they can relate the capabilities of the software to the exact problems faced, actually answer the technical concerns, and excite the customer engineers.
If the sales engineer ducks the technical questions then you should reconsider that company.
That’s the theory. That said, I’d say that Google, AWS, and (this dates me) HortonWorks just trot out certification jockeys.
Voting spam for “3 stories submitted, all self-authored, 0 comments”. Is this DevRel?
Good. The “growth at all costs” model is toxic and gave rise to truly horrifying applications of tech. It should never have happened and I hope it never happens again.
Long-term value propositions is exactly what you prioritise when you care about sustainability, though…
I have some bad news for you about the tech industry, capitalism and the current AI bubble.
…
ಠ_ಠ
I agree with the author that DevRel is very hard but also potentially really rewarding. I did this for nearly two years and I think to be truly great you need a lot of things going for you. Technical skills, a high bar for design, charm, community-engagement, and serious speaking skills. It’s very demanding and it’s a lot of spotlight while your skills diminish as you are no longer in the thick of things. One of the reasons I recall Kelsey Hightower stepped away from these kinds of roles.
One thing I didn’t see mentioned was that DevRel and company branding go hand in hand. I enjoy what @leerob has done with Vercel, and what @iconicbadger has done for Tailscale, or even originally with Jono Bacon and Ubuntu. These people are the ‘face’ of those companies for lots and lots of people and that it kind of elevates them in a way.
Another change since the first steps of DevRel is the rise of programming/dev influencers such as Primeagen, TJ Devries, BashBunni, etc - they’re another source of content for developer communities that are going to share opinions on things. Not having a strategy with how you engage with these self-organizing communities will probably hurt you!
Overall, though I think we’re still in prime territory for having DevRel, one only has to look to OpenAI and Anthropic to see the power that role has with products relatively very few people understand.
@bashbunni’s “developer advocacy in 5 minutes”: https://youtu.be/s01UjQk3syk
[Comment removed by author]