From team lead to head of support

Idit Matas As head of support you're now at a director level. You are expected to drive a strategic project, something that will leave a lasting impact. So you really have to zoom out from the day-to-day, from the tactical, and think strategically — otherwise you're not fully fulfilling your responsibilities.

Jen Weaver Welcome back to Live Chat with Jen Weaver.

Moving from team lead to head of support isn't just a title change. It's a shift from managing tasks to driving strategy across the business. And today's guest knows exactly how to make that leap.

Idit Matas was most recently the global director of technical support at Firebolt, where she led teams across EMEA and the US, rolled out a 24/7 on-call program, and helped shape the 2.0 product release by piping real customer feedback straight into engineering and product. She also led AI initiatives, including a GenAI documentation project that cut time by 67% — all while keeping CSAT at a rock solid 97%.

Before that she spent over three years at Datadog, climbing from team lead to senior manager and overseeing a 30-person team across five leads.

In this episode Idit breaks down what it really takes to move from tactical to strategic, how to scale global support without burning out your team, how to build escalation workflows your engineers will thank you for, and how to lead projects that actually move the needle for your company and your career.

As always, keep in mind this podcast is made possible by supportman.io, making actionable QA land directly in Slack from Intercom just for you. All right, let's get into it.

Idit, it's wonderful to have you here. I would love to hear first — your topic is, if you've been a support team lead in the past and then suddenly you are head of support, what do you even do at that point? You've done this before, so I would love to hear what's been your experience with that.

Idit For sure. And hopefully it's not suddenly you've become head of support.

Jen Hopefully it's something you've been working toward.

Idit Exactly, you were pursuing it and you really wanted to get this opportunity.

There are a few things to keep in mind when you're promoted to head of, and not a team lead. You see a different perspective and you are responsible for the entire operation.

The first place to start is really make sure you have global coverage. And it doesn't have to be 24/7, or 24/7/365. That really depends on where your customers are located, especially your strategic customers — maybe a strategic POC that you're trying to land — and also depending on your contractual SLAs.

So even if you have a customer in APAC, if you're not contractually obligated to have first response within an hour, you don't necessarily need someone located in that area. You need to examine where are your customers located, what is the SLA you have committed to, and then do you have the right people in those locations.

Jen Is it common, moving into a head of support role, for that to be a new consideration? I'm imagining sometimes people might move into a head of support role and global support is already established, and they might need to reassess it. What's your experience with that?

Idit When you're entering a new role, whether you're establishing a whole new team or an existing fully operational team, you have to re-examine things and make sure things are operating smoothly — because from this point on it is your responsibility.

If something goes wrong, if a customer complains on an SLA breach, it's on you now. So even if you do have a fully operational team, I think that's the first place to start and evaluate.

Jen So your first move would be to figure out really what is needed and how it's been going so far. Are there data points that you would recommend looking at for that?

Idit For sure. So time to first response — that's the first metric to look at, and one of the basic metrics of support. See if it fluctuates throughout the day. Are there times in the day where time to first response is longer than other times of the day?

Another metric is look at when a ticket is opened, what time of the day, and that would tell you where your customers are located. It doesn't really matter where physically they're located — what's important is which time zone they are in, or which time zone they're working in, which doesn't always correlate. So you need to make sure you have people on shift and covering while the tickets are being opened.

Jen As you're considering time zones, do you have any hacks for figuring out where to hire from, which countries to hire from?

Idit Yes. So a great hack is to hire in Israel. Now, I might be biased here because I'm originally from Israel — but not all people know that in Israel the work week is Sunday through Thursday. So you get a weekend day, which is Sunday in the rest of the world, with someone working just their normal work week.

So yes, that is a great hack. They cover EMEA time zone Monday through Thursday, and they also cover Sundays, and you get that out of the box.

We had one person working out of EMEA, and unfortunately that person left the company. And as head of global support I realized, oh my god, I do not have coverage for Fridays. And I had to ask an individual from the team in Israel to shift their work week Monday through Friday.

So sometimes you need to adjust. We had to do it the other way around, asking someone in Israel to work Fridays — whereas in the rest of the world it seems obvious, working Fridays.

