Support is a dead-end job

Support has no career path. You're expected to start in support in order to move into engineering or product management or project management or sales or literally any other job. We - the collective "we" of people working in companies and managing teams but especially the "we" who manage support teams - don't fully value the work of Support and therefore do not value the work of the people doing the work of Support. They're the "agents" or "customer care representatives" or "support engineers" or whatever they're called at your company. Let's call them Support Professionals here because that's what they are. And if we treat them that way, it will improve their careers, improve their lives, improve the lives of customers, and ultimately increase your revenue, which is what keeps you employed. See? It's a win-win-win-win-win.

First let's talk about why we don't do that, though.

The current state of Support

We often complain amongst ourselves, when we think we're in private company, that Support is shat upon. We don't get no respect, as they say. That lack of respect comes from a lack of understanding. People generally don't know what the work of support entails and, more damagingly, they don't know what skills are used to do the job. Many people at your average SaaS product company, for example, would likely say that support work needs to be done. They know that the product isn't perfect (yet!) and that some of the documentation may be missing or out of date, so somebody has to answer the customers when they have questions or problems. The engineers and product managers would likely also say that they themselves could answer all those questions, it's just not the best use of their time.

That is precisely why the company hires support teams - to do the work that other teams could obviously do but are too busy to deal with. It's cheaper to hire people with fewer skills, teach them how to answer the questions that other teams already know the answers to, and let them respond to all of the customers while the other teams do more important work.

(For my fellow Support folks reading this, I apologize for the rage that paragraph just induced. I should include some sort of trigger warning at the beginning of posts like these.)

I'll say here that I don't think anyone in the above situation is doing anything malicious. If you ask your average engineer at your average SaaS product company they would likely also tell you how great their support team is, and how difficult their jobs are, and how much they respect them for the work they do. My guess (and it's only a guess because I'm not a mind reader) is that the "work" they think is difficult and worthy of respect is the work of communicating with other people all day every day, the work of saying the same things over and over to people, the work of staying calm and helpful in the face of rude emails and phone calls, and the work of being the smiling face of the company to anyone who contacts them. And yes, that is all work and difficult work, at that.

But it isn't all of the work, as anyone who has done this for any amount of time knows. Because Support Professionals will often remind anyone that will listen that the other teams do not usually have the correct answers to questions about the product. The Product Mangers and Designers and Engineers are responsible for building the systems that customers use, of course. They bring it from concept to reality, and that takes a lot of time, energy, patience, and skill. After the product is let loose on the world, though, they usually move on.

The discrepancies between what they've built and what the customers experience, though, is often vast. We often think of software bugs as the core difference between an ideal state and its real-world state, but the truth is much more complicated. People use products in unforeseen ways, with unexpected outcomes. They use the product your company has been focused on building alongside dozens of other products that you have nothing to do with and often know nothing about.

It is Support's responsibility to close the gap between how a product is meant to be used and how it gets handled by real people. And when we try to bring in those other teams to reset expectations, Support Professionals will also remind us that other people at the company are not often available to lend a hand. They have often moved onto the next project because that's how their role operates.

Support's job is not just communicating. The job is problem solving, research, discovery, and documentation. The communication is maybe the easiest part of the job. Digging through other people's code reviews and experimenting with a production application in order to understand what new features are doing is a regular part of the job that never even shows up in their performance KPIs set by the leaders of their own teams.

(Again. Sorry for that eye twitch.)

Misunderstandings stifle growth

The behavior here isn't malicious, but there are harmful ramifications of how teams tend to treat Support (the work of support and the Support team). There are a lot of side-effects, from other teams making Support work harder by not understanding how their work affects Support's to mis-managing Support teams by judging people against performance metrics that don't reflect the challenges and successes of the job. However, the issue I'd like to dig into a bit deeper is how the misunderstanding of the Support role limits the scope and path of a Support career.

