Hiring your first Support Professional

We talk a lot about support on this blog. Obviously. But we also talk to support, for the most part. We write largely for an audience of Support Professionals at all levels within an organization, whether they're leaders or individual contributors or managers. Sometimes we write about how we're building Yetto, which is primarily for engineers but is also interesting to a lot of tech support folks.

In this post, I'd like to stray a bit and talk to early company leaders and founders. These are the people who are primarily doing support work at the first stages of a company, when there is no dedicated support team. They are usually the ones responsible for hiring the first Support Professional into the company and setting the path of the team at its start.

Hiring your first Support Professional can be tough. You have to know when to do it, first of all. Which means you also have to know why you need to do it, and what skills you're hiring for. All the while, you have to be thinking much further ahead than your current (often pressing) needs, because the future of the team will be based on the decisions you make before the team exists.

It's a lot. I've seen it go wrong several times. Fortunately, I've also seen it go right several times. And so, my fellow founders and CEOs, I offer some advice on how to do this well.

Know when you need it

Way too often I talk to a tech founder who has built a great product and a growing company and still hasn't hired a support team. Five people at the company? Sure, you probably have someone handling support as part of their daily work, but you likely haven't hired a support person yet. Even though I think that might already be getting too late, it won't break anything. Twenty people? Okay, but it depends on the product and business. It's starting to be a problem if you don't have a full-time person handling support when your company has around 50 people. But I've seen companies where the first support hire wasn't in the first hundred people.

That's shocking. I was shocked.

Here's a rule of thumb. When you find yourself or other people in the company spending more than 50% of their time each week responding to and working on support questions, it's time to hire someone. It's taking away from the things that they are ostensibly hired to do (build the product, or sell the product, for example). At that point, you should hire someone specialized in support to take on that work full time.

I often get some push-back here. "Why hire a full-time person if it's only taking half of my time right now?" "Why hire someone to handle support when what we really need is customer success to help with onboarding?" "I want the engineering and product teams to talk directly to customers, and hiring a support person will move them further away from the people using their product."

Look, none of those points are completely wrong. But they're all missing the point. If you or someone else at the company is spending twenty or more hours a week handling support requests, and you (or that other person) are not a seasoned Support Professional, then there's likely way more than 20 hours of work to do every week. You don't see it, though, because you're likely focused on a couple dozen other things and the support queue is mostly being addressed.

A Support Professional will see things that you don't. They'll see problems that haven't gotten big enough to make it to your desk yet. They'll find gaps in the product and in internal processes that you didn't think to look for. They will find all of these things and they'll know how to start addressing them.

You should hire your first full-time support staff long before you think you need to. Don't wait until it hurts, as most founders and early leaders do, because it will be much more painful (and time-intensive and costly) to dig yourself out of that metaphorical pit than you think.

Know what you need

You've decided to hire someone to take on the support load. Terrific. Chances are high that you don't know what that person will be doing yet, though, and you have no plans for onboarding them. These are solvable problems, they just aren't often solved before hiring that first person. In order for this person to be successful, and for your businesss to be successful, you should think real hard about what you need the support person to do.

Early on it's easy to say, "I need a support person because I have a lot of inbound support email to deal with." But "answering tickets" is not a complete job description. And it's woefully inadequate for describing the work that first support hire will be doing.

They'll be talking to customers, relaying information back to the rest of your company, taking information from the company to the customer, finding all the ways the current product (whether it's software or hardware, a product or a service) is not meeting customers' needs, and trying to turn all of that into useful recommendations towards business and product strategy. The day-to-day work that early in a company's life is deep and broad. The first support person will need to be an expert on every edge of the product in order to talk to customers every day and sound like the voice of the company. And they'll need those customer conversations to reflect back into the product, so they'll need to know how each of those edges operates in fine enough detail to help steer them towards what customers want and expect.

Planning this out early and hiring for the skills you need will alleviate some of those other concerns you may have had. For the founder who's trying to keep their product and engineering teams talking to customers, a good first Support Professional will give everyone the time to focus on the things they're good at, like building the product. They'll also know when to bring the product and engineering teams into customer conversations, so that nobody is losing touch with the customers but nobody is wasting their time in conversations that don't give them deeper insights or help them make better decisions.

The first support hire is someone who can build the team with you