Jen So would you say if you try to shoehorn people into a schedule that's not typical, they'll tend to churn as employees?

Idit Exactly. You don't get good retention rate. They will churn eventually, and I don't think it's sustainable. People want to have their weekend, or have their leisure time, just like everyone else.

Jen With their family. When my partner is off work, I want to be off work. When my kids are not in school, I want to be available.

That makes total sense. But that does present the problem of, as a head of support, how do you cover those SLAs? How do you cover evenings, weekends?

Idit The way I covered those hours is through an on-call mechanism. You can even have every time a new case comes in, the on-call gets paged, if you want to be very strict about it.

What we did is only if a customer opens a case in priority high or highest, then the on-call support engineer gets paged. Additionally, we defined that if you are on call, for the time that you are on call you should check for any incoming tickets once every four hours, starting 9:00 a.m. till 9:00 p.m. in your time zone.

So that's the hack we did. Just make sure you're covered using on-call, and a good on-call system, like PagerDuty or Opsgenie.

Jen So an ideal structure is have those priority customer emails ping the on-call specialist, and then the expectation is that every four hours they'll go in and look for new non-priority emails. Did I get that right?

Idit Yes, exactly. Because sometimes a customer won't know that they have to mark their case as high or highest in order for the request to be handled during off-work hours. Maybe they're unaware that it's off working hours for us.

Jen They might not know, and they don't need to know your staffing hours. They just have their question and want their needs met.

And that's one of the things about moving from a support team lead to head of that sometimes we don't talk about — the expectation of always being on call. The buck stops with you, and it's a bit of a different way to be. Can you speak to that?

Idit Yes, totally. It's very much the unspoken responsibility of always being on call when you're running a global team, especially a support team, when things are time-sensitive.

I constantly check my phone and my Slack. It's great having Slack on your phone — you don't have to be in front of your computer the whole time, you can get everything delivered to you.

I've heard from my team and my co-workers that it seemed like I was always on. I did my best to be available. But I definitely had my time — I'm taking some downtime for family time during the afternoon or evening whenever I need to. And I definitely sleep, like anyone else.

Jen Back to global support. With on-call and trying to cover many time zones, it makes workforce management a little challenging. How do you figure out your headcount when it's so variable?

Idit Like we said, you need to identify the time zones where you need a person to cover a shift. Then you need to consider, is one person enough for that shift?

Jen One person on call, or one person online handling whatever comes in — and that would be for a very small team.

Idit Yes, a very small team, which is how you start off, especially when we're talking about global support.

So you start with — okay, let's say your business is mostly in North America, so you'll have a team in North America, but then you want to expand to APAC. So you start with just one person.

Jen As you're growing global support, you're starting with just one person in that area. Does that present challenges for managing that person? They're not going to have as much overlap with the rest of the team and may feel isolated.

Idit For sure, and you're bringing up such great points. A global team also means a distributed team. It's not just the coverage for the customers, but how that person feels as part of the team, part of the company, knowledge transfer to that person.

If you have a global team that's really covering across the globe, you can't find a single time that works for everyone for a weekly team meeting, for example. It's just not feasible. So you really have to be mindful if someone is running the one-man show for their region — making sure the knowledge is transferred, and that they feel included and feel part of the greater purpose of the team.

One more hack for global coverage: consider using AI, because AI is always on. They never sleep. So if your first responder is an AI bot, you don't have to have a person located in that specific time zone. Your first response SLA is covered.

Jen So when you're using AI as a first responder and you have an SLA that someone in APAC will get a reply within an hour — they might get an AI reply, but won't be able to escalate to a human, like so many people like to do. How do you handle those expectations?

Idit I would then again use the on-call mechanism. So your first responder will be the AI, and if they insist on reaching an agent, then you use the pager on-call mechanism and you reach a human agent.

Jen Next, I know you mentioned to me that it's really important to handle escalations to engineering and product. As you're growing into a head of role, this becomes your responsibility — may not have been when you're a team lead. What's different about escalations at that level?

Idit Now you're head of, you're working cross-functionally, cross-departments. It is your responsibility to make sure everything is running smoothly.

