The Misallocated SE
In the last post we discussed how the SE role is unique, and why. By way of review: Presales Engineers do all three core business functions simultaneously. That is, they sell, make, and support for both internal and external stakeholders.
Below is an interactive chart that shows some common tasks Sales Engineers perform in each category:
As a result, SEs are frequently over subscribed.
This may seem OK on the surface (i.e. you're fully utilizing your talent, right?). Wrong. And this study explains a major reason why. I've taken the liberty to repurpose a key diagram from it, which describes how SE utilization can positively or negatively affect the individual performance of their sales counterparts. It describes three phases:
- Initial trust building as a team unit with the SE and their Sales partner(s).
- A fully operationalized team, with optimal sales results.
- SE overutilization, which diminishes sales outcomes across the board. Sales team members suffer from "role ambiguity", time management challenges, and more.
The punchline is essentially this:
Overutilization of the sales engineer can lead to diminished self-efficacy of the salesperson.
The SE is a critical part of the sales effort and diluting focus or otherwise spreading them too thin has a negative ripple effect across the field.
The Build Trap
When an SE needs an environment, they often build one.
These environments can take on many flavors:
- Custom integration demo for a strategic prospect.
- A sandbox for testing.
- POC with specific requirements you can't check-off without proper access to prod.
If done correctly, environments like this can solve a real, isolated problem. But they also create a structural liability that compounds over time. This liability is in the form of technical debt, sprawl, dilution of SE cycles, and negative sales outcomes (see above).The cloud service providers have a term for this, and I believe it's relevant here: undifferentiated heavy lifting. Our cheeky substitute term is artisanal labs.
Artisinal labs are un-versioned, difficult or impossible to reuse at any scale, and dependent on the person who created it. Over time, islands of functionality accumulate and impose inefficiencies that compound. It's like asking a pilot to build their own plane. Even if they could, would it be a smart allocation of their expertise? Is it a differentiated capability an SE should be spending time on? In most cases the answer is no.
SEs are the connective tissue between the product and a customer's problem. Every hour they spend wrangling virtual images, Terraform/CloudFormation templates, or performing bespoke development is an hour not spent on selling and supporting.
What comes next
We've now arrived at demOS®, our purpose-built platform aimed squarely at solving these problems for technical sales and marketing. It'll be the first of several posts that dive into use cases, architecture, and capabilities.
