Re:Role | Tech Support, Deconstructed

  |  Compiler Team  
Weiterbildung

Compiler • • compiler-re-role-technical-support

compiler-re-role-technical-support

About the episode

To some, working in technical support can seem equal parts stressful and mundane. But through building relationships, sharing knowledge, and practicing empathy for users, one can stretch beyond the help desk to become a trusted partner for customers as they navigate critical issues and business challenges.

The company, its business activities and its employees depicted in this podcast are fictional and are not intended to represent or depict any current or former business organization or any individuals living or dead. Any resemblance to any individual or organization is purely coincidental.

Compiler team Red Hat original show

Abonnieren

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transkript

Our startup has shifted significantly since they started out. Now, their focus is scalability, getting their product to different audiences and identifying new markets. Things have also changed internally. The sysadmin serves the guiding hand for maintenance outages and server issues. The tools development teams need are working properly and their digital strategy is more robust, complete with a knowledge base for users who encounter known bugs or have particular use cases. It's a well oiled machine, but here comes some complexity. There are scenarios that go outside of that knowledge base. Customers in those situations are frustrated. They want to talk to someone, anyone, who can help them. A cross-functional team has created a ticketing system to keep track of it all, but they aren't fully dedicated to resolving these issues, developers and programmers have other tasks and very limited capacity. The product manager, while doing their best to act as a go-between is a bit overwhelmed. After all, they need to account for requests coming from internal stakeholders too, and the tickets keep coming in. There needs to be someone who can engage customers and resolve their issues in a more proactive way. The core team decides it's time to look for someone who can fill a tech support role. This is Compiler, an original podcast from Red Hat. I'm Johan Philippine. I'm Angela Andrews. And I'm Kim Huang. We're following a fictional startup as they grow their business. As things move along, our hypothetical team realizes it needs to fill new roles. We're calling this series Re:Role. Remember: any resemblance to real companies is purely coincidental and unintentional. Today's episode: Technical Support. If you'd like to listen from the start of the series, check out our episode on the CTO. Producer Kim Huang is here with our story. Help desk analyst, technician, support technician, technical support specialist, whatever the name is, the primary purpose is the same. These are positions that are made to support end users when issues arise. We solve problems. We? Wait, Angela? Yes. That was my first job in tech. I was a help desk technician. That is how I got my start into tech, solving people's technical issues. Tell me more. It is the best job in the world if you're trying to get into tech, and I'll tell you why. You think about all of the calls that come into a help desk and you're triaging from people from different verticals, different countries, wherever. You are the first line of defense, you know more about every product, every team, every service, every issue. You've seen it all, you've done it all, and it really does put you ready for that next echelon where it's like, I've learned so much with all these disparate networking and printing and security and viruses, and I've learned all these things about applications. What do you do next with all of that knowledge? Whatever you want. You've learned so much. But you don't start out in that position with all that knowledge, right? No, and that's why it's so amazing because it is like the school of hard knocks. You learn so much with every call, with every end user, with every problem, every phone call is an opportunity to learn more and more and more. That's what makes it so amazing. Yes, I see the merits of going into technical support as a way to jumpstart your career in tech, but I feel like there's also, maybe from an internal standpoint, there is a little bit of, I don't want to say an image problem, but there is- It is. Yeah, there's a lot of misconceptions about technical support. Let's talk about those. Well, you're almost like the low person on the pole here. You are just the person that they call, especially if you're first line support. You have no respect because you're the person who's just basically filling out a trouble ticket. You're getting the person's name and phone number. You're asking those questions to hand it off to someone else. So you'd be surprised depending on the organization, like those folks catch heck. Oh, yes. Well, you have to remember as well not to defend any bad behavior towards technical support because no one ever deserves that. It's also, I think, key to remember that when someone is coming to technical support, they're coming to you with a problem, something they're probably frustrated with, and unfortunately, you're probably going to be that the outlet for that frustration, and unless you can get that problem solved immediately, which a lot of the times doesn't happen because solving problems can take time. It's just a recipe for someone to take some abuse. And if you're on the help desk, no one calls and says, you're doing a great job. Or how was your day? Or, oh, it's so nice to talk to you. Every interaction you have, someone has a problem. So on the lower end of the extreme, it could be quite mundane. Maybe you have a really amazing support staff and nothing bad ever happens. Then you're sitting there and you're just like... I don't want to say you're just sitting there, because obviously technical support does a lot of things. In that vein, I want to start off by defining a little more what technical support does and what are some of the scenarios or I guess situations that they can encounter without getting too in depth. To that end, I spoke with Joseph Tejal. He is a technical account manager at Red Hat based in New Zealand, and he starts out by talking about how New Zealand in particular has a culture that sets it up as a great place for support staff to work. And it's not just because the great surfing. New Zealand being a rather small country, I would say it's a good place for innovation, for testing out new things because of our population size and demographics. And there's also a lot of growing opportunities now in the New Zealand labor market, and particularly on remote tech support. Previously, we have our tech support remotely in Australia, in Brisbane, in North America, in Asia, but now we have quite a number of technical support working here in New Zealand as remotees. So first off, what is a technical account manager? I asked Joseph to define his job and the simplest terms. I'm my customer's teammates sitting inside Red Hat, so try to feature that out. Try to imagine that out. I'm your single point of contact for a Red Hat product line that I'm a TAM and I'm sitting inside Red Hat. In short, I'm going to be your advocate. I'm going to be promoting your interests within Red Hat to help resolve some of your issues, and hopefully turn that into a more proactive approach on using the product rather than firefighting later on. That's what a TAM is, a single point of contact for Red Hat products within our customers and becoming their advocates, their teammates inside our organization. So let me see if I've got this straight. I just want to make sure I understand properly. You've got technical support for people who help you with tickets and make sure that if you've got a problem, you can solve it. And then we have TAMs who are like an embedded teammate that acts as a go-between, between a company and their client. Yes, that's exactly I think what Joseph was getting at. Yes, we have TAMs in our accounts in North American public sector, and they serve a huge service to their customers. They're that person that knows their infrastructure better than even me as a solution architect, because they're always talking about what's going on, what's going on in the Red Hat portfolio. If you're having issues, if you're in the middle of planning an upgrade, if you're looking to buy more subscriptions, they're embedded into these accounts. They really do have this facilitating role. If your customer has an issue, you have them open up their support ticket. But because you are embedded with support so closely, you can watch that ticket. You can lead your customer in the right direction and on how to interact on this ticket, make sure they upload their SOS reports really quickly, make sure that they respond and stay within the SLA like you are the glue that keeps the ticket moving forward to resolution. Yes. And you're also an advocate for your customer within the organization where you actually sit. Yes, indeed. Yeah. So it sounds like because they're so close to these customers, they know how the customers have set everything up, and then they might be able to maybe skip a few of those, "Okay, well, how do you have this thing set up? What are you running exactly?" They can just give that information right away and get to that solution a little bit more quickly. Is that right? Yes, indeed. It really is an amazing role to play to be that go-between, between the customer and the company. So now that we have an idea of what a technical account manager is, another good question is "why would a customer have a need for one?" which we've already answered before, but it's a concept I want to revisit. We've talked about it before. Companies are not one size fits all, but their challenges can share some similarities. If you're talking about moving to the cloud or modernizing infrastructure or having an upgrade or doing some kind of digital transformation on your end, those are things that a tech account manager has worked with other accounts and other customers on before, and they can bring that expertise to this particular situation. Joseph has more to say, There are no two customers that are alike there. There's always going to be a different set of challenges. There might be similarities and whatnot. That's why as TAMs, we also share our experiences within one another, because some of those problems that we have on our products are kind of the same. In fact, I think for startups, trying to simplify those processes that they have as they grow makes them easily scalable moving forward. So it's going to be a more proactive approach for those startups if they start to simplify, automate things, streamline their processes early on so that when they succeed in whatever they're providing, they will have an easily scalable system that should be more proactive rather than reactive when it comes to grow, if I may say so. Customers may need that embedded person to understand their unique position, whether it's something that they're trying to do, like a market pivot, or they want to upgrade their existing IT infrastructure or something else entirely. Now, technical account managers and technical support are related, but they're different. Let's talk about the distinction between them. Well, they're very different. The support person is still responsible for the ticket and seeing it to conclusion and resolution. That is their job. There's nothing a TAM can do to resolve a ticket. That's not what their part is in this role. A TAM, however, is that go-between and a support person can't necessarily play that role because they speak to tens of people a day and hundreds of customers a week, and there's no way they can have that level of familiarity with a customer. So those roles are so very different. They serve very different purposes, but together, you think about why do we do what we do in the support realm? We're really trying to support our end users and our customers. We're trying to make sure that they stay up, they stay efficient, that their problems are solved. That's our job. That's the job of a TAM. That's the job of a support person. They just have different roles in that resolution. Understood. To your point Angela, technical account manager would serve to guide the process if there's something that needs to be resolved. And a support technician has that kind of, how do I say this? They're kind of removed a little bit from the customer themselves, and they're just focused on resolving whatever issue comes in a ticket. But a technical account manager can guide the process, like you said earlier, Johan, make it faster, maybe get past all that initial intake information that needs to come in, and maybe those two things combined, those two duties combined can give customers and give end users the results that they want faster and more efficiently. So a customer knows... They're the ones who know the most about their infrastructure. Absolutely. They are the arbiters of information and how things are set up. And then you have a TAM. They have multiple customers. A TAM is not assigned to just one account. They have multiple customers that they interface with. So they're getting these little slices of life inside of all of these different accounts. All of the products are different. The problems are different. The users are different. How they're using it is different. So they have these very unique perspectives across all of their customer accounts. So what they can do is they can bring that outside knowledge from one customer, and it could be of benefit to another. Whether you're embedded offsite with a customer or you're handling an account remotely, kind of hands off, when something breaks, tensions can be high. Joseph says, the focus for technical support staff is to identify the problem and its scope, resolve it, and take steps to circumvent the same issue happening twice. Number one, of course, we try to resolve the issues for them in the fastest way we can, not only to your own technical expertise, but within a wider group that supports you as well. The second thing you need to do to make the most of that situation is make sure it's not going to be happening again. Make sure that next time around, we have automated resolution when this trigger happens. So that's another opportunity for you to improve the lives of your customers and yourself as well. So those two things probably is one of the main better things on looking at those stressful situations as that is, and letting the business know how the impact of your job is making them better overall. Later on, you will save them time and money because it's not going to be happening again, because I took a more proactive approach on resolving this issue moving forward. We'll learn from it and next time it's not going to happen. I love the way he thinks. Especially because of what we were saying earlier, where people are only coming to you when they're frustrated, right? But if you're not busy, then you run in the danger of like, "Well, why are we hiring these people in the first place?" So I like his approach of saying that you really need to let the business know of the impact of your job, right? Because if you're automating these solutions, if you're coming up with these ways to make everyone's lives a little bit better, you got to really make sure that you're letting people know as well, right? That down the line you are... You're not just firefighting as things come up, you're also being proactive about preparing those solutions when they come up again. And when that problem solving, that behind the scenes work that you do is imperative to the company. When your company makes automation a priority, they understand that we want to see those problems go away. We want someone making sure that this situation doesn't happen again. Well, how do you do that? Well, someone has to put the processes in place to make it happen, and the higher ups need to have visibility inside of that to make sure that, yeah, stuff's getting done. We're not having the same problems that we had before. Why? Because we've automated them away. And having visibility and understanding the importance of what these folks do is so important. So for one, yes, you try to solve the problem as quickly as possible, but the next step is let's triage. Why did this happen? What can we do so this doesn't happen again? And how do we do it? So once you've gone through that and you've tested it and you've played around with it and you know it works, you put it in place, and that's just one less thing that your organization has to worry about. Now you can focus on more important things. So it gives you the opportunity to be more innovative, to be more forward-thinking, to work on the cool stuff as opposed to the firefighting stuff. So like Angela says, it's vital to create processes that can be scaled and automated. What does that mean for our startup? And more importantly, what does that mean for their prospective new hire? We're still here with Joseph Tejal, a technical account manager with a background in technical support. I was asking him deeper questions about working in tech support when he hit me with something a little unexpected. Of course, apart from the basic fundamentals of the specific products that you're going to be supporting, that you're going to be providing your customers, I think one of the key factors for a successful technical support team is their ability to innovate, to automate, and we should be getting talents, technical supports like that. I, for one, as an example. Previously, I also used to work as a technical support. I led technical support teams in the past. And this might be controversial, but in most cases, I tried to make myself dispensable from my role, from my job because for example, if I want to focus on more things or more innovations on more interesting projects, I will try to simplify some of the tasks that I regularly do so that it's either my customers can do it for themselves or my teammates, whoever is part of the team, can basically do that in a more simplified way, in an automated way, perhaps, so that I will have more time to focus on value adding services for the people that I support. So making yourself dispensable allows to work on more interesting things, and that is actually, I think heating two birds in one stone, your customers will be more satisfied because, I don't have to talk to technical supports for so long. I can do it by myself. And your teammates will be grateful to you because you've documented them well. Wow. He said all the things. He did. He's spot on. You don't want to be the hold up. If you can make it so that people can solve their own problems or there's some self-service, or it's been automated away, gone are the days when you used to sit back and it was your little fiefdom and you didn't want people messing with it, and you didn't want to document because this is your job and you don't want anyone else planning your sandbox. No, we don't do that anymore. We're open. We're documenting, we're automating, we're sharing our processes, we're being totally transparent, and we're helping our customers, which is our end users, be more self-sufficient, right? So that's what you want. That's what you want. So you don't want to be that person holding on to all the cards. You want to put the cards out on the table so everyone knows what's going on and where to go and how to do it. That's the way things are nowadays. So help me understand a little bit. How do you hold on to your job if you are automating all of the things that you do on a day-to-day basis? There is never going to be a fully automated anything. Why? Software changes. There's always updates. There's always things to document. There's something always happening that's moving your innovation, moving your infrastructure, moving your software forward. And when that comes along, then you have to get into there and try to fix and remediate and do things like that. So that doesn't exist. And what it does is, you are now a more valuable person of the team. Why? Because you can do these things that bring the team more value. So your job is even more important now because now you're not just holding things close to the vest and everything stops at you. No, you're enabling everybody else around you so they can be better. I want to bring it back to Joseph. When I asked him about the skills needed, like what technologists need if they're acting in a support capacity, he says, one of the most important skills to have is empathy. We need to understand, we need to be in their shoes for us to support them in the best way we can, because sometimes you will lose your patience on difficult times, stressful times, high pressure situations, but putting yourself in your customer shoes allows you to understand it fully and perhaps resolve their issues in a manner that you would want your issues to be resolved. And that type of empathy builds trust. By showing first the value that you can add to the team. Once you've shown the ability to help them out, you will continue to gain their trust moving forward. Because especially if you address some of their pain points, understanding their pain points and helping address those, that's one of the main ways to get their trust. And then you build off on that, and later on, they will start to be more open. Joseph says that trust can also go a long way to expand business partnerships and relationships. It could be that after those initial issues are resolved, that person on the other end of the line becomes more than just a hotline for outages and bugs. They become a subject matter expert, a trusted confidant. It creates that feeling of being embedded with that actually happening. Customers feel support personnel are invested in their success just as much as they are. You become a part of their team, and now that you're a part of their team, you learn more about their system. And now that you learn more about their system, you are helping not only the customer, but also our technical support teams, because you try to avoid the ping pong of information on logging a case, because you can immediately provide those information to our support team and vice versa, because of the knowledge of the product, you can just talk to the customer on some of the things that you already know and try to resolve the issues for them. That's a great example for someone like a support technician to follow. But ultimately, a job at a help desk can seem a little mundane at times. People call technical support when they have a problem. When things are running smoothly, it's easy for those people to fly under the radar. Some people might prefer this and some might not. So how does a person looking at a career in technical support amplify their presence and show off their full potential? Let me count the waves. When it's pretty quiet. That's where your initiative to come up with the innovations that may improve the lives of your teams internally and externally comes into play. Trying to submit a paper on a user group, on a conference out there about the innovations, the automations, the improvements that you're doing so that other people will learn from them. In short, shout out all the goodness that you are doing within your space to improve that in the middle of the silence when there's no firefighting reactive activities happening. And that's a golden opportunity for you to be proactive, innovate and tell the business people about it. So yeah, there's definitely different angles, different perspectives into looking at this. And I've learned those through the years because initially you'll get stressed out. You'll get burned out at some point, but look at the opportunities differently. Look at the situations differently and make sure you make the most out of them, because these tough situations as a technical support defines your next steps in your career. And this would be golden stories that you will tell your future employers, your future managers, and your future teams. What do you think, Angela? Nailed it. I thought so. There are so many things you can do, and because we don't do this job by ourselves, we don't learn in a vacuum. We're always out there on user groups and in blogs and asking questions, and we're out there. And when we have time to learn our craft and we become our these subject matter experts, then it is our opportunity to do for other people, that was done to us. We should be out there answering questions in user groups, and we should be out there putting out blog posts and putting out... Answering CFPs for conferences, showing how we've done the thing, and we should be sharing that information. So that's really the recipe for building a successful career. There is nothing mundane in that. This was really where you can show off, you can flex, you can let the world know. Let your internal team, let your external customers know you are providing value, not just on the other end of this email, not just on the other end of this phone. You are sharing what you know so everyone else can be better as well. So there's a lot you can do in this little role and have a lot of impact. It makes me wonder a little bit, correct me if I'm wrong, the way I imagine tech support is you get a lot of tickets the majority of the time that are more on the mundane side, things that you see over and over again. And then every now and then you get these problems that just, they're hard nut to crack. You really just need to dig in and figure out exactly what's going wrong. And it's some weird edge case that needs a little bit more research. Now, I had imagined that those are the ones where you're really learning and really pushing yourself forward and having that opportunity to advance your career. But from what it sounds like, it's more of the opposite. When you've got those mundane tasks and you're figuring out how to automate them and get rid of them more quickly, and you use that time to then innovate and make yourself more visible, that's where you have really the room to grow. Is that right? You're spot on. I mean, you think about when those edge cases come up and when you're challenged and when you're confounded and you have to figure this out because again, you're here to solve the customer's problem. That's a lot of pressure. So what you're doing is, in that exercise, in helping them figure out their problem, you are researching, you reaching out to more senior people, you're compiling information, you're testing your hypothesis, and you're growing. You're learning. You're learning what works. You're learning what doesn't work. And then when you finally get to the point where you're helping your customer along and they're fixed and they're closing their case, you can sit back and say, "Wow, that was rough." But look at all you've learned along the way. You may have never encountered such a problem, and now you have, and now you have that frame of reference, and if it ever comes up again, you know what to do. So that's where the growth happens. It can't be the same or same all the time because that does get mundane. It is these edge cases that really push you to know more and do more and be of more value to your customer. So some takeaways that Joseph left me with on how technologists can approach a career and technical support. Firstly, he says it's very easy to get stressed out at this type of job. It's very easy to get burnt out. Like I said, that emotional leakage from before when we were talking about the tensions being high, emotions being high, it's very easy to let that affect you in a negative way if you're looking to pursue this type of career. But he has a different approach or a different perspective on how to look at this type of work. You get burned out at some point, but again, look at the opportunities differently. Look at the situations differently, and make sure you make the most out of them. Because these tough situations as a technical support defines your next steps in your career. And this will be golden stories that you will tell your future employers, your future managers, and your future teams. That's how I look at it. What's up- This guy is a mind reader. Yeah. He is such a mind reader. You think about when you are ready to interview for that next job. We've all been there, and the interviewer asks you that question. What problem did you have? What hard problem did you have? And how did you solve it, right? And there's an acronym for these types of interviews. But when you have to look back over your career and find those things that help build your mettle, and these are the stories you tell your next employer, this is how I did this. This was the problem. This was how we dealt with it, and this is how it was solved. And these are these little feathers in your hat because you've done the hard things. You can answer those questions very confidently at this point. So these are the medals that you win along the way, and that you can shine in your next interview, in your next role. They're just building you up for what's next. Absolutely. For me, I came out of this episode having a whole new appreciation and respect for technical support roles because the job is tough. It can seem thankless, it's incredibly stressful, and it can be difficult for people in these roles to stand out amongst their peers. But people in these positions understand that the challenges they're facing every day, they don't exist in a vacuum. Other companies, other teams, they're all trying to figure things out along with them. So through practicing collaboration, empathy, touting one's victories and lessons learned, someone in a technical support role can demonstrate their impact in an organization and even have a little fun while doing it. I totally agree. What's next? Well, we have one final episode in Re:Role. And it's another position that may not get as much attention as it deserves. Next time we talk about the developer advocate. Whoa. I was hoping you would do this. Oh, this... This one's going to blow up. Yeah, I'm excited. I am very excited. Great. Wow, that was an amazing, amazing episode. Thank you so much to Joseph for sharing his experience with us. We want you to share the same. Tweet us at Red Hat using the hashtag Compiler podcast. We want to know, were you in tech support? How did this role help build your career? And please, if you have one, and I know you do share with me; what was your favorite, most memorable support ticket? We all have them, definitely. Hit us up. We want to hear all about it. And that does it for this episode of Compiler Re:Role. Today's episode was produced by Kim Huang, Caroline Creaghead, and me, Johan Philippine. A big, big thank you to our guest, Joseph Tejal. Victoria Lawton can make waves wherever the waters take her, even as far away as New Zealand. Our audio engineer is Christian Prohom. A special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Our audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Brent Simoneaux, Nick Burns, Aaron Williamson, Karen King, Jared Oates, Rachel Ertel, Devin Pope, Matias Faundez, Mike Compton, Ocean Matthews, and Alex Traboulsi. If you liked today's episode, please don't keep it to yourself. Share the show. Leave a review on your platform of choice. Maybe even rate us on the platform. It really helps us get the word out. Sharing is caring. Until next time, everybody. See you soon. Bye. Bye.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Blog

Friday Five — August 15, 2025 | Red Hat

15. August 2025  |  Red Hat Corporate Communications

...

Blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14. August 2025  |  Brian Stevens

...

AI inference

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.