As a team lead you were running just your team, you were focusing on your department. As head of, you need to look at the company level and make sure all the pieces work well in order to provide the best customer experience.

When a user opens a ticket to the support team, often it does not end with the support team. Often it is not in the support team's capabilities to resolve 100% of the issues, and the issues that are not resolved within the support team get escalated either to software engineering, R&D, or to the product team if it's a feature request.

So you have to make sure you have a smooth process to hand over issues from support to the higher tier of escalation, whoever that may be.

Jen What's one piece of advice you'd give a new head of support to making that escalation process smooth?

Idit If you're just entering the role, I will definitely say meet with the relevant stakeholders and ask, how are things being done today? What's working well and what could be improved? What are your pain points?

If you go to the head of R&D and ask those questions, you get their buy-in. You get their empathy of, oh, this person really wants to solve my pain points. They want to help, they want to make sure we work well together.

So I think it's really important to do this listening tour, and present yourself not as someone who knows how to run the business and already has these predefined notions, but really wants to learn this organization and this specific team, and how they should operate together.

Jen That term you used, a listening tour — that's just gold. I love that. It gives me this image of going around and meeting with teams and just listening to what works for them, what their pain points are, and gathering that information so you can build trust with them.

Idit Yes. As head of, you always need to build trust with your direct reports, but also with your co-workers, the heads of the other departments, because you will work cross-functionally with them.

Jen What are some processes that you've used to make sure that the escalation process is clean? By that I mean that only the information that engineering and product need goes to them, and that it's easy for support to get that all in one place.

Idit It's important to establish with the engineering team what is the information that they need.

Jen And that's part of that listening tour.

Idit Yes, you obtain that information initially in the listening tour, but you can always iterate and add on that.

You need to understand what are the details that are needed in each bug that support escalates to engineering, and it's depending on your product. It could be, how many cores were used in that specific machine or server? Which cloud provider was it running on? Probably need to link to your application logs. Maybe you have some observability tool that you're using, so you minimize that to the specific time frame that's in question.

You need to make sure that you package all that information for the engineering team, so they don't waste time on any further back and forth with the support team. Sometimes, like we do with customers, engineering can then do with the support team, and it just adds more time to the process until the issue is resolved.

It would also cause frustration from the engineering team — like, I got this issue, what am I supposed to do with it now? I don't have enough information.

And if you're working together in the same organization, you need to make sure you're working together for the same goal, which is resolving the customer issue. So support should package it in the best way possible for engineering to immediately be able to start work on it.

Jen Part of that is prioritizing, so engineering and product really understand whether this is on fire or whether it can wait a little.

Idit So another thing I've done at Firebolt, the recent company I worked at — we redefined the bug's priority along with engineering. We presented it to engineering and then got their final approval on that.

So we decided to go with four levels of priority: highest, high, medium, low. And we established what the definitions are for each of those. The two main criteria were whether this is blocking to the customer, and whether there is a workaround, yes or no. Is that workaround sufficient? Is that workaround sustainable? How much work does it require from the customer to implement that workaround, and so forth.

That's how we differentiated between the four levels. And then we decided along with engineering, okay, engineering are only going to handle the bugs that are high and highest.

Now obviously that's not something you tell your customers — like, engineering are only handling high or highest — because then every customer would scream off the top of their lungs, yes, this is highest priority. But it's internal SLAs.

So engineering would only address high and highest bugs. Medium and low they can, if they have the resources, if they happen to be working on an adjacent feature and you can bundle that bug in there and fix that, then might as well. But we did not expect engineering to handle medium and low bugs.

And then for those medium and low bugs, or the associated cases with those bugs, we would go back to the customer and tell them: I've escalated this issue to our engineering team, but we don't have a definitive ETA at this time, and therefore I'm going to close this case.

Now if the customer would come back to us and say, "What do you mean? I'm expecting a resolution, I can't keep doing this workaround that you suggested" — then we are now able to go back to the engineering team and tell them, you know what, that bug that we thought was medium priority, it's actually high, because of this further input that we just received from the customer.

That really helps to close the entire feedback loop and set the proper expectations with the customer.

