Service pressure

Data teams aren't service organizations, but we can learn a lot from those that are.

The support queue: A pressure like a drip, drip, drip, that’ll never stop.

Some of our opinions make sense: They’re well-reasoned and deeply considered, and built on firm foundations of logic and experience. Others, however, come from hiccups in our timeline, developed from quirks of coincidence, as inexplicable as they are strong. For me, this latter group includes my feelings about fall-themed salads, the Bank of International Settlements, Steph Curry—and bullets. 

I have a moral aversion to writing with bullets. They strip the humanity out of ideas; they turn thoughts tactical, into “action items;” they make every message a Politico Playbook Morning Brief, meant for a Hill staffer who wants a daily news email that confirms to them they don’t have time to read a daily news email. Bullets are devoid of context and connective tissue, snappy takeaways without supporting evidence, all chorus and no verse.

But, as I was reminded by a friend I recently exhausted with a four-page wall of prose, bullets have their place. When people are upset, irritated, or just want to read the recipe without slogging through an indulgent preamble about childhood memories of honeysuckle, they need bullets, not a shoehorned bank robbery analogy.

Reluctantly, I have to admit that my friend is right. She’s right today, and she was right eight years ago, when I learned the same lesson the hard way.

In the months immediately following Mode’s initial launch, we had too few users to justify spending much time analyzing how they were using the product—but we had enough that we needed to provide them with a lot of technical support. As Mode’s analyst at the time, I found myself reassigned to be Mode’s support agent. 

Though I eventually rotated off the support queue and into other roles, I stayed involved long enough to work with the early team that replaced me. In doing so, I had a chance to learn from a handful of far more talented and compassionate¹ support experts than I ever was. 

Sitting in the trenches together with confused and frustrated customers, they didn’t just teach me how to close out a ticket. They showed me how to handle the constant pressure² of an infinitely scrolling to-do list. They showed me how to diagnose a problem, how to listen, how to talk to someone who’s frustrated, and how to meditate without taking sides. They taught me that support, like sales, is a job everyone should do at least once. And they taught me how all of this can make me a better analyst. 

They also taught me that, sometimes, you need to use bullets. No customer wants an essay from their support agent, nor do they want short text messages, abbreviated to the point of illegibility. Instead, they want instructions, with the important points highlighted, and the details included if they need them. Often, that means they want lists, section headers, and bolded callouts. 

So, in honor of that lesson, and in honor of my friend who reminded me of it again this week, these are the other things that the support team taught me—in all their formatted, bulleted, and bolded glory.

Be a detective, not a consultant

When a customer reports a bug, production is whatever is on their screen. No matter what should be happening, no matter what’s happening when you try to reproduce it, no matter what the code says, no matter how little information they give you,³ their problem is the problem to fix. 

The same applies to analytics. As Randy Au eloquently put it, production is what’s in people’s heads. It doesn’t matter how it got there or if we believe it to be wrong. They think it; therefore, it is. Our job, first and foremost, is to figure out more about it:

• Sometimes, we’ll find out we’re the ones who don’t know something. For example, we may think that Facebook ads are ineffective, and think that all the sales reps who prioritize leads from Facebook are making a bad decision. But the problem might be that we’re not doing marketing attribution correctly, and it’s us who’s wrong.

• Other times, we’ll realize that some bit of tribal knowledge—”nobody likes that feature;” “our blog drives traffic but not signups”—stems from a single years-old deck that grew, through email and office chatter, from an interesting offhand finding to an Unquestionable Iron Law of the Universe. These beliefs can’t simply be corrected; they have to be unwound. To do that, we need to know where they came from.

We can’t do either of these things, however, if we act as consultants, charged with imposing our expertise on the unenlightened masses. Instead, analysts should model themselves after detectives who don’t seek to correct others’ experiences, but to understand them. And just as a detective—and a support agent—would never tell a witness they’re wrong, neither should we. We should instead say, “that’s interesting; tell me more.”

People want to be seen

