Las Múltiples Caras de un Ingeniero de Preventa. Parte 2
(seguimos con la serie sobre las competencias de un ingeniero de preventa)
The first one (X axis) is the Product dimension. Of course, Sales Engineering needs to understand the product from a technical standpoint, and then be able to master it. When I say "master it", I don't mean that an SE should be able to know the details as a Product Engineer does. But it's also not enough for him/her to be an average user. As I usually put it, an SE must be the most technical user the company's ever had. Of course, we can always find examples of SEs that know a lot about the details of the product, even about the internal code. I understand this in big corporations where the relationship between Sales Engineering and Engineering is complex. But in a well-oiled product company, I believe a Sales Engineer should not get to that point unless in very specific circumstances. Figure 2 shows the basic hierarchy of SE skills in the dimension.
The second axis focuses on environment. Meaning the environment in which our product or service needs to run on. But not only on the pure "hardware-software" environment where the product runs, but also on the different architectures where the product might be useful, both from a practical and a theoretical standpoint. The skills of this category would also belong to an Enterprise Architect. But that is what an SE is, but from a product provider's point of view.
The third axis relates to the specific customers the SE is talking to. What are their knowledge and business domains? And their organization? Who is the main champion, and who the technical gatekeeper? What kind of demo should I show them, or what is the best proof of concept we can propose? Those are critical questions which answer SEs must find out in order to secure a deal. This category relies on the SE's communication, negotiation and assertion skills, but also depends on the other two categories, since a good discussion with the customers requires having knowledge about both product and environment.
Finally, everything is surrounded by an inner knowledge of how the SE's own company works. Even a small product company requires the understanding of a set of procedures, hierarchies, formal and informal networks, where an SE is a basic part of it. Internal tension and frictions based on a lack of understanding of these elements can only cause delays and frustrations that lead nowhere. On the other hand, a great knowledge of this allws to have honest and useful conversations about how to improve them in an iterative and incremental way.
In the following posts, I will describe each of the dimensions in more detail.
2. SE Skills Categorization
Figure 1 shows the basic categorization which comprises of the competencies a Sales Engineer is expected to master. Of course, I could have chosen many more dimensions, or different ones, but I've chosen these three because (1) these are the ones that I use most often when managing SEs, (2) three is a great number for our three-dimensional mind :), and (3) this allows to differentiate between three types of Sales Engineers:- Technical Sales Engineer: must excel in the product and company categories. Usually Junior profiles, or high-skilled developers.
- Sales Architect: focused on the technical interactions, this profile masters the product, environment and company categories.
- Technical Account Manager: as a sales-driven individual, the product, customer and company categories are a must. Usually, top-notch TAMs will be a mixture of this and the previous category.
Figure 1: SE Competency Dimensions
The first one (X axis) is the Product dimension. Of course, Sales Engineering needs to understand the product from a technical standpoint, and then be able to master it. When I say "master it", I don't mean that an SE should be able to know the details as a Product Engineer does. But it's also not enough for him/her to be an average user. As I usually put it, an SE must be the most technical user the company's ever had. Of course, we can always find examples of SEs that know a lot about the details of the product, even about the internal code. I understand this in big corporations where the relationship between Sales Engineering and Engineering is complex. But in a well-oiled product company, I believe a Sales Engineer should not get to that point unless in very specific circumstances. Figure 2 shows the basic hierarchy of SE skills in the dimension.
The second axis focuses on environment. Meaning the environment in which our product or service needs to run on. But not only on the pure "hardware-software" environment where the product runs, but also on the different architectures where the product might be useful, both from a practical and a theoretical standpoint. The skills of this category would also belong to an Enterprise Architect. But that is what an SE is, but from a product provider's point of view.
The third axis relates to the specific customers the SE is talking to. What are their knowledge and business domains? And their organization? Who is the main champion, and who the technical gatekeeper? What kind of demo should I show them, or what is the best proof of concept we can propose? Those are critical questions which answer SEs must find out in order to secure a deal. This category relies on the SE's communication, negotiation and assertion skills, but also depends on the other two categories, since a good discussion with the customers requires having knowledge about both product and environment.
Finally, everything is surrounded by an inner knowledge of how the SE's own company works. Even a small product company requires the understanding of a set of procedures, hierarchies, formal and informal networks, where an SE is a basic part of it. Internal tension and frictions based on a lack of understanding of these elements can only cause delays and frustrations that lead nowhere. On the other hand, a great knowledge of this allws to have honest and useful conversations about how to improve them in an iterative and incremental way.
In the following posts, I will describe each of the dimensions in more detail.
Comments