Jen That's really useful, to be able to define the priorities and then have a flow for what needs to happen. It just makes it super clear.

Is there anything else about escalations that you feel is crucial for a new head of support to know? And do you have any wins from those projects you'd like to share?

Idit Redefining the escalations, and redefining that engineering would only handle high and highest — that made the interaction much more comfortable, I will say, because we each knew the expectations.

So support would not get frustrated with engineering of like, hey, why aren't you handling these bugs, there's this huge backlog that you're simply ignoring. It was fine, that's what we agreed upon. Only high and highest will be addressed.

And then from the other end, we were able to close those tickets because we set the proper expectations with the customers, and then we were able to reduce the time to resolution of the entire support team.

Prior to that we would keep the ticket as "pending bug" or some status of some sort, but the time to resolution would keep ticking. It would still be counted, because the ticket isn't fully resolved. By setting that mechanism and those expectations, we were able to reduce time to resolution overall by 20%.

Jen That's fantastic.

Idit So it also helped the support metrics.

Jen That's a huge win. I know you have a fantastic template for feature requests — for the information that specialists need to gather to pass those along to the product team. Can you talk a little bit about that? How you developed it, what the elements of it are?

Idit That was actually from my time back at Datadog, where they have a huge customer base and the product is so vast that a customer can just ask for whatever. It's really not tied to just logs or just monitoring or just a specific cloud provider — they cover it all.

We did get a lot of those feature requests coming in from customers. And a support engineer, when they get a customer inquiry, they might immediately go to, how do I solve this? How do I fix this? They suggest a workaround.

So if they end up getting to the conclusion of, okay, this specific request is just not supported in our system, we don't have this feature, let me suggest a workaround for you — which is great, that's exactly what support engineers should do — but then the next step is to package that information for the product team. That's the feature request, that's the other path of escalation.

And what information to gather there is not as straightforward as the information we're gathering for engineers. Because for engineers we're just providing those technical details — logs, observability tools, and so forth. For product, they want a user story. And for the common support engineer, if you tell them create a user story, they're not really sure what that entails.

So we really had to lay it out for them and be very prescriptive on what to ask. The question was: a user is trying to achieve X, the user does this action, then the user does the following action, but the user is blocked when they're trying to do this action.

So just be very detailed on all the steps along the user journey, and when they are blocked. What are they trying to achieve? How did they achieve it up until now? Probably they use this different platform, this different tool, but now they want to use Datadog for this. So what was that other tool that they were using? How were they performing that? Is there a workaround that the support engineer already suggested? And if so, is that workaround good enough? If not, then why?

There are all these questions that are not native to how a support engineer thinks. This is much more of a product manager mindset, and therefore we had to be very specific with what questions you need to ask.

And then lastly there's the business aspect of it — what is the MRR, or what is the expected revenue that we think we can gain if we develop this feature for this customer? Which is a very non-trivial question for a support engineer.

Jen But it's important. It drives the business. And if there's something that the customer is not able to do that would drive more revenue — they're not able to upgrade their subscription or something — those should be five-alarm fires.

Idit Exactly.

Jen There have been many times I've used a tool and I've thought, I'm trying to give you money. I like your product, but it's just not working. And that needs to be fixed.

I think this template is fantastic. I'd actually like to share it in the show notes so other people can use it.

The "what is the customer trying to achieve" piece is crucial, because a lot of times support engineers will send over "oh, the customer wants this button here," or "they want to move this thing" — but that's not really the need that they have, that's just how they're trying to meet that need. And support engineers really I think maybe are the best people in the company to dig into that, because they get what the customer is trying to achieve. They see it hundreds of times a week.

Is there anything else about that you want to share before we move on to your next step?

Idit Another crucial step is, when do you need to loop in an account manager? It could be someone from the account team, it could be customer success, technical account manager, solution architect — maybe the product manager themselves want to get involved and hop on a call with the customer.

Jen How do you help a support engineer know when to ping that person?

Idit You also need to have a very clear set of questions in order to determine that. I think you can start with, what tier is this account on? If you have business tiers for your accounts, like premium, gold, silver.

Is this blocking a deal? Maybe it's a new prospect that you're trying to sign, or an existing customer that is trying to expand to another org within their business. That would block bringing in more revenue.

