> I have been interested in software sales as well but that seems like it could be hard to break into as an engineer.
I am currently in technical sales (Presales is the name of my org).
This absolutely is not the case. There aren't a ton of folks crossing over but one of my team members did so and has been quite successful.
While it wasn't from a software engineering role, I moved to technical sales from the org's support group so I have the faintest sense of what pitfalls that you may go through.
At the end of the day, many folks in Support groups and R&D groups can fall into the trap of thinking narrowly about a problem. Let us take the problem of getting data into an application. In this scenario a customer asks you if your tool supports 'real time data'. The direct answer is no, it takes time for the tool to fetch / process / present the data from the source system. From a technical lens, this is absolutely, 100% correct. From a selling lens, it's helpful to redirect the conversation towards the customer's goal. Their goal is that they have the lowest latency data possible. This isn't a binary yes / no situation like the previous question.
Now it's relevant to ask questions like:
- What is the source system?
- Is the source truly the originator of the data or is it a downstream consumer of a pipeline?
- If it's not the originator, then how frequently is this pipeline run? Real-time? Micro-batch? What is the latency here?
- Is the source a fixed price system or a cloud-native platform (e.g. Snowflake, BigQuery, etc) where there are marginal costs per query?
- How many consumers will there be of this data? 1? 100? 1000? 10,000? Data approaches often can be cost / performance effective at one scale but flounder at another.
The net result is that the key question that you have to ask involves focusing on the _problem_ the potential customer wants to solve, not just the mechanics of how to solve it.
That plus
- the politics of the deal
- answering the question at the right level of grain for an audience (engineers get different frames of the same answer than VPs / Executives)
- positioning your differentiated techniques and technologies early in the deal to nudge out competitors (they will be doing the same)
- explaining broad or complicated techniques in a consumable fashion (aka a ton of PowerPoint slides) and a number of other aspects
Feel free to ping me (email is in my profile) if you want to chat more about this.
I am currently in technical sales (Presales is the name of my org).
This absolutely is not the case. There aren't a ton of folks crossing over but one of my team members did so and has been quite successful.
While it wasn't from a software engineering role, I moved to technical sales from the org's support group so I have the faintest sense of what pitfalls that you may go through.
At the end of the day, many folks in Support groups and R&D groups can fall into the trap of thinking narrowly about a problem. Let us take the problem of getting data into an application. In this scenario a customer asks you if your tool supports 'real time data'. The direct answer is no, it takes time for the tool to fetch / process / present the data from the source system. From a technical lens, this is absolutely, 100% correct. From a selling lens, it's helpful to redirect the conversation towards the customer's goal. Their goal is that they have the lowest latency data possible. This isn't a binary yes / no situation like the previous question.
Now it's relevant to ask questions like:
- What is the source system?
- Is the source truly the originator of the data or is it a downstream consumer of a pipeline?
- If it's not the originator, then how frequently is this pipeline run? Real-time? Micro-batch? What is the latency here?
- Is the source a fixed price system or a cloud-native platform (e.g. Snowflake, BigQuery, etc) where there are marginal costs per query?
- How many consumers will there be of this data? 1? 100? 1000? 10,000? Data approaches often can be cost / performance effective at one scale but flounder at another.
The net result is that the key question that you have to ask involves focusing on the _problem_ the potential customer wants to solve, not just the mechanics of how to solve it.
That plus
- the politics of the deal
- answering the question at the right level of grain for an audience (engineers get different frames of the same answer than VPs / Executives)
- positioning your differentiated techniques and technologies early in the deal to nudge out competitors (they will be doing the same)
- explaining broad or complicated techniques in a consumable fashion (aka a ton of PowerPoint slides) and a number of other aspects
Feel free to ping me (email is in my profile) if you want to chat more about this.