I was once told by a senior solutions and support leader that the biggest complaint technical users have about support teams is that they don't listen, and they don't understand users’ businesses. For these users, being told no was fine; they knew their questions were sometimes unreasonable, and their feature requests were unrealistic. But being rejected offhand, before they had a chance to explain what they wanted and why it was important to them—that was unforgivable. 

Good support teams understand this. They understand that, sometimes, customers just want to be heard. They’re frustrated by a bug, and they want someone to validate that emotion. They’re excited about an idea, and they don’t want to be demoralized by a quick dismissal.

As an analyst, I struggle to remember that this also applies to the questions people ask of data teams. When people come to data teams with bold ideas that we know won’t work, it’s tempting to immediately dash their dreams with an avalanche of well ackshuallys—”we tried this before and it didn’t work, we can’t get that data, and even if we could, it couldn’t be interpreted that way.”

This misses the point. People usually don’t want a model that precisely predicts which customers are going to miss their invoice deadlines; instead, they want the data team to understand that late payments are causing trouble. They want us to see their problems as much as they want us to solve them.

We don’t have to be smartest person in the room

Next time you’re sitting in a meeting, take a moment to ask yourself what you want people to think about the next thing you say. Do you want them to be inspired? To laugh? To feel supported? To see you as being organized? To see you as being in charge?

For a lot of analysts, if we’re honest with ourselves, our answer is that we want people to think that we’re smart. We’ve been conditioned to believe that, above all else, our cultural capital comes from our intellect. Better to be a prickly truth teller than a hyperbolic leader or a passionate manager. 

On a support queue, however, nobody cares how smart you are. On the contrary, the best support agents deflect their own cleverness back onto the customer. 

For example, prior to joining Mode, our first support lead worked at a hardware company. Their customers tended to put the batteries in their products incorrectly, but people reacted poorly when support agents asked them to check if they’d messed up something so simple. So the support team devised a strategy: Tell the customer the problem can sometimes be resolved by taking the batteries out and putting them back in. When customers did this, they’d notice the batteries were wrong, but could do so so without having to admit to the mistake they’d made. 

When these sorts of things happen—when people report a bug but were actually clicking on the wrong button, or when they thought they couldn’t log in but were using the wrong password—you want to take credit for solving the problem. You want the customer to know that you knew what was happening all along. You want them to know that you were smart enough to figure it out. 

Our support team taught me to let it go. Give the customer the win; take the glory to the grave. 

For data teams, our job is the same: Help people solve problems. We can—and should—be satisfied by good results and by happy coworkers; we don’t need measure our worth by how smart they think we are smart too.⁴

Have faith in the loose science of CSAT scores

When I first started researching how to measure the performance of Mode’s support team, I was excited to find how many quantitative metrics we had to choose from. That same initial team lead, however, dismissed most of these numbers. They’re useful, she said, but argued that we should focus most of our energy on customer satisfaction, or CSAT, scores.

As a stubborn analyst, I hated this idea. Unlike metrics like first response time or average time to resolution, a CSAT score is built on a subjective foundation. It’s often just a user survey, in which customers are asked to rate how they feel on an arbitrary scales of numbers (and, worse still, emojis⁵). 

I was wrong. The best support interactions weren’t the ones that got the fastest responses, or resolved in the fewest messages. Moreover, people can’t realistically “vote with their feet” by choosing other alternatives for technical support. Our help line was their only option. CSAT scores, imperfect as they are, measured what we cared about most—if people were actually happy. Sometimes, the best way to figure out what people think is to just ask them.

I’ve come to believe the same thing about data teams. Yes, CSAT captures feelings and not facts, but feelings are often rooted in facts we can’t quite describe. Rather than looking for indirect proxies for assessing if a data team is serving their internal customers well, just ask those customers. If they say yes—if business leaders would rather have an extra cook in their kitchen when they’re making a decision, with all the friction that introduces—would any metric really convince us that they’re wrong?

It’s not about you

When someone reports a bug, you can react in a lot of different ways:

• Be detached, mechanically thank them for reporting it, assure them that their feedback is of the utmost importance, and file it away in Jira, indifferent to whether or not the ticket gets resolved or rots.

• Feel bad about it—after all, this is your company—apologize for the bug, and take their feedback personally.