So when it comes to those business questions, if the answer on one of them is yes, then you need to bring in an account specialist.

Jen And these kinds of revenue and business goal questions are things that you need to think of as the head of support, that maybe as a team lead didn't really land on your desk.

Idit I totally agree. You have to think much more on the business level.

Jen I'm curious about how that's gone for you, making that mental shift from "I'm managing individual contributors" to "I'm managing the business interests."

Idit I think what helped me the most was again seeing what the other departments are doing. More specifically customer success, technical account managers — being closer to those teams. Or maybe what I mean is just look outside of your immediate team. Not just be the technical solving problems day in day out, but see what the other teams are dealing with.

Jen Part of that listening tour is understanding the needs of other teams, but part of it is helping yourself make that shift to thinking about the whole business. That's very interesting.

Idit One really last important thing I want to mention about the feature requests. As head of, an important position that you have is being the voice of the customer and providing that feedback loop to product.

This is probably not something you would do as a team lead, but as the head of — now we're talking not very tactically, like "create this process and a set of questions," but try and influence the roadmap. Because you as the head of support, you see all the incoming requests from customers, and you can see themes, and you can communicate those to the product team, along with which accounts were asking for those, what are the MRRs of those accounts. Just really have a more holistic view than a specific ticket, or even a team lead's view of all their team's tickets.

Jen That makes total sense. And that kind of thing would be your step three — about having a project, doing something outside of just what you would have done as a team lead.

You have steps for how to identify and implement a project that will leave an impact. So first, you're a head of support, you're looking to lead a project that will leave an impact. What are the steps there?

Idit As head of support you're now at a director level. You are expected to drive a strategic project, something that will leave a lasting impact. So you really have to zoom out from the day-to-day, from the tactical, and think strategically — otherwise you're not fully fulfilling your responsibilities.

The way to approach this is, okay, I want to make an impact. You have to first identify a problem, a pain point. And that could also tie in to the listening tour. It doesn't have to be a problem of the support team — it could be a problem with some interface with customer success, with the engineering team, with the sales team.

That brings me to my second point: tie that project to a business goal. Make sure it's measurable, and if it can impact the revenue, that's your best option. So anything that would help drive more revenue, increase customer retention, bring in more deals — in whatever way that you can influence the revenue business metric, that's where you will find the greater success.

Jen I can see that being a little dangerous in terms of stepping on people's toes. How do you identify something that touches on another department that support can move the needle on?

Idit There are a lot of interfaces with other departments. One that I can think of is about the documentation.

A SaaS product has its own public documentation that is very elaborate, and usually technical writers would write it. But a lot of very technical products would have their own support knowledge base articles which are customer-facing — not internal knowledge base. It could be a how-to guide, or troubleshooting guides, things that support would see on a daily basis and that can easily be resolved by the customer. So that increases the self-service of the product.

Going back to your question — if support has this other resource of a support knowledge base, it doesn't take anything away from the public documentation from the technical writers. It only supplements or augments that, because it identifies a different need of your users. It's not a user that is just being onboarded or is evaluating the product. It's a user that's already using it, maybe they're an expert on the product already, but they now just hit this little snag that they want to unblock themselves.

That could be a great project. It could go a long way with the product team. It could be, instead of implementing this new feature that customers keep asking for — wait, I have this stop-gap for now, I'm publishing this article and customers can resolve this on their own. So product and engineering don't need to invest all those time resources in developing or enhancing the feature, because support were able to unblock them.

Jen So that's a way that you can affect other teams without stepping on their toes, by taking work off of their plate.

What are some other examples of great projects that you could do as a new head of support that would leave a huge impact?

Idit Usually there's a need for this when the business grows significantly: creating support packages, creating tiers for your support offering.

So there's the free tier — maybe your product even serves free trials, so you don't really want to have a committed SLA to those. And then you have your medium-sized businesses. And then you have your enterprise. But then you have your top 10% customers that you really want to offer premier support for.

Creating those packages is a strategic move that will have a long-lasting impact and will drive revenue to the company. So like I said, tying it back to revenue.

