Leading a team when you can't do the job
Where do you start?
One of the points I harp on about leading a team is that you need to be able to do the work yourself. If you can roll up your sleeves and pitch in, it helps build credibility when you’re new to the team. Once you’re established in your role, you can model the behavior and habits you want to see from your team by regularly stepping in to handle tickets yourself. And in a pinch, you’re able to cover support duties when your team members are out or you’re otherwise understaffed.
But unfortunately, it happens sometimes: you’re hired, or cross-promoted, into a leadership role where you’re managing folks doing work you don’t entirely understand. There are any number of situations where this could happen, but since this is a support leadership newsletter I’ll focus on two common scenarios:
Cross-promoted from a non-support background
Hired to manage a team supporting something you don’t understand
How to approach each of these two potential disasters is different, but what remains the same is that your first focus needs to be on managing the team. Once you put out any immediate fires and things are humming along relatively normally, it’s time to give yourself a crash course in the fundamentals of customer engineering, or your specific company’s products and technology. If you need help with both—what, were you hired by mistake or something? Good luck, and I suggest starting with the first section. You need to be able to lead customer engineers first, before trying to learn the tech.
Cross-promoted?
So here’s the situation: you have management experience, but have never led a customer engineering team. You’ve been cross-promoted from an adjacent team, say, customer success (CS). Since you’ve been with the company for a while already, you have a pretty good understanding of the product and its ins and outs. But since you don’t have experience leading a support team, or being a support engineer, you’re somewhat at a loss for what to do next. It’s hard to tell what’s working and what isn’t in the support organization, because you don’t have a mental model for what ‘good’ and ‘bad’ even mean in a customer engineering context. So it’s time to build up that context.
Talk to your team: Your first learning priority needs to be what does this team do, anyway? I mean, you already know ‘tickets go in, solutions come out’, but there’s obviously a lot more nuance to it than that. Sit down with every member of your team and get everyone’s perspective on team operations, both the what and the why. A few things to find out:
What occupies their time
The processes and procedures they rely on
Which processes and procedures are helpful and which are not
What they believe is the purpose of the support team
What they believe is the role of leadership in the support organization
Their thoughts about how things are going and what changes should be made, if any
Talk to other leaders in adjacent teams: How your own team feels about the role of the support organization is obviously the most important, but almost as important is how other teams see the support organization. What points of interaction are important? Where are the common sources of friction? How can the support team make their lives easier?
Do some shadowing: You’ve got some of the theory down, so now it’s time to start looking at how things actually function in practice. Shadow everyone on your team for a few hours, and observe them at work:
Interacting with other teams in the company, answering questions and looking for assistance in turn
Investigating reported issues and reproducing bugs
Exchanging messages with customers in support issues
Working live with customers on troubleshooting or informational screen-sharing sessions
Take some tickets: From conversations, to observation, to actually doing the work. Walking a mile in someone’s shoes is a cliché for a reason. By interacting directly with your customers, your team’s tools, and your partners in other parts of the company you’ll learn more about the support engineering world than dozens of interviews and mountains of research. You’ll certainly have lots of questions and observations as a result of this experience, which leads directly into your next task.
Repeat: Now that you’ve gotten some hands-on experience with doing the work of a support engineer, your perspectives on your team and its functioning have probably clarified somewhat. Take this new perspective and run through the whole process again. You’ll be able to learn more now that your discussions are informed by actual experience.
You’ll know you’ve internalized the support mindset when you find yourself in the position of both understanding how your team works and starting to understand where it’s falling short and needs some changes. So what are you waiting for?
Don’t understand the tech?
Now let’s look at another scenario: you’ve been a successful customer engineer, and manager, at another organization. But now you’re leading a customer engineering team that works with a product you has absolutely zero experience in. Worse, it’s in a totally new field to you. You’ve got a good feeling for the rhythms of support, but you can’t provide granular advice to your team on handling difficult technical issues with the product they’re supporting. How can you quickly come up to speed?
Talk to your team: Just like the last scenario, your first step should be to have a one-on-one conversation with everyone on your team. You’ll want to get everyone’s opinion on:
Strengths and weaknesses of the product
Common customer use cases for the product
Comparison to competing products, if any
What’s easy/difficult to support in the product
Quality of documentation and other supporting materials
Talk to other technical teams with extensive product knowledge: Your team of customer engineers knows a lot about the product they’re supporting, but they’re not the only source of information you should be tapping into. Ask the same questions as above to other people who are working with the technology: engineers, sales engineers/architects, technical account managers, product managers. The more perspectives on the product and its strengths and weaknesses, the more well-rounded your own viewpoint will become.
Start using the product yourself: Simultaneously with the above conversations, you should be independently playing with the product. What is the experience setting it up? What is the end-user experience? What do you find easy or difficult about using the product? How is the documentation? Getting the end-user perspective is vital now, while you’re still inhabiting the role of a complete novice. Take lots of notes—they will be useful to your team, and to the Product team.
Study and learn the underlying technology: Once you’ve got a handle on the specifics of the product or products you’re supporting, it’s time to dive deeper into the larger ecosystem. If your product leverages Kubernetes or goes deep with Amazon IAM, for example, learn about those technologies. Get an introductory-level certification if one exists. This in turn will give you a better understanding of the technical underpinnings of your company’s products and open up new avenues for technical troubleshooting when things go wrong.
Do some shadowing: Also like in the previous scenario, you should be shadowing more experienced engineers on your team, but this time you should be focusing on how your team troubleshoots and supports this product specifically, rather than the mechanics of the support process (barring any glaring process issues, of course). And once you’ve absorbed enough of your team’s support methodology, it’s time to put that knowledge to the test.
Take some tickets: There’s no better final exam than actually fielding live support issues. Make sure that a more experienced support engineer is checking your work to make sure you don’t accidentally send a customer down the wrong road, of course, but this experience will both cement the product knowledge you’ve already gained and reveal remaining blind spots where you need to learn more about specific product features or oddities.
Repeat: You now have enough knowledge to stumble your way through an on-call shift, but that’s not enough. Keep learning the product, keep absorbing more technical information from your team, and you’ll soon find yourself sufficiently up to speed.
Fully learning the product is of course a moving target, and for many software products it’s impossible to know absolutely everything, but as long as you understand enough to take the occasional support shift, you’re doing well. You’ll be able to more effectively mentor new members of the team, and take a more active role in suggesting bug fixes, functionality improvements, and new product features.
Thanks for reading Andy's Support Notes 💻💥📝!