On the frontline: The Support experience and how it relates to Engineering

A couple of weeks ago, I was browsing through Tech Reddit and found a thread giving advice to junior engineers about how to get into Tech. One of these pieces of advice was to enter “through the sidelines”, for example by joining the Support team. This post resonated with me for several reasons: I started reflecting on how customer interactions are really valuable for an engineer - also, it was connected to my own experience: for the most part of my career, I’ve been working in some sort of technical support. Technology has always been my passion - so through dedication and a couple of choices I ended up in Engineering. Even today, I profit from that experience and can definitely say I’m a support guy at heart. Therefore, a fitting first blog post that serves as a reminder of how my roles in support sent me down the rabbit hole ultimately leading me to Engineering. In this post, I want to share key takeaways on how these skills directly impact engineering and problem-solving.

Knowing your customer

Let’s begin with the obvious fact: knowing your customer is actually really helpful if you intend to build something useful. Most engineers, though, have rarely spoken with actual customers - and if it happens, it is mostly for these two reasons: There’s a really tough edge case / bug that needs an expert in that topic or there’s any other highly technical discussion where specialties are required (e.g. security, certain protocols etc.). This is all perfectly valid but it misses a crucial point: When the cavalry (the senior engineers) is called in, things are either escalated or just too complex - the basic use case is not up for discussion or visible anymore.

When you work in Support, you interact with the customer on their day-to-day operations - depending on your product it might be something really relatable (e.g. tooling for engineers) but most likely it is someone outside of Tech using the product to actually do something very different. Talking with customers working on their Word documents or Excel documents might seem anachronistic for an engineer being used to work with cloud offerings like Github, Gitlab, or Jira. At the same time, these engineers are tasked with finding the right solution for this job - a challenge that surely gets easier if you can answer the “why are they even using our product” question. Once the why is addressed, it is easier to think about the how. Customers will not share this information for free though - you need to hear them out first.

Understanding customer pain

Most interactions in Support start with some problem. Obviously the severity greatly varies - but still, it is a biased view starting with issues. When engineers think about a bug, they mostly do so in quiet, taking for granted that someone else gathered all possible information available to narrow down what is actually going on.

If you have to hop on a video call and see how customers actually use the product, how they see it, how they fail to solve either simple or highly complex tasks, you realize that your assumptions do crumble with just a few clicks. “Oh, so you cannot drag & drop this?” - well it might seem obvious for the person who wrote the frontend, but it is not for the end-user. “So you’re telling me your product does not support bulk operations?” - sure, your CRUD API only supports individual inserts, and you don’t want clients to handle individual API calls - but have you ever tried to fill the same form more than 50 times? When you work on Support tickets, this is pure gold waiting to be harvested by your Product team - but there’s a fine line though: Customers are quick with providing solutions to their problem. The real challenge is understanding the core of that problem - the pain - and distilling it, so that it can be solved for more than just one customer. Once you reach the essence of the problem and you remember that one session where the user could not find that one menu for 15 minutes straight in a video call you’ll certainly increase the probability to actually address the problem your customers have instead of relying on some wall of text from your local product manager. But wait - there’s more - you’re not just the messenger delivering feature requests or problem statements. Your expertise in using the product is also urgently required, if you want to help customers.

Understanding your product

Imagine working for any recent software product without the knowledge of basic IT topics such as browsers, cookies, tokens, caching, and APIs - this list could go on and on. Sure, the engineers building your product are the experts in building mobile apps, your distributed microservices backend or your fancy desktop app - but when any of it crashes, someone answers the virtual phone (usually via mail / ticket) and goes on a deep dive. In Support, the mission is clear: solve the problem – this can actually mean very different things viewed from different perspectives. In many cases this means using a workaround until a feature is completed or working around the quirks of some product decisions haunting your product for many years. This requires expert knowledge of the product in a way that the engineers that build it usually don’t have - not because they lack the skills but because of perspective. In Support, you see the external view - the product is a black box with defined interfaces waiting to be abused by customers finding the one use case that breaks your UX designers’ best intentions. Engineers see the internal context first - they know exactly why the API semantics are built the way they are or that button is placed exactly as it is now. Getting to know the product from a user’s perspective is a crucial skill in order to enhance what you are building - but it’s not enough - you need to deliver a viable solution in time.

Get stuff done under pressure

The final point I want to make is delivery - when your job requires you to get in that one escalated call to make your customer happy again, you learn to solve problems under pressure. There are countless takes on Engineering productivity - elaborating on how estimations are bad or which methodology works best. My take on it is this: In Support, you either fix it or face the consequences - it’s not your product manager looking over your (virtual) shoulder, it’s an angry customer waiting for a critical issue to be solved. This means that you learn to hack things under high pressure to mitigate something and you settle for the most basic scope: Solving the actual problem — not a single line more. Understanding the core problem to solve, the bare minimum to satisfy, and delivering it on time is a very valuable lesson that brings in a different perspective.

Conclusion

To sum this up: As someone having spent years doing some sort of technical support, I clearly see the advantages of such a path.

There’s no faster way to get to know your customer, their pain and your product all by just a few interactions.

There are some companies that are fully aware of this and even have programs / rotations as either some sort of Support week, or part of the onboarding process. Is Support therefore a good starting point to get into Tech? As with all things — it depends. Sure, this will not “float your boat” if you absolutely dislike talking to other people. It sure is not the path for everyone. I do think though that many engineers would profit from being there on the frontline, feeling the failures and seeing the product with different eyes. So if you are stuck in your SCRUM meeting and wonder why you’re building what you’re building, don’t just wait for someone else providing the context - go join your support team, even if it’s just for one call gain a perspective on your product you won’t get anywhere else.