On top of all of that, this person is going to be the first person you turn to when it's time to build out the support team. Support Professional numbers two, three, four, and beyond. The first hire is instrumental in setting the standards of operation for the team, onboarding and training new team members, and deciding who gets hired into those early positions.

Make sure this person could be a stellar individual contributor and a great manager. It can be tricky to find someone who fits that description, but now you need to find someone who fits that description and can learn your particular product quickly and support your customers. You'll probably still be working in the support queue alongside this person for a little while, whether that's a shared inbox or Slack channels or phone trees. You need to rely on them to become the voice of the company in your place for most customers. But you're only onboarding the first hire, they're onboarding the next batch.

I don't say all of this to scare anyone or make the task seem more daunting than it is. You need to be fully aware of the role and challenges before interviewing and hiring someone. Once you have a firm grasp of the skills needed and of the possible future team this person will help you build, you'll be able to write a job description tailored for the role you need to fill. Too often I see job descriptions that are overly vague in what the first support person will be doing ("helping customers!" and "responding quickly and accurately!") and overly specific about things that ultimately don't matter that much ("exceptional writing skills" and "ability to solve puzzles"... I wish I were joking). Be clear about what you need and what you expect. Do they need to troubleshoot issues in your Node app? Do they need to have experience recruiting and hiring? Say that!

This person will be the voice of the company to customers, the voice of the customer to the company, and the foundation of the future support team. Make sure you know what you want that person to be able to do, and set those expectations up front as clearly as possible.

The shape of a team

When it is time to build the team out, the first thing you need to do is sit down with that first, lone Support Professional and decide what the shape of the team should look like. I've heard founders say that what they really want is to clone that first support hire to build out their team. They try to hire the next two people who look as much like that first one as possible. They want all of those same strengths.

Unfortunately, that kind of hiring results in all the same weaknesses. You don't want to hire by mimicking previous hires. You want your team to have a collective group of things they are good at. Maybe you need some people to be great at infrastructure debugging and DNS questions, while you might also need some people who can find and replicate all of the UI issues your users will find in your app.

On the other side of the coin, there will be some things that the team doesn't need to be good at. What are those things for your team? What is high value and what isn't? Where can you sacrifice some weaknesses to get some extra stengths?

Consider the team as a growing, evolving unit with a broad set of skills. You can't and shouldn't expect any one person to be great at all of the things the team needs to do. At the same time, you should expect each person to be weak in some areas. Make sure people's weaknesses are covered by other people's strengths when those areas are important to your business. Like I always say, support is a team sport. You're building a team when you hire, not hiring individuals who will work in isolation.

Giving up the reigns

Lastly, you need to know what your role on the team is.

You've built the team a little. But you're still in the queue with them. You've always answered customer emails. Even if you're only doing them for an hour every Tuesday morning, you're going to stay in the queue.

Stop it. Please. Get out.

If you can't devote half of your time to the support queue, you shouldn't spend time in there every week. You don't have the context to respond to customer issues directly anymore. That's alright. It's good, in fact. You now have a group of people who do have the context and who you hired because you trust them to represent the company's voice when you're not around. Let them do that. There are better ways to spend your time and you're only frustrating the team trying to work through the queue with them.

There are some founders who refuse to give up their support work long after they need to. However, there are far more founders who give up the daily or weekly support work but still manage to frustrate the support team. Let's say you have a small support team at a company of about a hundred people. They're working the support queue all day every day, weekends included. But one customer is unhappy and reaches out to you in a LinkedIn message. Do you immediately go to Slack and paste that message for the support team, telling them to go take a look at this customer's problem? Do you immediately prioritize that to get it off of your plate?

Most leaders do exactly that, and it's a pattern of behavior that shows a lack of trust in the support team you've built. Customers reach out to leadership directly because they know it works to short-circuit the normal communication channels. Leaders who trust their teams will tell the customer how to best get in touch with support and let it go from there. If it's a high priority issue, the team will have a process for dealing with that.

Let them do their job so you can focus on yours. That's what you hired them for. You hire the first Support Professional, and you start building your support team, because you need their help and their expertise. You need people to help customers with the product and to help the business learn from the customers. By following all of the steps above, you've created a team that knows the product, knows the business, and knows the customers. Now it's time to let them do that work while you focus on building the business.