At many companies, there is no career track for a Support Professional. They can likely get promoted from "Tier I" to "Tier III" (or even "Tier IIII" if their company has a level that high), but if they choose not to go into management or to "graduate" to another team then their growth path is stunted there. A Product Manager at the same company may have "Level 1" through "Level 10" or "Junior Product Manager" to "Principal Product Manager" paths with no less than five (but often as many as 10) levels in between. That kind of growth can take a decade or more to achieve.

Support, on the other hand, can be maxed out in a three-year span in many cases, maybe five if we're being conservative. At that point, managers will expect the top performers to either become managers themselves or leave the team to become a Junior Engineer or Junior Product Manager. That's right. Management will tell you that your five year career path brought you up to the lowest level of another team, if they'll have you at all, despite your ability to navigate the internals of the product and the byzantine communcation channels internally that make you as successful in the job as you are.

(I'll stop doing this.)

Support churn hurts your company

For the Support Professional, there are several downsides to staying in Support for even the short amount of time it takes to hit the ceiling of career growth. The biggest reason is probably that the pay is almost always lower in Support than an equivalent role on another team. Again, this is because Support is paid for communicating with empathy and not for problem solving, research, discovery, and documentation.

There are downsides for the company, too, though. With a constantly churning Support staff, the knowledge of the team needs to be replicated repeatedly. It takes a lot of time for people to learn everything that the most tenured person on the team knows (or knew right before they gave their two-weeks notice). Seasoned Support Professionals at a company may have been there for a couple of years and in that time have developed a wealth of knowledge about the product, the culture, the code base, and how to navigate all of that to solve customers' problems. And the best Support Professionals manage to solve many of those problems before a customer ever complains, even though there's no performance metric for Twitter complaints not received.

(I couldn't help myself on that last one.)

I think you should treat Support Professionals better because they're good people doing good work. But it's also true that treating them better would be good for your customers and good for your business. Recognizing all of the work that goes into Support means setting expectations around things that often get ignored by management - reading other teams' code reviews, writing internal documentation, experimenting with the application to reproduce bugs, experimenting with unreleased features to make sure they'll behave the way customers expect them to behave, understanding how customers will use the product with other products, and communicating clearly and with empathy to both customers and internal colleagues.

This work is worth compensating people for. It's also worth training people for, promoting people for, and hiring people for. There are more ways to use the skills developed over years of work in Support at a single company than by taking them to another team. Those skills could be nurtured right there in the Support Organization. How much more could the Support team do if they were given the tools and the time to go do more of what they already want to do? How much could Support Professionals grow if we gave them the permission to dig deeper and wider in their work?

Ways to make Support better for everyone

At this point, you probably want to see an example of a successful career ladder for a Support Professional. Unfortunately, I can't provide it here. I haven't seen one in practice. However, here's an idea of what it might look like.

Level	Title	Research scope	Documentation scope
1	Junior Support Agent	Uncovers user-reported issues with the product/service	Documents user-reported issues for internal teams
...	...	...	...
4	Support Agent	Uses their knowledge of customer behavior to uncover design flaws prior to releasing the product/service	Documents user feedback and common behavior for internal teams
...	...	...	...
7	Senior Support Agent	Uses their knowledge of customer behavior to uncover new product/service features during concept/design phase	Documents common and uncommon customer behavior and provides internal teams with guides to using the product from different customer persona perspectives

This is a rough sketch of what I might start with. I'd want to see other scopes on that list, too - third-party product analysis and discovery, for example, and relationship building (which is a whole separate topic I didn't even touch on here). I'd also want to see as many levels in a Support career ladder as there are in Design and Engineering, because the work is no less rich and no less important. Once we have that sketched out, we'll realize that there should be slightly different career ladders for the different types of support your company provides (a trust and safety support path, a developer support path, and more).

Every company is different and every product is different. I used SaaS product companies as an example here because that's what I'm mostly familiar with, but I've seen the same situation in hardware companies and service companies. The growth paths will look different from one industry to the next, one company to the next. They need to be built from the ground up, because currently nothing exists there. We need to have some difficult conversations with HR and the executive team to create career paths where none existed. Support is misunderstood, disrespected, and underpaid. It's hurting people and it's hurting our businesses. And it's our responsibility to change that.