Leading a technical support team
Just don't be a jerk
This is something that’s been on my mind a lot lately: as a support leader, what exactly is your purpose? What are you there to do, really? The short, glib answer is easy to reach for: leading your team and ensuring it performs well. But that doesn’t give you much to hold on to when it comes to arranging your day to day activities and when confronting tricky management problems. There’s plenty of advice out there about being a good manager, and what you should be spending your time on, but that’s not what I want to talk about today. Instead, let’s look at advice specifically to someone a) on a customer engineering team; b) in a leadership role.
Basic dos and don’ts
Let’s start by looking at a few contrasting approaches to team management. I don’t think any of these will be particularly controversial, and none of them are specific to customer engineering, but they’re an important background to the next section: where support leadership tends to go wrong.
- Don’t let your team sink or swim. That is, don’t just throw your team into the proverbial deep end without preparing them first. Though hands-on work is the best way to learn the role, especially in a troubleshooting-heavy role like customer engineering, there needs to be guidance and effective guardrails to prevent serious errors.
- Do provide an effective onboarding. Give your new engineers all the tools they need to succeed, and all the assistance you and your more experienced team members can provide as the onboarding progresses. Call recordings, shadowing, extensive internal documentation—the better prepared your new engineers are, the more likely they are to succeed in the role rather than burning out.
- Don’t lead by edict. There’s nothing more demotivating than a new task being imposed from above with no context, no dialogue, and no room for feedback. As a leader you can simply tell your team to do things, but it will breed resentment. This is even more true on support teams: you’ve hired independent thinkers who are paid to ask questions. They’re not going to do well with autocratic management.
- Do lead by example. Contrary to the above, solicit advice and respect your team’s opinions. When there’s a change in policy or your team’s processes, lead the way in learning and mastering the new process. If your team has an on-duty rotation, take a shift yourself. How can you expect the rest of your team to do the tedious parts of the job if you’re not willing to take part yourself?
- Don’t be a crutch. Sometimes deliberately, sometimes accidentally, many team managers end up propping up their team. They take over any task as soon as there are difficulties, they don’t train their team to handle more involved problems, and they prevent their team from picking up new skills to handle novel situations. While sometimes it feels easier to just take on tasks yourself if your team member is struggling, this will cripples your team’s capacity and confidence in the long run.
- Do provide a secure foundation. Once your engineers have been fully onboarded, they’re capable of handling 80-90% of inbound support requests more or less independently. But there’s always going to be a certain percentage of issues they can’t manage on their own. Be available to assist with those, even if you’re just pointing them to the proper resources. If your team members have the confidence that you can help when needed, but won’t jump in and take over entirely, they will in turn have more confidence in their own ability to handle whatever comes at them.
- Don’t be invisible. Stepping back and letting your team work doesn’t mean vanishing entirely. Always be available as a sounding board and offer assistance as needed. Regularly meet with your team, both one-on-one and in a group. Provide feedback, both positive and negative, and be present to guide your team in the direction it needs to go.
- Do be a shield. In my opinion one of the most valuable functions a manager can provide is to shield their team from outside interference as much as possible. If an edict comes from on high that will be detrimental to your team’s functioning, or the well-being of your employees, it’s your responsibility to advocate against it and mitigate its negative effects as much as you are able. If a team member is having trouble with someone elsewhere in the organization, you need to do what you can to address those issues rather than letting them fend for themselves. Protect your team and let them do their jobs with as little interference as possible.
Common pitfalls
These are patterns we see again and again as support leaders, simply due to the nature of our skills and inclinations. As support professionals, we above all want to solve customer problems, which is the root of all of these mistakes! Now that you’re in support leadership, you are probably also coming from a support background or a closely related field, and you’re probably going to be prone to them as well. Harken well!
Micromanagement
In the race to resolve customer issues as quickly as possible, you’re going to be tempted to step in yourself when you see one of your engineers struggling with an issue. And because you probably have a significant background in support or other customer-facing roles yourself, you’re going to have strong opinions about how to interact with customers, how to conduct troubleshooting, and how to manage and prioritize your issues. If you’re not careful, this will swiftly lead to micromanagement. You have more experience, after all. But as I alluded to above, you need to resist this impulse. If you closely manage everything your employees do, one thing will happen and one thing will not. Your team will fail to grow and adapt, because you’re dictating everything yourself. But what will happen is that your team will grow to resent this micromanagement. They have the same drive you do: to solve customer issues. If they’re not actually able to do that without you jumping in, they’ll lose motivation and will eventually look for a role where they can actually do what they were hired to do.
Lost in the tactical
Solving customer problems day in and day out is the name of the game, but it can be difficult to take a step back and look at the bigger picture. It’s very easy to get lost in the details, in the specific customer issues your team is working on, and forget that as a leader you have important things to do: note trending topics in the issues your team is working on, build relationships with other teams, and plan your team’s evolution over the next quarter (and year). It’s important to spend time in the trenches with your team, but if you are never getting out of that tactical mindset, you won’t be able to properly manage the support function your team is providing.
Excessive deference
One subtler way that drive to solve issues can manifest itself is to be overly deferential to others: if, for example, Sales comes to your team with a request to do things differently, it is natural to want to help them out and accommodate their request. But this would be doing a disservice to your own team: you (and your team members) know the support function best, and need to evaluate all of those requests (and sometimes insistences) on their own merits rather than simply agreeing to them. As an extreme example, it would undoubtedly be easier for Sales if you included a customer’s account executive (AE) on all support calls, because the AE could then subject the customer to an impromptu sales pitch when all they want is to get their mail server settings right. But a moment’s thought will tell you that this is a terrible idea from a support and customer satisfaction perspective. While most requests from elsewhere in the company aren’t so cut-and-dried, the principle remains. Don’t let your desire to help stand in the way of doing the right thing for your team.
Do these things instead
I’ve spent most of this post talking about general management guidelines and specific things not to do. When am I going to get to talking about what you should be doing as a support leader? All right, fine, here’s some affirmative advice.
Let your team members do their jobs
For every member of your team: remember you hired them for a reason. (And if you can’t think of a reason you hired any specific person beyond ‘they were available’, that’s a sign to look closer at what they’re doing on your team!) Trust that reason and let them do their jobs with minimal interference from you. On the flip side, if you brought them on board for their troubleshooting acumen and recognize that they can use some help with customer empathy, don’t hesitate to provide that support if it’s needed. But, in short, ‘hire them and get out of their way’ is the right way to deal with the kind of professionals you should be trying to hire.
Listen to your team
As a corollary to the above: everyone on your team has expertise in one or more skillsets that are crucial to your team. When they have something to say that’s relevant to those areas of expertise, listen to them. If you ignore their input, you’re wasting the money you’re paying them. This doesn’t mean that you need to take all of the advice everyone on your team gives you—quite often you’ll get contradictory suggestions from different folks on your team—but it’s important to take that advice into account when making decisions.
Remember you’re a manager, not a peer
Most support leaders are perfectly capable of doing the jobs of the folks beneath them, due to background and inclination. But as I mentioned above it’s a mistake to start thinking of yourself as a peer to the rest of your team. You’re responsible for team leadership, team direction, and the professional well-being and development of everyone on your team. You won’t be able to effectively do any of those things if you’re not focusing on your managerial and leadership tasks. Moreover, even if you’re thinking of yourself as a peer, rest assured nobody else on your team feels that way. They’re not going to forget you’re their manager, even if you do.
Think back to all the managers you’ve had through your career. What do you remember about the bad ones? They probably micromanaged you, were indifferent to or actively hostile towards your career aspirations, and didn’t understand what you did every day. On the other hand, which are the ones you remember fondly? The ones who helped you grow and didn’t make your job harder. Be the kind of manager you’d like to have yourself, and that will get you a long ways towards being a better manager than most.
Thanks for reading Andy's Support Notes 💻💥📝!