The fastest way to learn a new industry’s support problems is to stop assuming they look like your last one’s. In December I joined Q4 Inc as Director, Client Support, and I spent the first weeks doing very little except listening: to the team, to the tickets and to the customers who write them.
Q4 builds websites and digital tools for public companies’ investor relations teams. My team of 69 front-end technical support developers, working in CSS, Java, JavaScript and HTML, supports those sites across North America, Europe and Latin America. After a year in live entertainment, the change of subject was dramatic. Instead of venues and on-sale dates, my customers were IR teams preparing for earnings releases. I wrote earlier about searching for a job when my industry had stopped. This is what happened when I found one.
What is different about supporting investor relations teams?
The clock. In most support environments, a slow response is annoying. Here, timing can be the whole point. A public company releases earnings on a scheduled date and time, and its IR team needs the website to reflect that release at that moment. Public companies are also bound by disclosure rules that exist to make sure material information reaches the market fairly and at the same time. An IR manager waiting for a developer to update a page isn’t being impatient. They’re working inside a window that can’t move.
That changes how you think about priority. In my previous role, a severity-one meant a venue couldn’t sell tickets. Here, a severity-one can be a perfectly ordinary request, such as a document upload, that happens to be due at 4:05pm on an earnings day. The request is small. The deadline is what makes it critical. A support team that only reads severity labels, and not the calendar behind them, will treat that request the same as one with a week to spare.
It also changes the cost of error. A mistake on a promotional page is embarrassing. A mistake on a page that’s carrying a company’s financial results is a different conversation, with a different set of people on the other end. Accuracy, careful handling and clear communication matter as much as speed, and for a team working in the first weeks of a new year with a backlog, the balance between those is worth getting right.
How do you learn a team’s real problems in the first 30 days?
By starting with data and conversations in parallel, and by resisting the urge to fix anything yet. I had four sources: the tickets, the people on the team, the customers and the colleagues who depend on support.
The tickets came first, because they don’t have opinions. I wanted to know what came in, how it was categorised, how long it took to get a first response and what happened afterwards. One number stood out immediately. Initial response time was averaging 17 hours. In a business where customers are managing time-sensitive earnings communications, that’s a long time to wait to hear that someone has seen your request. Customers weren’t cancelling over it, but I’d spent enough years in support to know the pattern: a slow leak of confidence that shows up in renewals long after the work itself was done well.
Then I talked to the team, individually. I asked the same short list of questions of everyone. What takes up most of your day? What do you wish was different? What do customers complain about? What would you stop doing if you could? The answers made a pattern. A lot of each day went on classifying and routing tickets, and it wasn’t yet clear to me how the team defined “good” beyond getting through the queue.
Customer conversations were the third source. I asked to sit in on calls and read escalations. What I wanted wasn’t a list of complaints. I wanted to hear how IR teams describe their own work, so I could learn the language and understand what a good outcome looks like from their side. A support director who can’t explain the customer’s business in two sentences is going to prioritise from the wrong end.
The fourth source was the colleagues around support: account managers, sales, product and engineering. They know what’s been promised, what’s been learned and where the friction is. I asked each of them what they needed from support that they weren’t getting, and what support did that annoyed them. It cost a few hours and told me more about my own team’s reputation than any survey could.
Why shouldn’t you change much in the first month?
Because you don’t know enough yet, and the team can tell. A new director who arrives with a list of changes tells the people already there that their work wasn’t understood. I’d also learned from the AudienceView transformation, which I describe in the Vendini merger case study, that the changes people accept are the ones they’ve helped shape. The honest approach is to say what you’re doing: you’re learning, you’ll share what you find, and you’ll make changes together.
There’s a distinction worth holding on to, though. Not changing the structure isn’t the same as not fixing the obvious. If a customer is about to miss a deadline because of a handoff problem, you fix it that day. What you hold back on is the redesign: the new tiers, the new tools, the new reporting. Those wait until you can explain, with evidence, why they’re needed.
I also kept a running list, in plain language, of everything I noticed: things that worked, things that surprised me and things that seemed wrong. At the end of each week I’d read it back. By week four I could see which items had come up repeatedly from different sources, and those became the starting point for a plan. The things that only I noticed turned out, mostly, to be me not yet understanding the context.
What did the first weeks tell me?
Three things, and they set the agenda for the next three years. First, demand wasn’t random. It followed the reporting calendar of public companies, in quarterly waves, and a lot of what looked like chaos was a pattern nobody had written down. That’s the subject of the next post.
Second, the team had real talent, and I needed to understand how work moved between Tier 1, Tier 2 and Tier 3 in practice, and where routing depended on individuals and not on a rule. That’s the kind of problem I’d worked on before, with a skills matrix and defined levels of the kind I described in what a help desk actually is.
Third, I wanted better measurement. Ticket counts and times told one story, but I couldn’t yet see how customers felt, or which kinds of work were hardest for the team. If I wanted to make a case for investment, I needed that data. The idea of building a proper scorecard, as I’d done earlier at Tyco and described in the support scorecard case study, went at the top of my list.
What I didn’t do in those weeks matters as much. I didn’t announce a vision, I didn’t promise customers a number and I didn’t reorganise the team. I wrote down what I’d heard, I told the team I’d bring it back to them, and I started building a picture of a three-to-five-year plan, which I’ll describe in a later post.
If you’re starting in a new industry, resist the instinct to prove yourself quickly. The people you’re managing have seen directors arrive with answers before. What they haven’t often seen is a director who asks good questions and then does what was promised.
One habit from those weeks is worth passing on. At the end of every conversation I asked the same final question: what should I have asked you that I didn’t? It felt slightly awkward the first few times. It produced some of the most useful answers, because people tend to hold back the thing they’re most worried about until they’re invited to say it. Ask it of the team, of customers and of the colleagues around you.
Write down what you hear in the words people use. When a customer says a request is ‘stuck’, or a developer says a ticket is ‘a mess’, those words tell you how they see the problem. Later, when you propose changes, using their language makes the plan feel like theirs and not like something imposed.
You can’t lead a support team through a problem you don’t yet understand. You can find out what the problem is faster than they expect.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
