Not now, we're too busy

Support is busy. There are customers asking for help with the product, someone needs a refund but their card isn't accepting the funds, the engineering team just shipped a feature that nobody knew about, a product manager has been asking for categorized feedback on the previous product iteration for weeks, and the backlog keeps growing at a slow but noticeably steady pace. We don't have enough time in a day to get everything done and some things are going to have to wait. Or maybe not get done at all. It's stressful and aggravating, but that's how it goes.

Then someone on the team suggests that you all try a new process for handling requests from other internal teams. It'll take a few weeks to set up the system to manage everything, and to train the team on how to use it. Then someone will have to write documentation for the new system and the new process. You'll have to get buy-in from the other teams and show them how the whole thing works, too. It'll be a month of work, but in the end it will reduce the time spent on internal requests and cross-team communication by 50% to 75%. It sounds great, but there isn't time for it. Put that off until next quarter when we've tackled the backlog and we'll have time to deal with new processes.

To get a little autobiographical here, I've seen this over and over again in my years as a Support leader and Support consultant at a bunch of tech companies. It's not specific to Support, but it's exacerbated by the constant influx of requests from customers that can't be put on indefinite hold. Improving the way Support operates is rarely Support's top priority. They don't have that luxury. I've been the person putting off important projects and non-queue work because of the fear of a backlog. I've worked with companies where there was zero tolerance for extending their Service Level Objectives at the expense of overworked staff doing less-than-ideal work.

We've also heard similar stores from a lot of you, dear readers, over the past few months. It reminded me of the cartoon of cavemen dragging a wagon around with square wheels.

Hearing this common refrain from so many people reminded me of what it was like when I was on the other side of the conversation, leading a Support team that was constantly treading water. Only barely keeping our heads above the waves, constantly worried when one big wave would knock us all under. It reminded me of how helpless it can often feel.

But it also reminded me of how badly Support leaders need to step back and solve their team's deeper problems. Asking people to tread harder doesn't work. It also doesn't help to tell your team that "we just need to get through this quarter and then we'll have some room to breathe." I'm guilty of saying this more times than I'd like to admit, and all the people who were on those teams with me can probably count on one thumb how many times we got that room to breathe.

Here on the Yetto blog, we often say that we can't solve everyone's problems for them because everyone's problems are unique. And while that's often true, it's not true here. This is one problem that many teams have that can often be solved in similar ways. You are not too busy to improve your team operations.

Know what can slip

You can't do everything, so some tasks and projects will have to slow down or be put on pause. The only way this works is by knowing what work can be sacrificed in the short term. For some teams, it might be longer response times for certain types of support requests (e.g., feature requests or low priority bug reports). Other teams might let internal feedback get dropped for a little while or let customer data get stale for a month. As we so often say, it depends on your team and your customers. Whatever you choose, though, it will hurt a little. It's a sacrifice you need to make now in order to see improvements later.

If you're pausing something that other teams expect or depend on, let them know what you're doing and why. Tell the product team that feedback will be missing for a couple of weeks while you set up a new user feedback reporting tool. Explain to the sales team why they won't see updates on some of their accounts while you implement a better automation to keep things in sync in the future. Let customers know that you'll get to their request, but it might take a little longer than expected right now. Don't surprise people when you drop their work. Explain what's happening and how it will help everyone.

Know your team's limits

I've seen new managers try to do all of this and make a single, crucial mistake. They give everyone on the team two or three hours a day to work on project that will improve the team's operations. The team is excited about being able to fix something they've been dealing with. Morale starts to rise. Then the manager sees that the backlog is growing to an uncomfortable number, or they're hearing from another team's manager that Support is unresponsive to their requests.

The manager doesn't want to let anyone down, so they tell the team that they need to work on the backlog in addition to their project work. They're already a few weeks into the work, so they don't want to put that on hold - and the team is excited to see the payoff. But now they have to work overtime (literal unpaid overtime, in many cases) to get the queue back "under control" while also trying to finish up the operational improvements. The outcome is often an irritated manager, a stressed out team, and a half-baked team project. Things are worse off than they were before.

This could be avoided by following the advice above and letting everyone outside the team know what's happening and why. On top of that, the manager needs to be aware of what people on the team can do. Sometimes people will push a little harder and work a little extra if the outcome is worth it. But that can only be sustained for short amounts of time, and it should never be done by management fiat. If the team needs to work overtime to successfully complete a project, that needs to be clear ahead of time and, if possible, the team should be a part of that decision.

You don't want to let some projects slip and then find your team's limits. That's a recipe for disaster that you might not recover from.

Let things be bad

You've decided what work can slip a little and you have an idea of what "full capacity" looks like for your team. Now you need to allow some things to get ugly temporarily. It isn't easy, but it's important. Sometimes you need to let a few things get bad so that things can get better. It feels counterintuitive. It feels bad.

This can look like different things for different teams, of course. One way this can work, though, is by letting your support backlog grow a little. It hurts to see and some people on the team will need a little convincing. Support professionals, for the most part, are empathetic people who don't want to see customers suffer. But taking some time away from the queue in the short term to implement changes on the team can have an enormous impact in the medium-to-long term.

This might be a few people taking time out of the queue to set up a new internal tool. It could be everyone on the team taking a few hours a week to focus on training, or writing documentation. These sound like simple and obvious things, but we often push them off because we don't want to see our backlog grow or our SLOs slip. But we can decide up front that we'll accept that trade-off, and we can let everyone know what to expect. Ultimately, it will be worth it.

Celebrate the outcomes

Your team let the backlog grow a little for a month while they worked on a new product feedback process. Now that it's implemented, they're all back in the queue getting it back under control, working exclusively on that for another month. When all of that is finished, the team has a clear inbox and a better process for working with the Product team. That's huge. Celebrate that with the team. Not with a pizza party (although maybe also a pizza party... I love pizza). Give bonuses to the people who led the project, let people take some much needed vacation time, and let the team get back to a daily work cadence that isn't pushing them to full capacity all the time.

It's tough

Nobody wants to see the backlog grow or to drop the ball on other teams. Even when you clearly communicate why you're letting something slip and you are clear about when the other teams can expect you to get back to your normal cadence, it feels bad to people on the team. Make it clear that this is a temporary change of direction that will help the team more than it will hurt them. Because waiting for the right time to improve the team will have you waiting forever. Make things better now, not in some mythical future quarter.