Career laddering in Support

I saw a really interesting post on LinkedIn the other day from Brian Levine talking about how support is a “dead-end” job.

The premise of his article was effectively that in many companies Support is often seen as entry level, with no possible advancement in the organization outside of management. While his proposal discusses laddering up to “Senior” positions, I find that this may be aiming too low when looking at deeply technical support work like with many “enterprise” products.

Granted, my view on this is a bit biased from having hit the “Senior” ceiling at two different companies in Support organizations (IBM and GitHub), however where Brian and I differ on this is that I don’t think having a ceiling as an IC in Support is necessarily a bad thing…

What have other companies done?

There are a few companies out there that have Support tracks leading up significantly more senior levels (“Staff+” in industry terms), and two examples of these are Elastic and GitLab. From speaking with folks at both companies, the more senior you are the more your responsibilities align (in some cases directly) with engineering or management roles. Certainly, from reading through GitLab’s job description for a Staff Support Engineer, this reads almost exactly like a Team Lead/Manager role, minus formal people management responsibilities. For what it’s worth, I don’t find this surprising as it’s exactly the reason that many Support organizations don’t bother with advancement opportunities to that level. When you start mixing management or TPM responsibilities into an otherwise engineering-focused role you wind up with both being done poorly, or at least two jobs that would better be done by two focused parties.

What really stands out here is that Elastic’s role is more engineering focused, however there’s little to no public information available on this so I’m drawing some conclusions from discussions with engineers there. In short, it sounds like they’re more in line with “traditional” L3 support - engineers that have a support rotation for escalations and/or specific critical issues. This was certainly a common approach in IBM when I worked there, and it worked extremely poorly. The engineers in those roles were never able to reliably deliver on both their support obligations (escalations would linger for months) and their engineering responsibilities, and more often than not they were more heavily incentivized to focus on their engineering obligations. While that may sound like the opposite of what you’d expect, I want to throw some ideas around as to why that’s the case, and why I think anything beyond extremely tactical “Staff-ish” level roles in Support are not common or needed.

Impact

Let’s assume, for a moment, that your Support organization has roles going all the way up to “Principal” or two levels beyond “Senior” (Senior -> Staff -> Principal). What are you expecting out of a Principal Engineer in your organization?

As a Principal, are you dictating how day to day operations can be improved? That feels like a significant amount of management-track overlap as operational effectiveness is their raison d’être.

Are you helping steer product direction? I’d argue this is the role of everyone in support, but beyond a certain point does it make sense to just pivot to being a product owner?

Are you directly making product improvements? I want to focus on this one for a moment as this tends to be where I’ve seen the most focus. My argument against this is that someone with a skillset enabling that type of work is already in a position where they’d be better serving their peers and their company in an engineering-focused role since the work they’re capable of can have significant impact beyond the scope of the Support organization. With that said, if a Support organization is designed to be very closely integrated with Engineering (or directly part of it) I do see this being viable (ala “old school” L3 support) however this comes with caveats discussed earlier in this article.

What are some other options?

Another scenario I’ve seen that does remain somewhat directly Support-aligned is “Supportability Engineering” which is effectively an engineering team focused specifically on addressing customer pain points or critical bugs.

The challenge I’ve seen with this team across several companies is that they’re wholly a cost-center so they can be very hard to justify, especially as it has direct overlap with work that engineering teams should already be responsible for. Another concern here is that the immediately inherited technical debt can be crushing, and still require extensive collaboration with otherwise-owning engineering teams to progress due to domain specific knowledge requirements.

I’d suggest a “Supportability Engineering” approach is probably the most realistic for many companies if they want to adopt a Support-specific upwards ladder, but at the same time it’s such a grey area that it almost feels like putting a new coat of paint on an engineering position and calling it support.

Another opportunity for those interested in a less/non-technical path is to move into something like a Customer Success role. These often have some level of technical knowledge requirements, but are far more focused on relationship building and business problem solving. As they’re inherently a revenue generating role, defining your impact can often be as easy as pointing to numbers, and you can focus your projects on amplifying those numbers rather than some of the more nebulous metrics like “ticket avoidance”.

So what do you suggest?

I think the “dead-end” comment is click-bait, to be honest. Sure, Support in most companies has a very hard ceiling for that specific path, however that’s true of any number of jobs across any number of industries.

Support is an outstanding foot in the door for a company as it lets you learn about nearly every aspect of its operations, and critically it gives you direct exposure to real world usage of whatever product you’re supporting.

If you’re moving into a Support role for the first time, or reaching the “top of the ladder” in your organization, I encourage you to understand what other roles are available for you to progress into that will not only increase the height of that ladder, but allow you to utilize the skills and knowledge that you’ve built to accelerate your progress there even more rapidly.

Having “recently” (nearly two years ago) made the move out of a Support organization into an engineering role, I can say without hesitation that the knowledge and skills I built in support were fully transferable over to my new role and gave me a massive advantage in terms of knowledge around how the company and product works that even veterans in my organization don’t have. Obviously I do not have all of the domain specific knowledge I need, but I’m now part of an organization that has a career path up to a “Distinguished Engineer” level and I’ve got all the building blocks I need to progress further.

Churn

The biggest concern brought up by Brian’s article is that of knowledge loss as a result of churn out of the Support organization. I want to take this a step further and say that if that knowledge remains in the company (e.g. an individual moves into a non-Support role but remains with the company) that’s almost an ideal outcome. The goal here needs to be retaining those individuals within the company, not specifically within Support, especially if the work they can do elsewhere can improve the experience for Support and customers alike.

From my own experience, those who move from Support to other organizations often tend to keep an eye on Support-related matters (technical ones, at least) and it tends to be quite easy to “nerd snipe” them as they know how challenging the role and its associated problems can be. This creates little, informal, feedback loops between customers, Support, and Engineering organizations in ways that otherwise would likely never happen.

If you’re the manager of an engineer who you find gets “nerd sniped” by Support on a regular basis I recommend not only celebrating that, but making sure that you can capitalize on the feedback that your team is getting from it. Is there information coming through that channel that will allow you to better prioritize your upcoming work, or at the very least have discussions with the PM for your product to get a deeper understanding of how to avoid these problems? At the end of the day, these problems will likely land with your team through formal means (which you can still direct your snipee to request) so this likely isn’t something that’s eating up unexpected time.

Closing thoughts

I’ll leave it with this question for now - as you explore more senior levels (let’s say “Staff+") within your Support organization, what do you see their role being? How are they having an impact that justifies that leveling better than moving those seeking promotion to other areas of the company?