IT Support Creed

Case reviews. Tiers. Process.

1. Align your team with a shared vision, values, and understanding of what success looks like. Processes don’t align your team. Alignment starts with a shared vision that your team can believe in. For example, the vision for my current team is to “facilitate an effortless support experience.” Back your vision with shared values to which you can hold each other accountable, deepening your core belief in what you wake to do each day. The values for my current team are:

• Start with why. Context matters. I want my team to give context to customers and internal teammates. I also want them to ask for context when it’s not given.
• Understand and care. I don’t ask my team to practice empathy. It’s not healthy to feel the emotions of customers and often encouraging empathy can lead to a team taking work home. They simply need to understand, truly understand, and then show that they care.
• Be open and flexible. I want to try new things and so does my team. We need everyone to remain open to change and flexible enough to try it.
• Be persistent. Being in support can be hard, given how much of it requires serving as intermediary. I give my team the ability to be persistent in a healthy, kind way and empower them to stay on it like honey badgers.
• Outgrow yourself. I want my team to grow, in their current role and beyond it. Their goals are my goals.

And everyone knows what success looks like with shared metrics, ranked with a clear number on priority. How to achieve success should never be a secret and you can’t have more than one number priority. For example, our number one priority for success is to obtain 95% customer satisfaction (CSAT). And our number two priority is to hit our service level agreements (SLA) 100% of time. We would rather miss SLA by a few minutes than sacrifice quality. By the end of 2017, we were obtaining 93% CSAT and 99% SLA. This all started with our shared vision, values, and metrics. Once we were aligned, we could focus on identifying what the team was already doing well and where they needed to do better. Alignment + ability = autonomy. The trust to be as autonomous as possible is what your team wants and it will only benefit your end goals. If they don’t do something the way you would have wanted them to do it, remember you hired smart people and dig into what ability they need to further grow to have it be more aligned the next time.

2. Push “effortless” over “delight.” To delight someone you have to know them. What delights me, might not delight you. So … how is a team supposed to delight thousands of different customers? It’s way too subjective and to really do it ends up being quite costly — so trying to delight everyone results in your team struggling to understand how to be successful and risks tremendous impact on your bottom line. Think about the infamous Zappos 10-hour calls. How many people would you need on your team to do that every time a customer wanted you to? And it turns out, today’s customers don’t even want this (if you want to read more check out The Effortless Experience). They just want your team to solve their issue, quickly and without having to do a lot of work. They want an effortless experience. With two simple questions, you can make offering such an experience relatively objective and consistent: 1) Can I do this for the customer? and 2) Is it reasonable for me to do this for the customer?

3. People don’t stop being people just because they come to work. This is true for your team and your customers. Your team wants to feel accepted and protected. They are human, so they will screw up. Will you make that be a good experience from which they grow or an awful one that scars them? Your customers will have good days and bad days, so don’t pretend that if you’re in a business-to-business contract, your support practices should be anything other than business-to-consumer. Yes, there are differences, but not in how people want to be treated. If your customer asks for a call, call them. They are likely freaking out and just need to know a human on the other side understands and cares. Most seemingly unreasonable requests from customers come from all the bad support out there and a very reasonably fear that their issue will be forgotten. No one likes to be forgotten. Don’t let your team lose sight of the human on the other side and remember that this starts with how you treat your team.

4. Write less, talk more. When it comes to processes and internal knowledge base documents, be careful how much you write down. Most adults don’t learn best from reading on their own and the more you write down, the harder it is to find what you need. Frankly, the more you write down, the more you set your team up for failure. Imagine if before you did any aspect of your job, you were expected to stop and read an arduous process document — because if you didn’t, you would likely get the exact steps wrong. Would you feel trusted? Would you feel smart? So, why impose that awful reality on your team? Limit what you write down to only things that should be treated as if they are set in stone. You will find there are not very many of these things. As for how to share the rest of all that important information, make it part of the collective knowledge and build out workflows that get your team members talking to one another. Adults learn best when they are able to talk to someone and you will reap the benefit of the individual way each member of your team processes information. On my current team, we often remind each other to exhaust our collective brain trust, asking each other early and often. It is more efficient than wading through a pile of documentation and it creates an open environment where it’s safe to ask questions and learn from one another.

5. Review cases only when it’s meaningful. I generally think of cases like email correspondence. If I have anyone on my team whom I don’t trust to send an email without my review (before or after), I should probably fire them. Thinking this way caused me to dig into whether there was any value to case reviews or not. If one of the following is true, then I think there is value to case reviews as a reactive measure instead of a proactive burdensome, low value administrative check-the-box task:

