Moonlighting as (almost) everything else
The Swiss Army knife of employees 🇨🇭
Over the last few weeks we’ve talked about some of the extra roles that a founding customer engineer might take on in a small startup. Because the support engineer may be the only technical customer-facing person in the company, they’re often pressed into service to cover sales engineer (SE) and customer success (CS) functions until the company is big enough to hire dedicated SEs and customer success managers (CSMs). But while those are the most common side gigs for customer engineers, there are plenty of other places they can make themselves useful. This week let’s look, more briefly, at a number of other functions that customer engineering may find themselves doing for a few months, or years.
Onboarding / deployment
Just as SEs are almost the same as customer engineers, except with a change in focus and motivation, deployment engineers are another twig on that same branch. Helping a new customer go from zero (or, only marginally better, a trial deployment) to a full production deployment can be a long and involved process for some products. The same skillsets come into play too: a willingness and ability to work directly with customers, a deep knowledge of the product and its rough spots, and a certain tenacity and drive to solve customer problems. Therefore, it’s no surprise that in smaller organizations customer engineers are often responsible for the full customer deployment journey. This requires working closely with the onboarding customer and their assigned CSM, which is of course easier if you’re that CSM, to ensure that at the end of the onboarding period the product is fully deployed, the initial customer user base is trained in at least the basics of product usage and administration, and any ongoing issues are communicated back to the CSM and to the customer engineering team, which is also much easier when it’s you.
In a larger organization, the product deployment phase is handled by dedicated deployment engineers, or by technical account managers (TAMs), which by no coincidence is next on our list.
TAM
TAMs are much like support engineers as well, except with a stronger focus on building relationships with specific customers and helping them overcome technical hurdles and successfully implement their product use cases throughout the lifetime of the customer. This should sound familiar by now—in many ways a TAM is simply a customer engineer who’s also doing CS work, so of course this is a persona that the customer engineering team will likely have to take on at some point. I also mention this role because, once your company starts hiring TAMs, your team will almost certainly be charged with technical training for them at first. Customer engineers know everything there is to know about the product and troubleshooting it, and by this point you’ll also have a deep understanding of your customer base and their needs.
QA
Going a little farther afield from ‘customer-facing technical roles’, customer engineers are well-positioned to handle quality assurance (QA) tasks. Because they’re probably already submitting well-formed bug reports and feature requests, customer engineers are well-placed to validate whether a purported bug fix actually resolves a reported issue, or whether a feature request is in fact satisfied by the latest software update. How this functions in practice is going to be dependent on how your engineering organization is set up, but at a minimum early customer engineers should be notified when new product code is available, validate that the fix or new functionality is in place, and approve or deny the broader release of the new code.
If the support team has more capacity, and if the product is small enough (both are common situations in very early startups), they can be tasked to do more comprehensive QA. While automated testing is probably already in place for product updates, it can’t catch anything it’s not specifically designed to test, and that’s where a human QA function comes in. Working with the engineering and Product teams, the support team can build a standard deployment and functionality checklist. For every new code release, whether or not it contains support-relevant bug fixes or requested functionality, customer engineers can then run down the testing checklist, ensuring no glaring bugs or regressions have found their way into the new release. While nothing can replace a dedicated QA function, the support team is well placed to do basic sanity checking to avoid embarrassingly broken product releases.
Documentation
I saved this one for last, because if the support team is ever responsible for product documentation, it’s a task that will probably stick with the team the longest. Full-time writers and editors (outside the marketing team, anyway) tend to be late hires at software startups, so prepare for the long haul if your team ends up in charge of writing, updating, or otherwise improving product documentation.
On one hand, assigning responsibility for documentation to Support seems like a natural fit: customer engineers know everything there is to know about the product and are comfortable with clear technical writing, thanks to regular customer correspondence. On the other hand, documentation writing is a somewhat different set of skills: instead of speaking to a specific customer for a specific purpose, documentation needs to be broadly usable. It is long-form writing that needs to be precise, accurate, and also stylistically consistent across dozens or hundreds of documents. Not everyone has the facility, or interest, to write good documentation.
If you are a founding customer engineer with strong writing skills, you will probably be responsible for documentation at some point, which means your team, as it grows, will also share that responsibility. Make it easier for yourself, for your future team, and for a future dedicated technical writing team by writing a style guide, constructing a good and intuitive documentation structure, and generally laying the groundwork for future documentation expansion.
I started this post somewhat facetiously with a picture of a Swiss Army knife, but it turns out that’s a pretty accurate metaphor. Like a Swiss Army knife, as anyone who’s ever owned one knows, customer engineers are good at a few things (the knife blades), OK in a pinch at a few others (screwdriver, corkscrew), and marginal at best at several others (why do they bother putting tweezers and a toothpick in there anyway?). While you’re extremely versatile, don’t forget why you were hired in the first place, and cut yourself some slack if you’re not as good at customer success as a dedicated CSM, not as speedy deploying new customers as a TAM, or as efficient at writing documentation as a technical writer. As your company grows, you’ll spend more time focusing on your core duties, but the skills you picked up while helping elsewhere in the company will serve you well going forward.
Thanks for reading Andy's Support Notes 💻💥📝!