All too often, working in technical support at highly technical companies is viewed as a stepping-stone to development, sales engineering, or other roles. And that’s a fine path for those who want to take it, but it doesn’t always have to be that way.

I've definitely had many support engineers join various engineering and success teams after their time with me, and it's always a bittersweet day. I'm proud of their growth, but sad that I won't get to see their efforts first-hand anymore.

On the other hand, I am a firm believer that technical support is, itself, an entire career path, from entry level to industry-impacting terminal levels. The trick is you must be willing to invest in your team to allow folks to get there by giving them the resources and, most importantly, space to explore and do meaningful work that is not just grinding on tickets.

The most important conceit here: the career trajectory of a support engineer is not measured in tickets. Tickets are the table stakes, and increasingly less important as they level up. Rather, as a support engineer advances, leverage is the important thing to strive for. Unfortunately, leverage is not easily quantifiable, which means assessing the growth of a support engineer requires lots more work and attention. For your entry level folks, sure, make sure they're hitting whatever reasonable numbers you set. But promotion is based on the ability to improve individual impact: are they becoming more self-sufficient? Are they unblocking others? Are they spotting patterns and providing clear evidence-based feedback about it?

As they progress through career levels (whatever that looks like at your org) you should be looking at how broad that impact becomes. The higher the level, the greater the expected leverage from the work. The path might look something like:

self-sufficiency: What can I do to handle my own work better?
peer impact: What can I do to help my peers accomplish more?
whole-team impact: What can I do that makes everyone more efficient?
cross-team impact: What can I do to make other teams better?
whole product-area impact: What can I do to make this whole feature better?
whole product impact: What can I do to improve the entire product experience?
whole company impact: What can I do to increase the odds of company success?
industry taste-making: What can I do to share our wins and help the industry standard improve?

There are support engineers who are able to operate at all these levels, and building folks along those lines will result in better tickets and better ticket metrics as a natural consequence instead of a goal. Mostly without having to focus on how many tickets someone does or even the specifics of the tickets themselves. Each of these is much harder than the last, and reaching those levels also becomes increasingly rare, but support leaders should strive to leave the door open to all of these.

When it comes to keeping up with how support engineers are doing, for the most part, I don't use metrics on an individual level except as an indicator of something to talk about. Are you below median? Could be a run of hard tickets. Could be because instead of tickets, you spent a couple days doing something that eliminates or greatly reduces an entire class of issue. This is something for us to discuss, but not something to, by default, make specific goals about. Same goes for the other basics like CSAT, First Response, Escalation rate, etc. There are many reasons why these may differ, and not all of them are negative. I look for their progress on that path above. Are they moving beyond doing only their own work well and raising the bar for others instead? I always hope the answer is yes.

Of course the schlep and the core work of ticket resolution still has to get done. It's not a free for all and you still have to care in aggregate about the numbers. And sometimes you just have to ask folks to focus on the grind. Reality is rarely so clean. But if you want the best result, provide sufficient room for the ones who will really stretch themselves to do so without having to worry about individual metrics as the deciding factor for whether they've done well at the next performance review. Setting naive individual metrics someone must hit OR ELSE is extremely common, and as Goodhart's Law tells us, turning a measure into a goal makes it a poor measure.

I have watched support engineers, free from the worry of ticket quotas, spend 2 days really diving into the patterns in the queue. They, themselves, worked almost no tickets directly during that time. But on the other side, they had created clear, thoroughly researched artifacts that could be handed to product teams to resolve a whole class of problems, plans for how support can efficiently handle them in the meantime, and enablement materials for getting the whole rest of the team trained and able to handle large swaths of problems better.

I've also seen them be able to take time out of the queue to deeply embed with engineering teams to become experts on a particular feature. That expertise allows them to level up the rest of the team and provide critical feedback directly into the heart of the engineering teams so they really understand the user experience of their products. This produces better support, better products, and better experiences for everyone: users and employees alike.

None of this happens in a vacuum, and the ticket work must still get done, so you can't let everyone do this all the time. But really good support leaders plan for this in headcount and capacity analysis. These are high-leverage and force-multiplier pieces of work, and they give support engineers the chance to do what they do best: solve problems. Only these are YOUR problems, and the really good ones will take as much care of you as they do your users.

These are the real growth moments, and these are the places where you can let your engineers grow their impact. They'll create relationships across teams, become company glue to pull together disparate parts of the business, and raise the bar for everyone along the way. But only if you let them.