Starting a support team from scratch
If you wish to make an apple pie from scratch, you must first invent the universe
You’ve just been hired to build a new support team! This is a tremendous opportunity, but also a tremendous responsibility. You need to:
Establish and systematize a support process from zero, or near zero
Successfully transition support issue handling from whichever overloaded early hire or founder was already handling it
Plan ahead for the future growth and success of the support organization
What, isn’t that enough already? Fine, one more: build relationships across the organization that you and the rest of your future team will rely on for years to come
Building a new support team from scratch requires a specific mindset, one that I’ll refer to throughout as builder-leader. What do I mean by that? Well, at the beginning, you’ll need to be primarily a builder. Building processes, building relationships, building strategies to bring your team through the next phases of company growth. At first you won’t have anyone on your own team yet to lead, but you’ll still need to lead throughout your (likely small) organization. Advocate for support as a first-class component of customer retention and product improvement, and as a strong selling point for your sales organization. Train Engineering and Customer Success to trust your team when it comes to the intersection of customers and technology. Once you’ve established your and your team’s charter, processes, and bona fides, it will be time to amp up the leadership and dial back the building as you prepare to build the team out according to your company’s scaling plan. But you will continue to rely on both halves of the builder-leader split throughout the establishment of the support team.
Now, if you haven’t already done so, read last week’s post on starting as a support leader. Done? Great, let’s continue from there. You’ll want to do all of those things, but with wrinkles specific to this particular situation. Let’s go through the specific things you’ll want to do to be successful as a builder-leader.
Learning the product and learning to support it, redux
Unless your company has no customers at all, somebody has fielded some sort of support issues already. Find out who handled those issues and go talk to them first. Maybe it was an early engineering hire, maybe it was a founder, maybe it was a founder’s dog. Whoever it was, sit down with them and find out:
How have you been handling support issues? Do you have an email address, a ticketing system, a Slack channel?
How is your existing process, if any, working? What’s not working as well?
What’s the current support load you’re dealing with? How many issues in a typical week? What’s the mix of simple and complex issues?
What knowledge base is needed for someone (like me) to successfully address 75% of support inquiries? What additional training or practice is required for the remaining 25%?
Most importantly, what expectations have you already set with your customers regarding support? Is there a defined SLA or other contractual guarantees? Have you committed to specific hours, days, initial response times, communication modalities?
Once you have this information under your belt, you’ll have a good understanding both of the existing support process you need to learn and systematize and of the level of effort you’ll need to expend to understand the product well enough to step in as a replacement for whoever has been handling support and is ready to offload it to you. Once you get to 75% you’ll be able to take over day-to-day, only occasionally escalating to the previous support victim engineer, and you’ll be able to phase out that escalation as you master the remaining 25%.
Working with other teams, redux
As a part of your initial research into existing support practices, pay close attention to how other teams come into support issues. Are tickets thrown directly to engineering resources? Does customer success step in and handle some issues directly? How are handoffs communicated and discussed, if at all? It is very important to systematize these handoff points because, as the company grows, these are the places where inter-team friction will develop. If you formalize your interactions with other teams, with buy-in from leadership and the ICs on each team, it can be internalized and effectively conveyed to new team members as the company grows. If you neglect these points now, the negative effects may not be immediately apparent. But you’ll pay for it down the road with confusing and implicit guidelines that are understood differently by everyone and not consistently enforced.
Start building for the future
As I alluded to before, one of the reasons you were hired was to look to the future when you’re not handling all the support issues yourself. As you onboard yourself and gain product and support knowledge, it’s critical to take time to reflect periodically about what you want support to be like in this organization once it’s more than a one-person show. The insights you gain while onboarding are hugely valuable, so be sure to record them while they’re fresh.
What does good support mean here?
What do customers expect? What would make them happier?
What hours are you providing support? Do you expect that to change in the future?
What is driving the typical support load you are seeing? How do you expect that load to change as your company grows and onboards new customers?
Given all of the above, what should your team’s growth plan look like?
While pondering the above, make sure you are regularly communicating your questions and findings to your own leadership, up to and including the CEO. A functional and comprehensive support program has a multiplicative effect on organization-wide success, so it is important to gain executive buy-in to your plans. Learn what growth they are planning for over the next 3, 6, 12 months. Ensure that your own plans, as they start to come together, are aligned with and ideally part of the overall company growth plan.
Getting ready for scaling
Okay! Now that you’ve made it this far, it’s time to start putting all of that planning into practice. Take a look at the guidelines for hiring support engineers below, and begin to think through your hiring process now, rather than when you actually need it. When the time comes, you’ll be ready to get scaling.
Support titles: what's in a name? • Buttondown
Rosa rosa rosa est est
Hiring support engineers: the skills • Buttondown
... to pay the ... well, you get it
Hiring support engineers: preparing the process • Buttondown
Thinking about preparing to initiate a plan to devise the blueprint to...
Hiring support engineers: the interview process • Buttondown
FINALLY
Hiring support engineers: onboarding • Buttondown
Baby engineer on board
Thanks for reading Andy's Support Notes 💻💥📝!