Managing Technical Support Teams

Managing Technical Support Teams – D M Goldstein, April 2022

Some people may think that being a manager is easy; you hire, fire, and give reviews. You tell the team what to do, and they do it. But in life nothing is simple, and Management is no exception. It is part science and part art, part process and part psychology, part parenting and part mysticism. You can spend years pursuing post-graduate-level degrees and reading thousands of books and articles on this, with the hopes of mastering it all. That is not the purpose of this article. This article is a collection of thoughts and lessons I’ve gleaned while building and leading software technical support organizations. Think of this as “Support Management 101”.

Controls and Levers

As a services manager, you have three factors under your control:

• People: I once had a boss whose motto was, “Hire the best and then get out of their way.” In a services business your “product” is the time and skill of your people. For the best product, you must hire great people and train them well, then ensure that they have an environment where they can succeed. You drive improvements through the professional development of your people, including improvements and enhancements to how you train and develop them.
• Process: What your people do and how well they do it are a function of your processes. A well-written process tells the reader not only What to do, but How to do it and Why you do it; it also must have a mechanism to handle exceptions. Well-written processes can ensure consistent performance, aid in training, and provide a mechanism for continuous improvement. The absence of them can cause random performance and introduce confusion and chaos. Drive improvements by measuring the outputs of your processes and looking for opportunities.
• Tools: Even the best craftsmen need appropriate tools to do their best. The tools vary based on what your team does, but may broadly include software such as case tracking tools, documentation, other forms of training, and appropriate equipment like computers and phones. It also includes automation to reduce staff effort, such as Self-Service Community Portals and Knowledge Bases. Working with sub-optimal tools can be highly detrimental to productivity. Drive improvements by considering whether your tools are helping or hindering your team, and what you should add or change to provide your team more time or efficiency.

Increases to any of the above factors requires budget. It is important to have a forward-looking plan for where and how you plan to expand. You need to understand your performance metrics and get a realistic view of what kinds of tools and process improvements will produce worthwhile results – where “worthwhile” means improvements to customer satisfaction and reduction in overall long-term costs.

Similarly, you have three levers with which to meet your objectives:

• Resources: If your workload is increasing, either due to organic growth or from adding new services and products, one way to address this is by adding resources. While that usually means more people, it could also be accomplished with process improvements that free up time for your existing staff, or by adding automation and other tools which reduce the need for manual human effort or intervention. These are the three control factors above, which all require budgets to acquire.
• Schedule (time): If adding resources is not an option, what flexibility do you have with time? Can you take longer to deliver, allowing you to spread the load over non-peak periods? What are your financial risks if you extend or miss your Service Level Objectives (aka SLAs)? Is there any benefit to reallocating your existing team into more shifts so you can leverage “quiet periods” to absorb load from peak periods?
• Content (features, offerings): If demand is increasing and you cannot add resources or extend delivery times, your third lever is Content. What work are you doing that you can stop doing? What low-demand or expendable service can you stop providing to maintain your ability to deliver on a high-demand one? Can you drive your low-value customers to a Self-Service Portal to reduce demand on your human resources? Is there flexibility to lower the quality of the service to accommodate higher volume?

If your team is fully utilized, then it is not possible to expand Content while restricting or reducing Resources and Time. Similarly, you cannot reduce Resources or Time while maintaining Content levels. Understand what you are truly capable of delivering, as well as what trade-offs you will need to make to meet such demands. Regularly think about your three levers and where you can drive continuous improvement.

Metrics and Forecasting

To successfully manage the control factors and levers above, you must be able to measure them. My article “The Seven Rules of Reporting” provides the following guidance on how to approach metrics and reports:

1. Ask the right questions.
2. Context matters.
3. Use the appropriate measurement methods.
4. Look at trends over time.
5. Know what it is you are measuring, and why.
6. Only track and report on the items and at a granularity that drives action.
7. Reports don’t always answer questions; more often they tell you which questions you should be asking next.

