Comparing Pre-Sale and Post-Sale Technical Resources
I’m asked frequently about the difference between pre-sale and post-sale technical resources, and why they can’t be used interchangeably. Typical pre-sale technical resource titles are Sales Engineer and Solution Consultant; post-sale technical resource titles are more varied and include Solution Architect, Implementation Engineer, and Technical Consultant. For brevity I’ll refer to them as Sales Engineer (SE) and Solution Architect (SA).
The relevant technical skills and product knowledge are similar. I like to identify the superset of technical skills and product knowledge and state the minimum required proficiency for each as follows:
- Level 0: None (i.e., the skill/knowledge is nice-to-have)
- Level 1: Beginner (know enough to be dangerous)
- Level 2: Intermediate (experienced but may require assistance at times)
- Level 3: Advanced (know it cold)
In my experience, SEs can be successful with lower levels of proficiency than SAs. In particular, SEs usually can get by with level 1 proficiency, with a scattering of level 0 proficiency. On the other hand, SAs rarely are successful with less than level 2 proficiency, and level 3 proficiency in at least one area; level 0 proficiency stands out like a sore thumb.
The very best SEs would make great SAs, and vice versa, but outside of this upper echelon there’s an important difference in mindset that makes crossing over ill-advised. That difference comes down to what you view as the resource’s most important reason for existing, and the required mentality implied by such raison d’être.
The most important reason for an SE to exist is to help get deals done. That means going only as deep as is absolutely necessary to overcome objections during sales cycles; anything more consumes valuable time and can give rise to additional objections. SAs, meanwhile, exist to optimize for the long term. You want them to sweat the details and this is often done by peeling the onion one layer at a time. Dave Kellogg puts it another way: the role of the SA is to maximize ARR while not losing money.
SEs are deal accelerators, while SAs are lifetime value maximizers. You don’t want an SA to do a sales demo, because while capable of doing it, a demo isn’t actually what you need; what you need is an objection put to bed—and quickly. The ability to do this effectively is exceptionally valuable and uncommon. At the same time, you don’t want an SE to manage an implementation—the robustness that’s needed doesn’t come naturally.
None of this is meant to imply that SEs should pull fast ones on unsuspecting prospects; if an SE knows or suspects that a prospect may encounter a future problem as a customer, it’s incumbent on him or her to address it. Just don’t lose a deal by selling past the close.
There are exceptions, of course. Early-stage companies will share technical resources between pre- and post-sale activities out of budget necessity. True enterprise products will involve SAs in pre-sale conversations over a period of many months. But generally speaking, matching skills, knowledge, and mindsets to tasks at hand will yield the best results.
