Negative Maintenance: Why Support Should Grow Slower Than the Company

Nobody contacts support because they want to. They reach out because something broke, or because the product asked them to figure out something it should have made obvious. Every ticket is a symptom. The queue is a live readout of everywhere the product is failing to explain itself.

The default job of a support team is to clear that queue. Answer quickly and keep the backlog from growing. Do it well and you get a healthy CSAT score and a short time to resolution. You also get the same ticket again next week, because nothing you did touched the reason it was filed.

The alternative has a name. Serval calls it negative maintenance, and made it one of three operating principles: make things happen and remove bad things. Most teams aim for low maintenance, keeping the system running with as little overhead as possible. Negative maintenance aims past that. Every system you touch should need less touching after you leave it than it did before.

For support, that has a precise meaning. Every ticket you touch should lower the odds of the next one. Not resolve it faster. Make it less likely to exist. You close the ticket in front of you, and you subtract a little of the reason it showed up, so the queue gets quieter on its own.

This is not a team firing itself

The obvious objection is that a support team killing its own tickets is voting itself out of a job. It isn’t.

A company worth working for is winning and growing, and a growing company sends you more customers every quarter. More customers file more tickets. If support headcount tracks ticket volume one for one, the team grows in lockstep with the company forever, a fixed tax on every new customer. Killing tickets is how you break that ratio. The team still grows. It just grows slower than the customer count instead of matching it.

The incentives line up better than they look. A ticket is a symptom, so removing its cause makes the product a little better and the customer a little more satisfied every time. Nobody enjoys having to contact support. The quieter your queue, the more often the product simply worked.

And if your customer base is not growing, none of this is your real problem. That is a different and worse situation, and not one I would choose to work on.

Ways to subtract a cause

Closing a ticket and killing its cause are different amounts of work, and the second is usually slower. The moves themselves are not exotic.

Ship the fix. When the cause is a bug small enough to patch, the ticket and every future instance of it die in the same pull request. I made the case for support shipping its own fixes separately. It is the cleanest form of negative maintenance there is, and also the narrowest, because most tickets are not bugs.

Fix the thing they had to ask about. When you answer the same question for the fortieth time, the question is the defect. The fast response is a saved reply that makes answering it painless, and that is the trap. A good macro lowers the cost of the symptom enough that nobody ever pays to remove the cause, and the question outlives everyone who learned to answer it. Spend the macro’s time once on the doc or the error message that stops the question from forming.

Escalate a diagnosis, not a complaint. Most tickets you cannot fix yourself, because the cause lives in a system you do not own. A bug report hands engineering a problem. A reproduction and a proposed fix hand them a decision, and a cheap one. Half the time they merge it the same day.

Change the product so the question cannot occur. This is the strongest move and the rarest. Support is the only function that watches every customer hit the same wall, at volume, and can say exactly which wall and how often. That signal is worth more than any survey, and it usually dies in a ticket field. One setting had never graduated from beta, so enabling it stayed gated behind support, and for years the queue filled with the same request: turn this on for me. Support absorbed it quietly, thousands of times, every ticket resolved and not one of them subtracted, until the signal reached the people who could change the product and the setting became something customers flipped themselves. The whole category retired in a single release.

The comfortable product

Absorbing a problem is always cheaper than removing it, and the better you get at absorbing, the more people the pain gets hidden from. A macro hides it from your teammates. A doc hides it from the next customer. A workaround hides it from everyone, including the engineer who could have removed the cause if they had ever felt it.

That is the trap inside the trap. Get good enough at absorption and you become the reason the product never improves. Customers still hit the wall. But the queue is quiet and the workaround is documented, so to everyone upstream the product looks finished. A support team that absorbs everything perfectly is indistinguishable from a product with no problems, right up until the customer leaves for one that actually has none.

Negative maintenance is supposed to relocate pain to the cheapest place to fix it, not erase the evidence that it exists. When the cause lives in the product, a flawless doc is not the fix. It is insulation, and it lets the people who could change the product go on believing there is nothing to change. The disciplined move is to resolve the ticket and still let the cost stay legible upstream, sharp enough that it lands on the desk that can remove it. Make the customer whole. Keep the cause visible.

The catch

Negative maintenance is slower per ticket, and a team that is underwater cannot do it. If every engineer sits at the edge of their queue all day, there is no hour to spend writing the doc that shrinks next month’s queue. Someone has to allow that hour. It is a resourcing decision a manager makes, not a virtue an individual can will into existence on a drowning team.

It also depends on the rest of the company. Support can diagnose a cause it has no authority to remove. If engineering will not review the escalation and product will not change the empty state, the signal dies and the team goes back to clearing the queue. Negative maintenance for support is partly a request to be let upstream, and it only works where the rest of the org takes the handoff.

Make it someone’s job

On a small team, one engineer does all four moves between tickets. They answer the question and write the doc, file the bug and propose the fix. Negative maintenance is a habit squeezed into the gaps. That stops working the moment the queue is big enough that there are no gaps.

So you make each move a job. The four moves are roughly the roles a support team grows into. Someone owns the docs, and “fix the thing they had to ask about” is their whole job instead of a stolen minute. Someone owns tooling and deflection, and builds the systems that make every other subtraction cheap and countable. Someone owns escalations, and turns the hardest tickets into reproductions engineering will accept. Someone owns the product signal, and carries the wall the whole queue keeps hitting to the people who can move it.

This looks like it contradicts the whole point. Support should grow slower than the company, and the answer to the catch is to hire. Both are true, because there are two kinds of support hire. A front-line engineer’s output scales with the hours they spend at the queue, one customer at a time, a fixed tax on every new account. A knowledge manager’s good doc answers the question for every customer who would have filed it, including the ones who never write in because they found the page. One role, the whole queue. The first kind of hire tracks the customer count. The second kind bends it.

That is what growing slower looks like up close. Not a smaller team, a differently shaped one, where a rising share of the people are paid to make tickets not happen instead of to close them. It is also the easiest spend in the company to cut, because the result is an absence. A salary sits in the budget with no queue next to it, and a finance review reaches for the pen. The teams that keep these roles are the ones that already believe the queue they don’t have is worth paying for.

The work you can’t see

Think about the best support engineer you know. The evidence of their work is hard to point at, because it shows up as absence. The question that used to arrive every week and quietly stopped. The bug that got closed once in a pull request instead of a hundred times in the queue. They are not the person who closed the most tickets last quarter. They are the reason the queue is smaller than the customer count says it should be. The best support is the kind nobody had to ask for.