Let’s take a “Support 101” look at what you should be reporting on. If you have an inbound phone queue your basic metrics should include:

• Average hold time before the caller gets connected to an agent
• Abandon rate (those who hung up before being connected to an agent)
• Average handle time (the amount of time an agent spent on the phone with the customer)
• Staff availability (how many people, on what shifts, and are they being fully utilized?)
• Call volumes by time, day, season, and location
• Other indicators of spikes and dips in demand

These work best for “customer service” types of calls, where one call is usually sufficient to resolve a request or problem. This may include things like ordering a product, asking an account-related question such as a billing inquiry, or scheduling an appointment. Time-of-day and seasonality often impact these statistics, so trend data over time with appropriate granularity make a measurable difference. If you need to take on more work, these numbers will help you forecast staffing needs and evaluate alternatives like automation. Online Chat requires a similar set of concerns. Both methods are human-resource-intensive but could benefit from well-constructed automation such as a Self-Service Portal.

For work which requires more than a single phone call to resolve, like in a technical product support situation, you will require similar metrics from your case tracking system (CRM). In addition to the metrics listed above, your metrics should include:

• Volume by source (phone, chat, web self-service, email, internal)
• Size of Backlog and Aging statistics – consider granularity in areas like component, team, customer, and other demographics
• Amount of work required on an average issue (may vary by parts of the product)
• Average time-to-resolve (in minutes, hours, and days)
• Percent of issues escalated to other departments, such as Product Engineering for bugs or feature requests
• Customer Satisfaction ratings (transactional, per case)

There are other items you should track or break out, such as per-customer information, revenue impact, severity, and priority. If you have a Customer/Community Self-Service Portal or a Knowledge Base, you will also need to track their efficacy, such as number of cases deflected (never came to Support) and number of cases resolved by existing Knowledge Docs. All these together can help you forecast future needs, set expectations with upper management or other organizations, and measure the success of any tools or process initiatives you undertake.

When looking at the metrics outlined above, remember “Rule 7”: Reports don’t always answer questions; more often they tell you which questions you should be asking next. Look for trends and anomalies, and then ask yourself what are their causes and what actions should you take to address them?

The Right People in the Right Place

Your work on the metrics above has informed you as to when your load is coming in and from where. Now you must ask yourself:

• Do I need to provide Support globally? If not, which regions do or do not require it?
• Do I need to provide 24x7 Support? If so, is it just for critical issues or for any type?
• Do I need to provide “Follow-the-Sun” (FTS) Support for critical or sensitive issues?
• Do I provide Support from a single 24x7 center, or do I post staff strategically around the globe?
• Do I make that staff “company-badged” (direct employees), or do I outsource? If I outsource, do I go “offshore” (based in a country or region with significantly lower costs than one of your corporate locations)?
• If I go global (direct or outsource), how will I manage a remote team?
• How do I structure the team? Do we have Tiers? Do we segment by product area? What should our hierarchy look like?
• In addition to Technical Support Engineers (TSEs), what other roles and functions do I need to staff for in my Support organization?

Your current and projected numbers can help you answer these questions. But here is some general guidance if the metrics drive you this way. Most companies I have been through divide the world into three major regions: EMEA (Europe, Middle East, and Africa), Americas (North and South), and APAC (Asia/Pacific, including Australia and New Zealand). This enables coverage of all time zones depending on where your teams are located. Even if you use one or more 24x7 centers, it is common to break out your view of customers into these (or similar) demographic groups. In my article “How to know how much Technical Support staff you need” I provided an example of how a small US-centric company might provide 24x7 Follow-the-Sun coverage through shifts in US, APAC, and EMEA:

• M-F 8AM - 5PM Eastern (1PM-9PM UTC): minimum 3 heads
• Sun-Thurs 8AM - 5PM Pacific (4PM-1AM UTC): minimum 2 heads
• Tues-Sat 8AM - 5PM Pacific (4PM-1AM UTC): minimum 2 heads
• ·??????above two staggered shifts provide weekend coverage; "hole" on Mon/Fri covered by Eastern staffing
• Sun-Thurs 8AM - 5PM Japan (Midnight-9AM UTC): minimum 1 head (absentee risk)
• Tues-Sat 8AM - 5PM Japan (Midnight-9AM UTC): minimum 1 head (absentee risk)
• Sun-Thurs 8AM - 5PM GMT (8AM-5PM UTC): minimum 1 head (absentee risk)
• Tues-Sat 8AM - 5PM GMT (8AM-5PM UTC): minimum 1 head (absentee risk)

The goal is to identify where you need the resources, when you will need them, how many of them you will need, and what are the expectations around delivery. As with the Metrics and Forecasting section above, the answers to the questions at the start of this section will lead you to other questions. The answers to those questions may involve manipulating the Controls and Levers from the beginning of this article.

Remote and Follow-the-Sun

The days of having your entire team collocated in a small number of offices were already waning before 2020. Teams which were historically office-based had either already moved to a remote or hybrid model, or were considering it, and many organizations continue to move to remote or geographically dispersed teams. While this has its benefits, there are challenges to managing a global team.

Benefits to remote and dispersed teams include:

• Improved employee morale and retention, and a larger candidate pool, by providing employees more choice in where they live
• Elimination of “graveyard shifts”; employees work primarily their local daylight hours
• Lower costs if hiring employees outside of major (expensive) cities
• Getting more “local” with your customers helps bridge gaps in culture and language
• Enables literal “follow-the-sun” coverage

Challenges to a distributed team:

• Need to take extra measures to establish a sense of unity. Use tactics like regular video meetings which are recorded for those in “inconvenient” time zones, and schedule them to move that inconvenience around. Also use team communication tools like Slack to allow real-time discussion of issues and let those who were off shift review later.
• Real-time management feedback and support. If a team is large enough in a region, providing local managers or team leads helps provide guidance and assistance to other team members. If that is not possible, but there are other similar local teams (think of Sales teams collocated near Support staff) then working out agreements to leverage their management structure for time- or location-sensitive issues is an option. If you are in a situation where you are the sole manager, try to schedule video meetings with your remote teams during the overlap time when your day typically starts or ends, and the other two regions are at the start/end their respective days.
• For follow-the-sun issues, your staff should also leverage the end/start shift overlaps and a well-designed process to actively hand off issues that need continued effort.
• For any Remote staff, regardless of time zone differences, you should make the effort to “see” them often. That could be acknowledging successes via email, having regularly scheduled 1-to-1 meetings with them, and responding promptly to messages they send via any email or messaging channels.

Among the critical success factors with remote teams, and with any team, is to ensure that they have a means and incentive to collaborate. The easier collaboration is, the more seamless your team will be regardless of geography. The same holds true for performance management, training, and development; regardless of where your staff sits, you must always strive to understand their performance and their needs.

Roles and Functions

The previous two sections dealt mainly with TSEs (Technical Support Engineers). Depending on your size and other factors, there are additional roles and functions within Support. For a small team, these may be facets of your job as the leader; for larger teams you may have sub-teams in your org chart for these. A brief list follows and is not intended to be exhaustive. Note that some roles or functions may coexist under a single leader or team.

• Support Readiness: works with Product and Engineering teams to determine what knowledge and skills Support requires for new features, and ensures that proper tools and documentation are in place; may have sign-off authority on new releases
• Support Communications: handles external communications via email or web for Incidents and other critical notifications
• Support Planning: helps answer many of the questions in this article about current load, future needs, and project priorities; may also be responsible for project management and change management within Support
• Support Process Management: responsible for creating and updating processes, measuring their effectiveness, and training staff on them
• Community, Knowledge Base, and Portal: team(s) to implement and manage these tools and their related processes, oversee their use, and measure their effectiveness
• Support Training: provide onboarding training for new hires and ongoing product and process training for staff (unless and except as provided by the specific other teams listed above)

