Moonlighting as an SE
The farmer and the cowman should be friends
When you join a very small startup, everyone is expected to wear a lot of hats. If you’re brought in as the first customer engineer in an early-stage startup, you’re more likely than not the first hire who isn’t squarely in engineering, sales, or a founder. In other words, you’re the only customer-facing technical person on staff (possibly excepting a founder). But as we’ve talked about in the past, customer engineering isn’t the only customer-facing technical role out there. With that in mind, there are a lot of different additional jobs you’ll probably have to take on, at least until your company grows enough to hire someone to take those tasks from you full-time. For the next few weeks we’re going to talk about what it’s like to be a founding customer engineer who’s also filling a lot of other customer-facing roles like SE (sales engineering), deployment engineering, CS (customer success), and so on. This week we’ll discuss being a part-time SE while also holding down the fort as a full-time customer engineer.
What is an SE?
You probably already have a good idea what an SE is and does, but just to make sure we’re on the same page, here’s a brief refresher. An SE works closely with account executives (AEs), or is paired with just one, to serve as the technical resource throughout the sales process. The SE generally conducts any necessary software demos, answers technical questions, and helps ensure that the POV (proof of value) or pilot deployment goes smoothly and demonstrates that the product meets the customer’s requirements. While the AE is responsible for handling the business side of the deal, including contractual terms and pricing, the SE is there to remove any technical hurdles standing in the way of a successful sale. An SE needs to understand and be responsive to business considerations, of course, but their domain is primarily technical. This is why, in a pinch, a good customer engineer can fill in as an SE.
Where the roles overlap
I like to say that SEs and customer engineers have the same technical skills, but apply them for different purposes. They both need to understand the product inside out, its pluses and minuses, its rough spots and gotchas, and effective deployment models. For an SE, this is all critical to giving a good demo and to helping the customer through a trial or POV deployment. For a customer engineer, on the other hand, this skillset is deployed for fast and efficient troubleshooting, use case advice, and ensuring customers can effectively use your company’s product.
I’d also add that soft skills necessary to succeed in each role also overlap quite a bit, but again in different directions. Customer engineers excel in interacting with a wide variety of users with a broad range of technical expertise, quickly building rapport, and driving technical issues to a resolution. SEs, on the other hand, need to lead in-depth technical conversations with users across this same spectrum of technical aptitude, adjust their demos on the fly to address customer questions and objections, and serve as a technical resource for the AE.
Overall, the difference between customer engineering work and SE work is largely a matter of focus and purpose. The purpose of your work as a customer engineer is to resolve customer technical issues as effectively as possible, while the purpose of your work as an SE is to remove technical barriers and assist the AE in landing new customers. I mention this because this mindset shift, in my opinion, is the trickiest thing for a moonlighting customer engineer to nail. To be an effective SE, even if only for a few months, requires learning the rhythms of the sales process, learning the lingo of the sales team, and learning when to defer to the AE and when to step in. None of this will necessarily come naturally to you if you haven’t spent any time as an SE in the past. Pay attention to the feedback you get from the AEs you’re working with, and you’ll get the hang of it.
Splitting your attention
Your SE tasks are somewhat unique in the gamut of non-support tasks you may have insofar as they may, in fact, be more important than what you’re doing in your day-to-day as a customer engineer. Why? Customer acquisition, that’s why. Though of course not every founder will agree with this, when given the choice between solving an existing customer’s problem and gaining a new customer, tiny startups are often going to choose the latter. Unless a support issue is pressing enough that you’re in imminent danger of losing the customer, it is always going to be more important to the business to bring aboard new customers. So if you have a conflict between addressing a customer issue that just came in and running a demo, or helping an AE close a new customer, you’re probably going to be focusing on the revenue-generating activity. I’ll caveat this by saying every startup is different, and your leadership team may prefer that you focus on existing customers. But it’s more likely that your priority list is going to look something like this:
Critical customer issues (i.e. you might lose a customer over this)
Customer-facing SE-related tasks (e.g. demos, POV work)
All other active customer issues (they need to be solved, but can wait until critical SE work is done)
Other customer engineering tasks (bug and feature request reporting, documentation, etc.)
Other SE-related tasks (onboarding guides, SE procedures, demo scripts, hiring/training new SEs, etc.)
When real SEs are hired
You’ll probably be in charge of training them, at least on the technical side. Like I said before, the technical skillsets are going to be largely the same, so you are going to be best placed for the initial technical onboarding of new SEs. After all, you’ve been doing the job for some period of time already. To prepare for this transition while you’re functioning as an SE, you should also be laying the groundwork:
Getting the demo script locked down: While the demo is constantly evolving, it’s important to have an established script that new SEs can learn and, eventually, improve upon.
Preparing an objections document: As you meet and overcome them, write down common technical objections and your responses. This will be invaluable for new SEs to refer to as they are gaining technical knowledge of the product.
Building a technical onboarding plan for new SEs: What do they need to learn? In what order? What’s the best way to learn? How quickly should they be learning? All of this information can be found in the onboarding plan and will give structure to your onboarding process.
If all of this is in place, you will have a clear and straightforward path to bringing the new SE(s) up to speed quickly. Keep in mind while you’re doing so, however, that you’re not the only one to onboard the SEs. Just as important is the onboarding they will receive from the AE side, since that’s where they’ll learn everything else they need to know about the business side of the SE role. Take this into account, and work with the Sales team, to ensure your onboarding plan doesn’t neglect that side of onboarding as well.
Once the first class of SEs are trained up, don’t get too comfortable—even though you’re probably off the hook for regular SE work, that doesn’t mean can put it out of your mind entirely. You’ll still be a technical backstop for issues that the SEs may encounter during the POV process, and you may be called on to pinch-hit if the SE team is overbooked or otherwise understaffed. Still, these lingering tasks will get less and less frequent as the SE team gains maturity.
One last piece of advice: remember the skills you built in your stint as an occasional SE, and keep up the relationships you built with the sales team and with the SEs you helped train. There is a lot of cross-pollination between customer engineering and sales engineering, and your teams will be able to learn from each other—and possibly transfer from one team to the other—far into the future.
Next week: guess what? You’re also going to be handling customer success.
Thanks for reading Andy's Support Notes 💻💥📝!