The reverse Anna Karenina theory of support

I have a theory about support teams. I've been using it as a guiding principle for years and it has so far always proven to be true. It is what I have come to call the Reverse Anna Karenina Theory of Support. The theory says that,

All unhappy support teams are alike, while all happy support teams are happy in their own ways.

I think this is true more generally, beyond support teams, but I am in no position to argue with Tolstoy on the matter. So we'll stick to discussing customer support here. Keeping in mind that this is my theory based on my experiences and not grounded in qualitative research, let's dig into what this can tell us.

Ways in which unhappy teams are unhappy

Many support teams are happy and productive, full of happy and productive people. There are many other teams, however, that are full of people who are dissatisfied and frustrated with their jobs. A lot of these people talk to each other. They gather in Slack groups and Discord servers, at bars and cafés and conferences. And they commisserate. Because a lot of support professionals are deeply unhappy with their careers in a lot of the same ways. The teams they're a part of and the companies that employ them often display some of the same behaviors no matter what size the company is or what industry they are in.

I don't think any one problem is necessarily worse than another or even more prevelant than any other. They often come in groups and are connected to each other in various ways, so I've tried to list them in an order that I think makes sense. For folks reading this who have experienced these problems and behaviors, this is sometimes the order in which they realize the problems exist.

Siloed from other teams

The most common complaint I hear from support professionals is about how the support team is siloed from other teams at the company. It's so far ahead of the other contenders for complaint status that it feels silly to discuss it at all. For the people reading this who don't work in support, have never worked in support, and don't know anybody who works in support, I'll say that most support professionals find it difficult to work consistently well with other teams at their companies.

It's not that they never work with other teams, or that it's always a terrible experience. The issue is often that the style of work and the style of communication required to do the work between support and the other teams they need to work with (engineering, product, logistics, finance) is drastically different between teams. Bridging the gap is challenging, and more often than not, the other team would be just as happy to not spend the time doing it.

It's support's responsibility to devise ways to communicate and collaborate with other people at their own company. Everyone at the company is trying to do the best job they can for their customers, but support teams need to spend extra time and energy making sure teams are working in sync with each other. And sometimes that's just not possible. Either the time doesn't exist or nobody has the bandwidth to do it or the other teams are busier than usual and can't make the time. So that cross-team collaboration that we all hear so many buzzwords about doesn't happen.

Misunderstood skill set and job description