“Your mileage may vary.” Your organization might not have a current need for some of the above roles, or may require additional roles within Support. My intent here is to highlight that there is far more to a healthy Support organization than just “taking tickets.”

Management Lessons and Styles from TV and Movies

This last section is a bit of a non sequitur. The previous sections provide a set of instructions and building blocks; this last one is a collection of random items – my gift to thank you for reading this far. Among the things I have learned is that some lessons show up in unlikely places. Here are some management lessons and styles that I have learned from entertainment sources.

“The Wizard of Oz”: The Wizard does not want to help Dorothy and her friends. Instead, he sends them off on a dangerous quest to get the broom of the Wicked Witch of the West. What purpose does the broom serve in getting Dorothy home? None. The Wizard neutralizes his enemy without putting any real skin in the game and doesn’t expect the heroes to succeed. He could have just brought them to his bag of placebos and then flown Dorothy home; everything else was wasting their time and putting them in jeopardy. The Lesson: Don’t waste your customer’s time, and don’t let others waste yours, on unnecessary tasks. If Tech Support suggests that you backup your entire computer, wipe the disks clean, and reinstall everything, it’s fair to ask how that will help you retrieve your login ID to their application.

“Apollo 13”: The ship had a critical failure, and the crew was at risk of dying. The team on the ground could only solve the problem using exactly what the crew had on the ship. If the astronauts only had 11 inches of duct tape, the guys on the ground couldn't devise a solution that required 12 inches. The Lesson: Don't provide a solution that cannot be executed. Don't tell me, "Just have the customer do this," if the customer cannot realistically do that. Impossible solutions are not solutions at all.

“Jurassic Park”: You only engineered female dinosaurs; therefore, you only have female dinosaurs, right? For those who have not seen the movie, “Spoiler Alert!” Check your assumptions. The Lesson: If you only check for “happy path” (expected results following established behavior) then you may never realize the problem that’s right in front of you. Long ago (long before every application used a web-based screen) I was supporting a Forms-based product. The customer had reported that there was garbage at the end of many data elements. Investigation revealed that the user was using the Tab key instead of the Enter key when moving between fields. That was unsupported (I know – ancient technology!) and it was the (encoded) tab character that was being appended to the corrupt data elements. Looking for the unexpected behavior may lead you to the solution.

For those of you who are Star Trek fans, have you noticed that some of the captains are lessons in management styles? Here’s my take on them.

“Star Trek” (original series): James T Kirk was a classic “heroic manager.” He was always personally jumping into every problem and joining every “away team.” While this has the positive effect of getting his team’s respect as well as his knowing everything that happens, he was a micromanager who was putting himself at risk and not fully developing the leadership potential of his team.

“Star Trek: The Next Generation”: Jean-Luc Picard was a delegator, with his tagline, “Make it so.” He collected information from his crew, collaborated on a plan of action, and then delegated it to them (often under Commander William Riker). While he often also put himself in harm’s way or made autocratic decisions, his general style was to lead with authority but collaboratively.

“Star Trek: Voyager”: Kathryn Janeway went too far down that collaborative path. I always thought that she spent more time in their Situation Room than they did off-ship and wouldn’t make decisions without 100% certainty regardless of urgency. I’m surprised that analysis paralysis didn’t get them blown up.

And one final thought which I have shared with my teams over the years. If somebody asks, “Does this road go to San Jose?” then a correct answer could be, “No.” But that is also a completely useless answer. The Lesson: Always try to answer the problem, not just the question. A better answer might be, “No, this road goes to San Francisco. This other road goes to San Jose. Where are you trying to go?”

You may agree or disagree with my examples above. My point is really to watch for these examples and lessons outside the work environment, recognize them, and consider them.