• The employee is new. I usually look at the first few replies before they hit publish just to be sure we are aligned overall. After, I let them go forth, check in often to make sure they are not blocked, and once they hit a certain milestone (for example, they have closed their first 50 cases), then I review the last 30 they closed and sit down with them to review the results. I use this as a confidence builder. I offer more positive observations than constructive and I ignore their first 20 cases closed — everyone gets the opportunity to make a few mistakes in private. And if the mistakes I don’t comment on continue, I can address them later.
• The employee consistently receives poor CSAT. If this happens, I dig in and try to figure out what is going on — again, looking at the last 20–30 cases closed to identify themes.
• The employee is trying to learn a new skill and the results would be visible in their case responses. This turns case reviews into a helpful coaching method as you help your employee outgrow themselves.
• I want to feel good about my team. That’s right. If I’m having an off day, I might look at cases at random and rarely does my team disappoint. I just sit there quietly at my desk and feel happy and proud. Sometimes I share these moments with them, which can reduce the anxiety they may feel about me digging into the details of their work.

Otherwise, if one of these things isn’t true, then I find case reviews to offer very little value for the amount of effort and time they require. If someone on your team isn’t doing a good job, it will surface quickly enough without making your team feel like they aren’t trusted enough or smart enough to send a damn email.

6. Single tier is best. Unless you’re making a cake, resist the temptation to have a tiered model. Multiple tiers requires handoffs and for customers, each handoff is like starting over. Handoffs cause your customer to become unfairly frustrated. It seems cheaper to have multiple tiers, but it’s actually not. With a single tier team, you ultimately need fewer people and you can teach the technical skills you need. Investing in an amazing onboarding and ongoing education gives you the right talent without the need for costly, frustrating handoffs. There are many additional benefits, such as, the workload is more predictable. Everyone works from a single queue and you no longer have to estimate for multiple factors that can create undesirable wait times at each handoff. There is also a stronger sense of ownership across the team. Once someone starts working a case, it’s theirs. There is no second or third tier to wonder why a case was handed off and everyone on the team has opportunities to outgrow themselves to solve each issue they own.

7. Don’t hide quality issues with people. If you’re predicting how many new hires you need only based on number of customers and not taking into account the defect backlog, you’re likely making it harder to see if you have a quality problem. One of the hardest things I’ve had to do as a technical support leader is not let the defect backlog get to a point of no return. Support isn’t the team that gets to fix the defects so this was an exercise in looking out for what was best for the company and being open to the best path forward. It is one of my crowning accomplishments, a thankless win that will prevent years worth of quality problems down the road. It was so hard, that at many points I thought how much easier it would be to just justify more people and plan for roles to handle escalations. I think this is what a lot of us do — we hide quality issues with people. Keeping technical support as small as possible is a fight worth fighting. And I’m pretty sure you don’t need me to talk about the benefit this will obviously have on customers and retention.

8. Add even more visible value. Technical support is near and dear to my heart and I know it adds tremendous value. Yet, I’m still learning how to overcome the interesting phenomena that the better my team does, the more our internal colleagues seem to not recognize them. I’ll have a lot more to say about this in a few months (increasing the sentiment of being recognized within my team is an active effort right now), but I have learned that there are a few easy ways to make support more visible in your own organization.

• If anyone internally finds an issue, have them reach out to support just like a customer. Let everyone experience what it is like for your customers and appreciate the work your team does every day.
• Partner across the organization to have your team serve as one of the gatekeepers to engineering. This will reduce internal chaos when it comes to how issues are reported and ensure that defects are packaged for engineering with all the relevant information. This will also allow engineering to have less interrupts, as they can expect work to come from only the product or technical support teams.
• Own the official product documentation. More often than not, support ends up creating their own version of documentation to meet the needs they have working with customers every day. Moving ownership to support (from the more common home of engineering) simplifies getting to the end result, improves the overall documentation quality, and diversifies the role of technical support to add even more visible value.

9. Inspire yourself to be better, to make your team better. There are many ways to do this, but one of my favorites is when I have to reach out to another support team for help. This could be for a tool my team uses or my bank. In these experiences, I am either inspired through the validation that we are doing something truly great or through seeing what I might want to try next. If you are not inspired as a leader, you will not be able to inspire your team.

Technical support is near and dear to my heart and I want to see this discipline be the best it can be. I want to hear people talk about being a member of a technical support team as the reward it can be and not some curse to carry just to get your foot in the door. May this creed and its 9 tenets help this become a reality in more and more companies.

This should help us in becoming better and the quality of our response and service will shine.