Jen So it sounds like the recipe is finding a problem or a pain point, tying it to revenue and a business goal, and then pitching that. Do you have any stories about how to pitch a project that you want to do?

Idit Another example that I wanted to point out, which is something that I have personally tried to implement, was using AI in order to get the support tickets accessible across the entire organization.

Jen Oh, interesting.

Idit Support tickets are a direct interaction with our users.

Jen And the best source of information.

Idit Exactly, it's a gold mine. If you take all that text, which no one wants to read — the entire correspondence on all of your support tickets — you take all that text and you put it into an AI model, you can then ask the AI anything you want.

Product could use it and ask, what is the number one feature that customers are asking for? Technical writers can use it and ask, what is the number one article that support are sharing with our users? Engineering can ask about a specific feature that was released — what are the bug trends around that feature?

So if you ship all that information into an AI — and obviously you need to anonymize, remove all the PII so customer details won't be identified — you can really get a lot of insights there.

Jen That makes total sense. Is there anything else that you feel like you would have done differently with your first move from team lead to head of support?

Idit I feel everything I just shared is learned from experience.

Making sure you have global coverage — for example, if you have just one person covering Fridays, you better make sure that person sticks around. You better make sure they're happy and they don't churn, because you really need them for those Friday mornings.

If you identify friction between engineering and support, then you better look into what is causing those pain points, and define processes that are agreed upon from both sides.

Jen If you've seen friction between support and engineering, do you have like a 30-second mini masterclass on how to fix that?

Idit I would say friction between support and engineering is inherent.

Support sees all the problems. Their interactions are users reaching out saying something's not working, something's broken. And then we turn that frustration to engineering — why did you break this? Why didn't you QA this feature before you released it to production?

Then from the other side of things, engineering are frustrated with the support team of, why can't you handle this yourself? Why do you need to escalate to us? You're not knowledgeable enough, you're not technical enough.

So I think there's an inherent friction, and the way to solve this is to lead with empathy. That would always work in every situation. Try to understand where the other person is coming from.

Engineering, they have their own schedule, they have their own priorities, they need to ship features to production as quickly as possible. And on the other hand, support are not as knowledgeable as engineering — they did not write that feature themselves, they were not part of the design doc, and they handle every single aspect in the platform, as opposed to an engineer that is very specialized.

So understanding where the person from the other side is coming from, and that at the end of the day they're trying to do their best.

Jen That's just the best advice. And I think that's where a head of support can really have a huge impact on the experience and the flavor of the team.

Just one final question, because I know we're at time. If somebody is stepping into a new head of support role, what project do you think is the most important to tackle first?

Idit I would definitely go with AI. So don't just implement AI for the sake of implementing AI — find the pain point and solve it using AI. Because AI is overtaking the world right now, and you want to make sure you're part of the revolution and not lingering behind.

Jen I'm a late adopter, but I've been getting into AI more and more because of my podcast guests encouraging me to do that.

I'm so grateful for you being here. I feel like each one of these three steps could have been a whole podcast episode on its own, so this is just packed full of information. If anybody would like to get in touch with you, how would you like to connect?

Idit I'm always checking my LinkedIn. I'm also a mentor on a platform called CX Mentor — you can also find that on my LinkedIn profile. So either way works for me.

Jen Cool, I'll link those in the show notes. It's just been lovely to see you today, thanks so much.

Idit Thank you so much for having me, this was a pleasure.

Jen All right, thanks for joining. I'm sure you haven't forgotten that this podcast is sponsored by Supportman, which connects Intercom to Slack and uses AI to give agents and managers feedback and surface problems in real time.

So let's say you have moved into a head of support role. What are your first three hurdles? Let's dig into Idit's plan.

One: master that global coverage without burning out your team. Her tips and tricks, especially about Israel — I had never heard of using a Sunday to Thursday work week.

Step two: building escalation playbooks. You want those to work for engineering and product as well as for the support team, and usually there is a lot that you can clean up there.

Third: spearheading a project that moves the business. Idit gave us a lot of ideas for what to do there. And of course, these also move your career forward as you prove your value to the team.

As always, it's been a joy creating this episode for you. I'll see you next time.