As I've talked about at length, the role of Support is often misunderstood. A lot of well-meaning people think that the job of Support is to answer customers' questions with reliably known information. And at large call centers, this is often true of Tier 1 support. However, in other contexts (and at every tech startup I've ever met) that maybe a small fraction of what the Support team does.

Responding to known issues with known resolutions or following up on a customers' process request takes a few seconds. These are tasks which should have been automated in some way but weren't. With the rise of AI tooling, we're seeing a lot of companies try to solve these issues now with a host of automations and generative AI tools. That's great and I wish people had thought to automate those easy issues years ago. The problem is that a lot of companies are trying to automate the entire job of support because they think that this easy kind of question-to-answer workflow represents most of Support's work. In reality, it likely accounts for less than 10% of the teams' work, because it's often the fastest work to do.

Most of the problems that customers report that can't be resolved in seconds requires a broader and deeper set of skills. Support professionals research and experiment with products, including their own company's products. They try to reproduce customer issues, solve those that can be solved, and find workarounds and mitigations for anything that requires further fixing. They report their findings to the rest of the company, whether in the form of bug reports, customer feedback, or status updates on product usage. Support professionals also spend a good chunk of their time writing and editing customer help documentation to avoid getting the same questions over and over. And none of this includes the time a lot of them spend optimizing their own workflows within the confines of the tools available to them, often by writing scripts to automate their own work or sharing automation tools amongst themselves to reduce the time wasted throughout the day.

Basically, Support teams do a lot of interesting, creative, and analytical work. They need to be excellent communicators, but writing emails and responding to phone calls is the easiest part of the job. It's often not even the bulk of the job.

Given poor tools

With the above points in mind, it should come as no surprise to anyone that Support teams are often poorly equipped to do the their best work. The job is not well understood by leadership or by other teams, which makes it more difficult to get access to the tools required to do that job. Support teams often need access to information tucked away in systems across the company - application logs and subscription invoices and bug reports and legal disclaimers and ongoing disputes with foreign governments (I wish I was kidding aboutt that last one). Being siloed away from all those teams makes this a never ending struggle.

The struggle to access information within a company is compounded by the fact that even most support tool vendors don't fully understand the work of a highly productive support team. Support professionals often have to use a help desk that doesn't meet their needs because the people building it don't know exactly what those needs are. Stress runs high when you spend time away from the queue of customers to deal with internal access issues only to return to your own workspace that puts up obstacles at every turn.

Held to precise and irrelevant standards

Readers of this blog will know how we feel about performance metrics. In practice, many Support teams are judged by strict sets of performance metrics, some of which they have little control over. On top of that, most of the metrics used for Support teams do nothing to measure the non-queue work the team members do. When that represents the bulk of the work a person does - both in terms of time and in terms of effort - not even taking those into account when judging performance can feel like a slap in the face.

I won't go into the details of that problem here, but I highly encourage everyone to read that previous blog post about metrics and why we, as a community, are often wrong about what they say and how we use them.

Given little autonomy

Work is often dictated by the hour, with specific times spent doing specific parts of your job. Anything that needs to be done outside of that needs to be done on personal time, if it gets done at all. And there will be more to do because the people making the schedules often don't know what Support does.

This is often directly related to the points above about the role being poorly understood and the metrics being only barely related to the work, at best. The result is that many companies are constantly looking to optimize the surface level value of support - answering customers' questions. And optimization often translates to "answer as many customers as possible for the least amount of money."

The customers' questions, though, are only symptoms. We never have a chance to address the deeper business issues that those symptoms point to when we have to jump to the next question as quickly as possible. Support professionals are keenly aware of this disconnect and are often aggravated by their inability to help solve those problems.

Compensated poorly

With all of the frustrations caused by the issues above, an uninformed reader may now be thinking that the job sounds terrible but the pay must be fantastic. Why else would people sign up to do it?

Despite all of the skills required to do the job of a skilled Support Professional, the role remains one of the lowest paid office jobs within a company. It's an entry-level role in many places, and an entirely outsourced role in many others.

Compensation doesn't just come in the form of dollars in a bank account. I can't count the number of Support professionals I've known who attended a week-long company retreat at which every team was told to take the week off and get to know their colleagues... except for Support who had to continue managing their workload while the rest of the company partied. In some cases, the team was acknowledged for their hard work with cash bonuses. Some only got a pizza party.

It's not hard to look at this list and imagine why Support teams experiencing even one of these problems would be unhappy. In truth, teams often experience these issues in groups. It makes sense that a team whose role is misunderstood and who has no autonomy would be poorly compensated, for example.

Not every unhappy team is unhappy for all of the reasons above. However, all unhappy teams are probably unhappy due to at least a few of those reasons.

Ways happy teams are happy

Every happy team is happy for different reasons. Whenever I've met a happy, productive support team full of joyful, motivated Support professionals, they have given me wildly varying reasons for their happiness. They all boil down to the same root - they've solved the problems that make teams unhappy.

Solving one or more of the unhappy problems

On the surface, it sounds like a singular cause for all of those happy teams to have high morale. They all seem to have that one thing in common. They've all addressed the core sources of unhappiness. What most people on those team will tell you, though, doesn't sound like a single cause of success. The story is more complicated.

The ways in which teams solve the issues listed above vary dramatically between successful teams. This is because successful teams develop solutions that are tailored to their specific situation. The team, the company, the product, and the customers all impact the work of Support. Therefore, finding ways to solve Support's problems needs to take those factors into account. Every company's support team - and often teams within a company's support team - will have different ways to solve problems that they all have in common.

This doesn't sound like a breakthrough idea or some revelation. However, in practice, most teams and team leaders and executives will look to industry standards, best practices, and benchmarks when evaluating their own performance and looking for ways to improve. When leaders find themselves looking at their peers to see how they should solve problems that all of their peers are also dealing with, they inherit the problems of other organizations. When a majority of the industry is dealing with the same unsolved problem, it doesn't make sense to look to business standards and benchmarks to find a way to do things differently. The problems become more entrenched and eventual develop into "how things are" across the industry.

Support teams and Support leaders need to start looking internally to develop new ways of addressing core problems in their teams and in their work. To address any of the six core issues of unhappiness - cross-functional communication, role definitions, tools, performance metrics, autonomy, compensation - we need to focus on our company, our product, and our customers. Maybe the tech industry has a benchmark average of 40 tickets solved per day per support agent, but that doesn't mean that you should expect your team to do that. Consider the problems the team is solving, the needs of the business, and the persona of the customer you're helping, Those will give you a better indication of how you're performing than comparing your individual work to a context-less benchmark from other companies.

Better to start on the right path than course correct

The most successful, productive, and generally happiest teams I've ever met have gone farther. They have avoided running into the most frustrating problems to begin with. It's possible to predict them once you see the Reverse Anna Karenina Theory play out a few times. Once you know what to expect and what to avoid, you have the opportunity to build organizations and workflows that create better environments from the start.

Many of you are likely not in the position to create your ideal team from scratch. Maybe you have a stressed out team with slowly decreasing morale already. The fear of layoffs still raging across the industry isn't helping. I encourage you to look at this list and think about how you would solve these problems for your team.

And for all the teams who are chugging along happily, I'm happy for you! I've been there, too, and it's amazing. I think we owe it to the rest of the community to talk about what has worked for us to get there and how other teams can do it, too.