Lurking on the internet forums related to software engineering, you will often find people asking questions like:
- Is getting accepting a support role bad for your career?
- How do I get out of a support job?
- Is technical support experience valuable?
I found myself asking these same questions some time ago when I unwittingly accepted an offer that turned out to be a support engineer role. I was inexperienced and eager to land a job so I never thought about clarifying what the exact responsibilities of the role are going to be. When I turned up to the new job on day one I was mildly frustrated to find out I was to be part of a support team. It became only more unpleasant that I had to work non-traditional hours, starting my day in the afternoon and ending it in the late evening which meant I would reach home after midnight. Setting aside the logistical challenges I am going to talk about what observations I have made working in support and how has it impacted me both in a positive way and in a not so positive way.
Support work can often boil down to menial operational tasks.
As a member of the development team, I always had the luxury of knowing the nature of tasks I am supposed to accomplish at least a few days in advance, although nothing is ever set in stone you generally are prepared. This is usually not the case in a support team. The kind of work that comes your way depends on the tickets raised.
Sometimes they can be interesting production issues that help you learn new ways of doing things but usually, they may just be janitorial tasks like changing some settings in the backend, updating a file, or resetting a password.
Your work depends on external factors.
If you are an employee at a company, you usually do not control the kind of work you end up doing. It is often dependent on the type of clients you get, sometimes it depends on the budget your team has or the priorities of your company as a whole.
When you work for a support team, you inherit all those things and some more. The work you end up doing depends on how well the application was developed in the first place, how well it was tested, how well the code was reviewed. What time or resource constraints did the development team had to accommodate, how successful had the launch been, what issues do end-users care about the most, the list can go on like that.
I am not saying that working in support is inherently bad, but it definitely has it's share of downsides. If you do not enjoy ad-hoc work coming at you or daily reprioritization, then support may not be a good fit. If you do not enjoy fixing bugs in someone else's codebase, then you may not enjoy working in support.
On the other hand, there are some good things about working in a support team.
Talking with customers and building a feedback loop.
Support tickets are a good indicator of how good a software application has been delivered to the intended customers. In some sense, they form an open channel for generating feedback. As they usually say, where there is a problem there is an opportunity, it becomes really critical for the success of a project to be constantly listening to what the customers are saying. The concept of MVP and agile methodologies have been developed out of this very need. The key to innovating at any software company is keeping the feedback loop as small as possible, so as to keep iterating on the product.
Traditional support teams are not seen as part of the agile/scrum team. Support usually falls outside the purview of product development, but many companies like Stripe, Zapier, Basecamp, etc have become aware of the advantage of having support bridge the feedback loop.
Even though your company may just be treating support as a tactical solution to keep the lights on, you can still learn a lot by finding patterns in the tickets being raised or talking with customers to understand underlying problems with requirements or design. Proactively making a plan to reduce support tickets at your workplace is a very desirable skill to have. Working in support allows you to do just that.
Cross skilling and becoming a valuable player.
Drawing on the above theme of "challenges equal opportunities" and the fact that you might have to improvise when handling certain kinds of support tickets, you can definitely make a case for potentially gaining experience with skills outside what you would normally practice in a traditional development team.
As a backend engineer, there are numerous opportunities to explore the DevOps and Software Architecture aspects of software applications. I would assume there are similar opportunities for frontend engineers in improvising design changes (I have rarely heard of designers being part of support teams, although I strongly believe they should but that's a topic for another day.)
What is ideal?
As I write this blog post I have managed to articulate some of my mixed feelings about working in support. There is definitely an upside to being in support. And there are obvious downsides. You must be already thinking, why do teams have to exclusively do support or development but not both. As it turns out some engineering teams do aim to own both aspects of building and maintaining a software project.
But managing both support and development can get out of hand if not proactively managed. Most developers love to be in a state of flow which can be hard to achieve if you manage support tickets. Triaging support tickets becomes a crucial part of the process so the developers do not have to context switch for longer periods of time.
What makes one a good support engineer?
Support teams generally have to deal with well defined SLAs. As a support engineer, you will quickly get accustomed to hearing terms metrics like Mean Time to Resolution or Mean Time to Response. These are usually tracked by service desk tools like Jira and became a very important part of both measuring performance of the team but for the team itself, it becomes a crucial part of daily activities to be diligently making updates on the tickets. Although this quality is desirable in support engineers it comes under "necessary but not sufficient" set of qualities.
It is somewhat ironic I felt, that the thing that helped me most while working as a support engineer is the experience I had working in development teams. The best developers automatically tend to be great support engineers. Skills like being able to navigate legacy codebases from day one, being good at debugging techniques, knowledge of cloud providers, and their logging mechanisms, become crucial parts of a support engineer's toolset.
I speak from experience working in dedicated support teams, dedicated development teams, and teams with dual responsibility. I have not worked at the likes of Amazon and Google where they might have figured out these things long ago. Starting out as a self-taught developer one may not have the luxury of choosing your ideal job. I want to give a perspective for such developers who may want to consider taking up an offer for a support engineer.
I would like to end with a quote from an article on Aeon, titled Hail the Maintainers which, I feel, encapsulates the essence of working in support teams.
Innovation is a dominant ideology of our era, embraced in America by Silicon Valley, Wall Street, and the Washington DC political elite. As the pursuit of innovation has inspired technologists and capitalists, it has also provoked critics who suspect that the peddlers of innovation radically overvalue innovation. What happens after innovation, they argue, is more important. Maintenance and repair, the building of infrastructures, the mundane labour that goes into sustaining functioning and efficient infrastructures, simply has more impact on people’s daily lives than the vast majority of technological innovations.
Thanks for reading!
Please let me know your thoughts in the comments.
Photo by Markus Spiske on Unsplash
Top comments (0)