• Get defensive about it—after all, this is your company—and try to convince the customer that the issue isn’t so bad. 

• Tell the customer you're upset about the issue too. You reported that bug before, and you’re just as mad as they are that it’s not fixed yet.

Away from the support queue, when you’re talking to internal teammates about the recent conversations you’ve had with customers, you can also position yourself in several ways:

• Side with your teammates, and put customers down by joking about how they don’t understand how the product works.

• Side with the customer, and complain to your teammates that they’ve abandoned you at the wall, bearing the brunt of issues you can’t fix.

• Side with yourself, and just be a messenger, there so you don’t get fined, delivering feedback from customer to product manager with the same passion that a postman delivers both an eviction notice and wedding announcement.

This happens because support agents are caught in the middle between company and customer. They’re the voice of both to the other, professionally invested in the success of each, with little agency over either. Speaking from experience, it’s confusing to know where to stand. 

Data teams sit in a similar breach. They operate in the spaces between teams and competing opinions, and are often called upon to indirectly mediate internal disagreements. But data teams aren’t disinterested observers: They’re invested in the business, and likely have personal relationships with people on both sides.

Support teams offer a potential solution: Be everyone’s stern therapist. Listen, give people emotional space, tell the facts straight—and, most importantly, recognize that none of this is about you. The customer isn’t mad at you; they’re just mad. The marketing leader who’s holiday campaign is flatlining didn’t want you to bury that information; they just need time to process it. And neither of them need a cheerleader to amplify their emotions; they just need someone to help them figure out what to do next.

Finally, take pride in maintenance 

During my first few months on the support queue, I often went home frustrated by how little I got done every day. I'd arrive in the morning, talk to customers, close out tickets, and return the next day to a fresh batch. Aside from gradually expanding our help docs, I built nothing. At a startup where progress is paramount—and in an industry that tried to manifest “IT’S TIME TO BUILD” into the zeitgeist—I was running on a treadmill. 

I should’ve taken more pride in that work. We appreciate airplane pilots who fly back and forth along the same routes every day; we celebrate chefs who cook food that needs to be made again tomorrow night. These jobs are no less important than those of the idolized builders; they’re just shaped differently. 

Data teams should remember that as well. We often chase big projects, like launching a new testing platform, building a new pricing forecast model, or finally refactoring the core financial metrics. But the value of this work doesn’t discount the value of analytical maintenance—of keeping the key dashboards up, of making sure operational teams have quick access to information, and of reliably publishing the news.

By rejecting the identity of a service organization, we turn our queues of requests into to-do lists, a looming prerequisite to burn down before we can get to the bigger, more meaningful stuff we’re supposed to be doing. But there’s something to be said for embracing parts of the service role. Our backlogs are inevitable, and a service mindset can turn those requests into routines; they can become weekly work that isn’t an ante to do something better, but a healthy habit to be celebrated.

Just as a support team will never finish their work on the queue, we’ll never be done with maintenance. We can’t change that. But we change how we see it, and how we value ourselves on the days that we do it. 

1. Low bar.

2. I finally got that login, Jillian.

3. The second most memorable ticket I ever worked on started with a simple message: “Mode borked, you fix.” Though most issues didn’t start quite so starkly, this was life in support in a nutshell: Short, vague, and more emotion than detail. (The most memorable was the first ticket we got after our third major update to Mode’s SQL editor (codename: Return of the Jeditor). The user wrote in to tell us that something looked different, but “it didn’t look like a bug?”)

4. There is, it must be pointed out, a caveat to this. Men are more likely to issue the pedantic corrections that are, first and foremost, meant to signal how smart we are, and we’re more likely to get credit for being smart without needing to remind people of it. To be part of the solution, men, I think, need to not only stop trying to be the smartest little boy in the room, but also recognize the more subtle ways that people demonstrate their intelligence.

5. Say what you will about 1-to-10 scales, but they’re better than emoji scales. Intercom, for example, asked people to rate their support experience using a five-emoji scale where the highest rating was the heart eyes face ​​😍. On multiple occasions, customers told us they wanted to give us the top score, but didn’t, because it felt creepy sending their support agent a heart eyes face.