You’re Gonna Need a Bigger Boat featuring Charlotte Ward

Transcript

Rob Dwyer (00:03.231)
Hey everyone, thanks for joining. Charlotte Ward, you are next in queue today. How are you?

Charlotte Ward (00:11.47)
I'm great thank you it's very hot it's very hot here it's it's early August it's just hot that's all it is Rob it's just hot I'm otherwise I'm good I'm melting but good

Rob Dwyer (00:24.883)
Yeah, it's hot here as well and we are an ocean and half a continent apart and yet I feel like we're probably experiencing very similar weather patterns right now

Charlotte Ward (00:39.822)
Yeah, it's been very hot outside, but you know, being in Britain, we love to just create situations that allow us to moan about the weather. So we don't believe in air conditioning or any of that. So the temperature in the house is basically equal to the temperature, sometimes warmer than out at the house in this weather. hot.

Rob Dwyer (00:52.582)
Ha ha!

Rob Dwyer (00:59.997)
Yeah, I don't think I could handle that, but I'm glad that you and your countrymen have that stiff upper lip and go ahead and take one for the team. I guess I'm not really sure if that applies or

Charlotte Ward (01:18.38)
I'll lay claim to the stiff upper lip, but not necessarily taking one for the team. I just feel like that's a position I don't want to put my nation in.

Rob Dwyer (01:30.578)
Okay, okay, fair enough. Before we dive in and talk about scaling teams. Let's talk a little bit about your history and where you're coming from to give us a little bit of context. And then I want to talk a little bit about Snowplow and what they do to give us even more context. And then we can actually have a conversation that we're meaning

So let's start with you, Charlotte. Tell us all the details, but the Cliff's Notes version.

Charlotte Ward (04:35.912)
Okay, all right. I'll be as brief as I can for my, you know, without, while doing due diligence on my long and illustrious career in technical support, which has been a very long one. I started in the mid 90s, I stepped out of university into a technical support role at Oracle and went through a series of technology companies after that doing different, always deeply technical support for

deeply technical products, enterprise integration management, CRMs, e -commerce, back in the day database stuff, and including, you know, short little stints at startups, longer like 12 year stints at companies that I went through like five acquisitions and five company names with. And...

a little bit of freelancing more recently, just prior to Snowplow and I've been at Snowplow for four and a half years. So I've been leading fully remote technical support teams this year, in fact almost to the month for 20 years. I haven't been full time in an office in 20 years and I've been leading technical support teams for slightly longer and I've been at Snowplow for four and a half of those.

Rob Dwyer (06:01.213)
Yeah, that's awesome. So did you go to school thinking, want to be in technical support?

Charlotte Ward (06:10.894)
I don't know that I went to school thinking that but and by school I would say university that's what you mean right you mean that kind of yeah good there's gonna be some translation here I think the so no I didn't

Rob Dwyer (06:21.193)
Mm -hmm, mm -hmm, mm -hmm.

Charlotte Ward (06:31.69)
I figured quite quickly that what I was interested in was not being a software engineer. Even though I wanted a technical role. I don't think that I knew technical support existed, really. Not as a career. I mean, I there were people out there doing these kind of jobs. But what do really know when you walk into

school or college or university at 18 and you know you start studying some things that are vaguely related hopefully to what you eventually want to do but I got bored quite quickly of sitting and doing really long form projects and that was the point where I thought yeah I love what I'm doing but I don't love what I'm doing and the course that I did was what

Rob Dwyer (07:22.51)
Mm -hmm.

Charlotte Ward (07:26.958)
called back in the day a sandwich course. I don't know if they really exist in the US, but it's a very British name, isn't it? So we had two years of study, a year placement out in industry and then come back for a final year. And it was in that placement year that I went on site at Exxon, the oil company there, one of their laboratory centers here in the UK. And I did on site technical support. And it was then that I knew that that was what I wanted to do.

And so I came out of that, going back, doing my final year at uni, I came out really just looking, like, rabidly looking for any role that replicated what I'd done for that year. And I landed Oracle, one of the graduate intake at Oracle. I got in completely under the wire, like three weeks before the programme started. I'd clearly not been paying attention. I figured the way that you got a job back then was to go through the yellow pages.

do you have yellow page? I wrote, I wrote, well I typed but I wrote individual letters and put them in the post to every technology company in the area. I was lucky, I am lucky enough to live in a in what at least back then was considered kind of the Silicon Valley of the UK and there are lots of technology companies relatively close and I started with the closest and worked out and I landed a job at Oracle three miles up the road.

Rob Dwyer (08:55.987)
That's awesome. The yellow pages do still exist, although in a significantly different form for the most part these days.

Charlotte Ward (09:03.49)
different format. Yes, I think the pages has been dropped at least, right?

Rob Dwyer (09:09.533)
I mean, they are now web pages, right? They're virtual pages. I think they go by YP maybe these days. I believe that's the case.

Charlotte Ward (09:14.936)
I suppose. Yeah, yeah, yeah, yeah, yeah, that sounds about

Rob Dwyer (09:24.607)
So let's dig into Snowplow and kind of where you are today from a support operations size, just to give us a little bit of an idea of kind of where we're coming from. How many people do you have supporting your customer base

Charlotte Ward (09:47.822)
12 right now across two geographically split teams covering 24 by 7 though so I have an Emir APAC team and an Americas team.

Rob Dwyer (09:59.939)
And you're getting ready to scale that. And we've talked on this show about scaling really from scratch, right? Maybe you've got one person and you're starting to grow that team and grow it organically, but you've got an existing team in place, but we're

Rob Dwyer (10:22.369)
You have a highly technical customer base. And I'm wondering how that impacts the type of people that you bring on into support. I think most people in support are relatively technical. But I don't know that your customer base is representative of most SaaS technical support customer bases.

Charlotte Ward (11:17.326)
I think that's a fair representation of the customer base. We are serving engineers at the end of the day, software engineers, data engineers, infrastructure engineers. A real mix is a really complex product. It touches a lot of technologies. It's bring your own cloud as a platform. It just adds like each of these things

layers of complexity to the way that you might deliver support because of the range and expertise of your customers. So scaling that is not straightforward and it's not straightforward because we are doing in -depth work. I mean, I wouldn't say

I wouldn't say it's white glove because it's not intentionally high touch, is where I would really put white glove experiences. But it's complex. It's complex. it's absolutely not a typical SaaS environment. The unit metrics are not the same, the types of problems, the way we build relationships with our customers, and the

Rob Dwyer (12:28.221)
Mm -hmm.

Charlotte Ward (12:45.792)
operational and technical challenges in delivering that support are pretty deep and almost bottomless it seems some days.

Rob Dwyer (12:56.413)
So how do you go about vetting for potential new hires? How do you find the kind of talent that you're looking for? I imagine that's one of the first challenges.

Charlotte Ward (13:12.588)
Yeah, I guess to set the landscape first is important because I think that when most people think about delivering really technical support, most people assume you're putting some sort of levelling or tearing in place in the way you deliver that. So you'll have a front line and then you'll have an L2 and an L3 even.

I've railed against that model since the days of Oracle. Oracle had a two -tier support model when I joined. it was, it always felt

Hmm. It was easy to get stuck on the front line. You know, the growth opportunities are, they're not, they're certainly not impossible, but I think it's, there's a barrier there and it's a barrier of expertise. It's a barrier of the mechanics of the way the teams have to grow. And you, you know, you have to wait for opportunities to come in the L2 environment before you can step.

cross, et cetera, et cetera. And I had been at Oracle less than a year before they switched to a single level support model. And everybody did everything. And for me, that really set my view that it was just, it created so much more opportunity for learning stuff as someone on the front line who was relatively inexperienced in those days.

to also like in the opposite direction, the more experienced people in the team spending time, you know, understanding the simpler questions on the frontline, how we can take those out of the queue, we can, know, spending time with customers is important to improve things for customers. And I think in a two -tier support model, frankly, the further back you go, the less time you spend with customers in my experience. And I really, really loved.

Rob Dwyer (15:22.749)
Mm -mm.

Charlotte Ward (15:26.315)
working inside and delivering support in that single level model. Because of the level of exposure, it gave everyone to everything. I've, wherever I've built support ever since or had any input, I've always advocated for a single level support model. So that's what we do at Snowplow. We don't have a frontline and an L2. Everyone in support is doing the same job essentially.

So in that landscape.

The type of people we hire aren't being hired to do a super tightly defined role. They're not there to be the expert or to be the front line person, you know, kind of taking those calls and then passing them back once they get beyond a certain level of complexity. It means that I can hire quite flexibly as well, which...

allows me to balance the team with every hire, balance and rebalance. know, if somebody moves internally at Snowplow, out of my team, for instance, I can hire what I need to fill that gap. I can, you know, everyone's learning all the time. So naturally your team kind of gains the experience too. So you can constantly look at the balance. People leave for all sorts of different reasons or

you know, level up over the years. So in a single level support model, it's just much more fluid. And it actually really allows me kind of to be quite creative about how I hire and the type of person I'm hiring. So there is no single answer to kind of how do you scale support through hiring in that environment, because almost every hire or hiring round is about the team that you're hiring into as much as it is the people that you're hiring. That was a really long answer.

Rob Dwyer (17:24.807)
Yeah. No, I love it. I actually have a question about retention in what you've experienced in tiered models versus the single level model. And my question is, is retention different at all? And what does the internal movement look like? are you potentially maybe having

Charlotte Ward (17:26.803)
Oops.

Rob Dwyer (17:53.533)
the same retention challenges, because people are moving internally, is it just reducing retention overall? What have you

Charlotte Ward (18:05.334)
think that when you're in a multi -tiered model,

move because they're bored in my experience more than anything else. know, aside from riffs or, you know, performance exits, I think people get to the edges of their role and it's difficult to know what you do with that. And I will say, you know, my experience has been not in highly fluid support teams, you know, when you get into this deeply technical support that I've been doing

for centuries, is frankly, certainly this century and last century, that when you get into those kind of really technical roles, particularly in smaller teams, opportunities are harder to come by within the team.

Rob Dwyer (18:47.048)
Ha ha ha ha!

Charlotte Ward (19:12.534)
And so, and particularly in a tiered model, because you get to the edges of your role pretty quickly. If all you're doing is taking the simple calls, and by simple, I'll put little bunny air quotes around the word simple, that you have to wait. You have to wait for the opportunity to come if you want to stay in support. And it just comes around less because there's less turnover, there's less fluidity.

And I, least again, at least in my kind of environment, I think different support environments I've seen, you know, you get you into this kind of great pattern of like being a farm team for the rest of the business. And there's a natural flow from L1 to L2 and then off they go to products or to customer success or whatever. But that's much less the case, I think, in deeply technical support and certainly in the tiered model.

In the single level models that I've worked inside, because of what I talked about before, the breadth that you can bring to any individual's working day through solving the hairy and scary issues to taking a few easy tickets, talking to customers on the phone or on chat or something, then I think that it's that variety.

that gives support engineers, technical support folk.

I guess it's kind of a perspective that there are lots of different ways they could

Charlotte Ward (20:57.004)
And so I see retention is generally really good in those kinds of environments because it's a varied day, because it's challenging and you also get a bit of sort of downtime or at least different time, know, changes as good as a rest really. You know, you get to do something else without leaving the environment that you're, you know, able to contribute a lot to because you can...

you you stay. And I think just in any environment where you're building that kind of exposure, it has, it provides other opportunities across the business in a different way, though, I think you kind of get there slower. You get there more slowly because, because expertise is not the only thing that you're building in

Rob Dwyer (21:55.851)
It strikes me that in that environment, you get maybe more breadth, and it takes more time to get the depth. But that exposure can be really important, because it does lead you to understand what you may be interested in that you didn't realize was a potential option for you.

Charlotte Ward (22:07.982)
I would agree.

Charlotte Ward (22:21.867)
Absolutely, absolutely.

Rob Dwyer (22:23.951)
Then maybe I go, well, I didn't realize that I like this, but I love it. I'd love to move into that type of role. So as you are thinking about support, we're going to talk more about the people. But I wonder, have you considered or are you looking at your tooling, your technical tooling? Are there specific platform decisions that you need to make now that you're getting ready to get out of that kind

10 to 12 type of person team, because for a lot of organizations, you can rely on maybe some less complex tools for a variety of different functions. But once you start to grow, it's like, well, OK, now I got to change things up a little bit. What are you seeing there?

Charlotte Ward (23:03.724)
Mm

Charlotte Ward (23:13.868)
Yeah, think, think, I think, you know, we're going through, a bit of a transitionary time right now. I think that, so I have this kind of nice chart, which shows the evolution of support over time with the maturity of a business. And you go from like all hands, every, everyone on deck to this kind of specializing and then,

I would say we're kind of at the third point or coming just out of the third point, which is, you know, we are, we're getting more predictable. Like we're building predictability. We're not there yet. It's hard to build something that's very predictable when it's very complex at the same time. And so for me getting from like the left -hand part, side of

chart to sort of three quarters of the way across, if you can visualize this thing that I'm waving my hands around for, is mostly about people, actually, I think. So much of that early days scaling is about coverage, it's about skills as well, particularly in 24 by 7 environment, which is what my team are.

It's coverage, it's skills, it's getting the structure in that allows you to build teams rather than a team. process, know, building maturity of process. And I'd say we have the structure. I would say we have broadly the maturity of process. No one's perfect. So as you said, like the next thing to look at is what can we do around tooling? And I think the...

The thing that I lean quite heavily into is scaling support isn't about hiring more people all the time. And in fact, shouldn't be scaling support is about delivering the service that your business needs to your customer base as it grows and doing the necessary. That might be more people. It might just be. certainly I would bet my growth mechanics in my team are quite different from

Charlotte Ward (25:31.244)
you know, some sort of like box shipping or something where the predictability comes really early. And so I am looking at tooling, but it's part of the story for me because there are there are other things I need to do. And

When I think about tooling, think one thing, particularly here in 2024, everyone says, AI, you should be using AI. That's how you scale. And again, in certain environments, great. I'm like, I am not the Luddite in the room. Just ask my family. I'm the early adopter in most rooms, you know? But I have not rushed to bring AI into my support environment.

because it's not suitable right now for us. There are...

many, many environments where AI can do a lot for you, for your support team in terms of delivering answers directly to customers, you know, helping your team surface the knowledge they need. A myriad of applications of AI and support as much as in any other part of the business, right? But it's not for us right now. And I feel pressure.

I feel pressure, you know. I talk to support people. yeah, talk to support people most of the time, including my own team who go off to conferences, God love them, and come back all fired up about AI. But I'm like, it's not for us. It's, and I don't want to bring too broad a brush to that. I think there are things, I think that we will adopt certain types

Rob Dwyer (26:56.072)
I bet, I bet.

Charlotte Ward (27:20.97)
AI elements to certain types of tool quicker than others. I think when everyone thinks about AI, we think about chatbots answering questions for customers. We're a long way off that. But would I apply AI to something like sentiment analysis of my surveys and my tickets? Probably. I think that'll come much sooner. And so for me, it's a matter of what's important. And when I think about particularly things like AI,

and how often they are kind of carted out in the argument about, in any argument about how you might scale a team, it has to align with the problems I'm trying to solve right now. And the problems I'm trying to solve right now are by their very nature complex, but they're also barriers to scaling.

When I think about tooling, I'm not automatically thinking about something that can reduce a human load in terms of support tooling. So there might be quite a long walk from a tool that I'm looking at to essentially the narrative of how it helps my team scale because I might be thinking about

Rob Dwyer (28:27.518)
Mm -hmm.

Charlotte Ward (28:44.92)
how we can bring something that would improve our relationship to product or engineering or how we can do analysis of our own data better, to scale better, how we can join up with other teams and reduce internal frictions, which isn't necessarily all hyper support tooling focused, but it is a big ecosystem of platforms

we exist on and in a technology company. And any one of those is an opportunity to help in my team deliver the support they need to without me just throwing people at it all the time. Again, a long answer. I'm really sorry, but I can give you one tool which we've just brought in. If that would be, if you want me to finally, finally commit to something, right? For goodness sake,

Rob Dwyer (29:33.087)
Okay, let's do it. Let's do

Charlotte Ward (29:41.954)
Give me a tool. So we, here it is, the big reveal.

Rob Dwyer (29:44.393)
Here it is folks, the big reveal. We built it up. I don't want anything. I don't need anything but this one thing.

Charlotte Ward (29:54.744)
But this is one thing. This is the thing right now. So one of the barriers to providing the kind of support my customers are looking for, maybe not barriers, but one of the increasing demands of the kind of customer base we're looking at is being where they are, helping them solve their problems where they are. We have generally done email support. Most of our customers are

increasingly talking to their customer success manager, their implementation team in Slack. And it's really hard to deliver support in Slack unless you have a tool to do it. We're a Zendesk shop and I just literally this month brought in ClearFeed to integrate to the shared Slack channels that we are increasingly setting up for our customers.

There you go, there's a tool that's gonna massively change the landscape of how we deliver support because what is unscalable is having my whole support team in every single Slack channel that we share with our customers. So that's a really easy, quick win for me. And it's not AI, it's not AI. It's a problem I need to solve right now to get us to a place where we

stay on an even keel, but deliver better support and we'll keep looking for opportunities like that. And AI will be there at some point, but right now, this month, is how do I get Slack support in a scalable way to my customers? Because these are complex questions. They want kind of, you know, there's a lot of to and fro, try this, do that, can you send me that? I need this log, what's that error? You know, this is engineering support after all.

And everyone who doesn't live in Slack nowadays, Rob, that's what I want to know. so, us being able to, you know, bring that into Zendesk so we can measure it, which is a super important component of properly scaling anyway in the future. So capturing it and measuring it, but also just reducing the mental and operational burden on my team and having to be in every Slack channel. It's a game changer,

Rob Dwyer (32:09.395)
Mm -hmm.

Rob Dwyer (32:20.189)
Yeah, it's one of the things that we always try to do is meet our customers where they are, right? And so they may be in Slack. It makes a lot of sense to just easily make that connection. But certainly as you start to grow, Slack can get a little unwieldy. There certainly are challenges with measurements, right? And paying attention to metrics and

What I love about this is there's a very specific job to be done. And you're focused on, how do I solve this particular problem? What tools do I have available? And here's a tool that does that. It essentially is just marrying two tools that I'm already currently using so that it works for me. I love that. Speaking of Zendesk and tickets, you once

told me that a ticket isn't a ticket in your world. Can you talk me through that? What does that mean?

Charlotte Ward (33:31.2)
It means when I say that, you know, I've been saying for a really long time that no two support environments are the same. And I always get asked, what are your volumes? Whether I'm being asked that by another support lead or we're discussing it on a podcast or, you know, I'm hiring sometimes I get experienced support folks coming in and interviewing with me. What is what's a typical volume in a

you know, I can give you a number. Does it mean anything if I give you a number? How many did I solve this year? I can give you a number for that too Rob, but it means absolutely nothing because the numbers inside my team are completely disjoined from the numbers, first of all, inside any other support team. As far, you know, the way I always used to say, you know, I...

When I was at Oracle I used to take 20 phone calls a day. And then I went from there to a company called Siebel and I took about 12 support tickets a week. Both of those were full -time jobs.

Rob Dwyer (34:47.816)
wildly different.

Charlotte Ward (34:48.79)
And wildly different. And that's really what I mean, first of all, when I say a ticket isn't a ticket across organizations. Inside my own organization, the same is also true because some tickets are question and answer. You know, it's how do you do this thing? Here's how you do this thing. And it's not not most of the time, you know, something that we can easily deflect because the customer still has like something customized, something that

very few or zero other customers have done. But it's a couple of interactions it's done. We also have tickets that are days, weeks in the running. Because we are running a bring your own cloud managed service, deeply technical product where we are doing deployments, are helping customers get from A to

or A to Z over a long period of time sometimes. And so if I was to just look at my ticket metrics and say that this month I did 100 and I didn't, but just to use a round number and next month I did 200, I need twice the number of people. It's not done quite work like that because of the completely disproportionate like effort involved

any ticket type. I could have 100 very small things and 100 very big things or 200 very small things. And it's just, it's much, it's impossible to measure and scale my team based on ticket counts because tickets aren't repeatable, predictable sizes. That's what I meant.

Rob Dwyer (36:37.599)
I love that you talked about the fact that we can't base certain things on ticket count because that leads me to ask how in an environment like that do you measure what needs to be scaled and how far it needs to be scaled, right? We talk about in a lot of different environments,

You have to justify headcount for a variety of things, right? So I know that you're probably in the middle of justifying that increase in headcount. So how are you doing that? Because it certainly isn't necessarily just based off of volume, which a lot of environments would use.

Charlotte Ward (37:27.982)
Exactly, yeah. It can't be based off of volume. About 50 % of what my team do is tickets. The rest of what they do is manage the managed service. We do deployments, we set up the infrastructure for our new customers and certain new infrastructure along the way for existing customers. We run a number of programs that help us as a support

help our customers. So my team, for instance, runs supportability. We take ownership of what we need and we ask for it for every new component, for every new feature. That takes time too. So we track our time.

And what I can say is that I'm a great believer in time tracking as a key data point when tickets aren't the only thing you do and when tickets aren't unit metrics that you can scale by, which they certainly aren't in this environment. So...

about six weeks into joining Snowplow. Maybe four. One surefire way to not make yourself a popular manager is to step into a new organization and say, think we probably need to start tracking time because this is really unpredictable. But we trialed it and actually, and just full transparency, it's not the first time

rolled out time tracking and I have had time tracking asked of me when I was a support engineer, not everywhere. And neither do I roll it out. So if at some point, you know, in the dim and distant future, if I end up anywhere other than snowplow, it's not a given that I'll be rolling out time tracking. I'm not, I'm not some kind of time tracking whipcracker, but, but it's useful.

Charlotte Ward (39:43.894)
If you've got nothing, you've got to find something. if you can't measure what you've got, you've got to find a way of measuring it. And when you're talking about scaling, you're talking about really cost to the business and how you keep cost to the business down. And when you're talking about cost to the business for a support team, that's time. It's people hours. That's what it comes down to. So...

Rob Dwyer (39:46.373)
Mm -hmm.

Rob Dwyer (40:06.601)
Yeah.

Charlotte Ward (40:11.278)
We trialed it in the early days of my time at Snowplow and it stuck. It was really useful really quickly. I'm not a taskmaster about it. I do have expectations. The team track about 80 % of their time. They track it real time. So they do task switching. They don't try and add it up at the end of the day. I want real data. And I want.

data with a relatively good margin of error on it, know, something that we can live with. But what I'm looking for in that is opportunities. I'm not looking to measure any individual. I'm looking at the ecosystem. And the biggest thing that has done is enable us all to have positive conversations about where the problems are. I

I don't kind of secrete the time tracking data away in a black box that only I get to look at and tinker in. Everyone in the team, everyone in the organization can actually view it. And when you have it, can slice and dice, I work for a data company for heaven's sake, you can slice and dice data any way you like to find the problem. we can join that data up with our ticket metrics because I can,

Rob Dwyer (41:25.747)
Ha ha ha.

Charlotte Ward (41:36.334)
It's all linked to the relevant tickets. So tickets of a certain type take a certain amount of time. Not just in terms of time to resolution, but effort as well. And actually they can be quite disparate. If there's a lot of comms, it doesn't actually require a lot of effort all the time. But it might not be a great customer experience. So that's one thing you can dig into. Or there might be something where you've got

one kind of please do this thing for me ticket for a customer and it's two days worth of work, you know. But then there's the whole other 50 % that's not tickets and how do you even dig into that without having something to dig into. For my team mostly that is looking after the managed service, doing some of the other efforts I talked about, about supportability, things like that. And time tracking has been invaluable.

Rob Dwyer (42:17.606)
Mm -hmm.

Charlotte Ward (42:29.92)
It really has, it allows us to say, this is the next big opportunity. This is the thing that's costing us as a business and or our customers, you know, as I said, like it's a matter of looking for opportunities in the data. so time tracking has been a real game changer at Snowplow in that sense, in terms of how we talk about support, how we talk about the support we deliver and how it relates

know, legacy product or new product, new customer types, all sorts of things, all sorts of things. It's been a game changer.

Rob Dwyer (43:08.413)
Yeah, it's certainly an interesting data point that allows you to understand who costs what, what types of problems cost what, and I think most importantly, in an environment where volume doesn't dictate things, it gives you insights so that you can identify where do we need to grow, how can we be more efficient, how can

Right. Where are the things that I can do to, to help my team, whether that's increasing head count, right. Size or maybe doing some other things. It gives you all of those insights or at least leads you in the direction.

so we've talked about a lot of different things, right? We've talked about people tooling a unique environment. think the one thing that I want to know from you is as you're going on this journey, what's the biggest challenge either in front of you or that you've already begun to tackle and what's the plan?

Charlotte Ward (44:26.952)
It's really...

It's breaking the linear growth is kind of the meta plan. As we go along that kind of evolution of support, which I talked about, you get to this point where it's predictable and you're delivering it in a predictable way. We broadly are. I mean, you know, as the company grows, as we take on more enterprise customers, the shape of support will change.

So that's something that I have to keep a careful eye on. And that's something that I'll be watching carefully over six months to a year, right? But,

For me, it's how do we break the linear growth, which is essentially what scaling support means. Scaling support successfully means you're not throwing people at the problem. Which for me, think it means that there are a couple of big opportunities and they are product opportunities that I am able to provide a lot of that data around

our product team figure out like how we, I mean, in a more traditional support environment, this would be reducing tickets by a certain category. You know, you'd be just going along to your monthly meeting or whatever and saying, this is our top five categories this month. And they'd be bashed off in the roadmap in a month or so. But there are some really meaty problems when you're talking about bring your own cloud. And when you're talking about like very, very complex deployments in a bring.

Charlotte Ward (46:06.038)
cloud environment, it's not simple to productize your way out of them. And so for me, it's grabbing the next two big things that we can evolve the product to be able to effectively get the people out of it, you know, get the people out

some of the setup, some of the deployment stuff, make it more self -serve, make it more, just make it less people intensive. And that's actually across the business, but a big part of that is with my team right now. So that's the next big barrier. It's a big roadmap piece. Lots of data coming from my team and anecdotal data

and that like operational analysis coming from across the business in terms of how we manage that and how we create product to get us out of that. That's a big unlock to getting to sub -linear growth for me.

Rob Dwyer (47:15.431)
I wonder how much communication, if any, that you have with your sales and your marketing team about customer identification and how much the customer type impacts how much manpower, person power you need to spend on support and how much certain customer types might.

Allow you to spend less time on on support. Is that a conversation that you're having today or

Charlotte Ward (47:53.838)
It is, it is a very high level.

think though that the...

The changing face of our customer base is going to change the face of support rather than in terms of the type of support rather than the scale of support. I think we will break the sublinearity and I think that's our opportunity to actually become more white glove, much more about.

best practice than break fix. And then that's another evolution. Maybe I'll need to put a point five somewhere on my chart at some point. I'll have to extend the paper a little bit. It'll be like one of those think ahead diagrams where you run out of room before you finish writing ahead. So I'll have to, yeah. But I think for

Rob Dwyer (48:54.899)
You know.

Charlotte Ward (49:01.442)
Being able to have a team that has the opportunity to deliver that level of expertise and help to a customer is the natural evolution of that single level support model. Because you get to a point where even in a single level model, I mean, we're not there, it's still incredibly complex,

even in a single level model, eventually you feel the edges of it. So being able to get to a point where you can really be consultative for customers would be living the dream for me and I hope my team as well. Because I think that's

Having that level of partnership with customers is the kind of environment I want to build. It's the kind of environment that I think is full of opportunity for technical people to come. People like me leaving uni who don't want to be software engineers, I know you're out there. I know you're out there. But who still want to do the good and meaty work, you know.

And I think that's where I would love to get the team to. And I think that's where we'll go. I genuinely do. I think that there are some product opportunities and the changing landscape of our customers is going to force us to go in that direction anyway, which comes with its own scaling challenges again.

Rob Dwyer (50:41.565)
I think the biggest takeaway that I have from our conversation today, Sharma, is that there's no one size fits all solution for any team. We can look to other teams for ways that they've been able to achieve success in their organizations. But understanding that in any organization, the variables are

The measures of success are different. The product is different. The team dynamics are different. To be able as a leader in an organization to assess where you are in any given moment and what it's going to take to move you to the next level is an art form that needs a little bit of experience and a little bit of creativity.

to be able to navigate really well. And I know that you're going to navigate this really well, and we can continue to learn from what you're doing. But also recognize, what you do doesn't mean that it is going to work exactly for another organization. That doesn't mean we can't learn from it. It just means that taking what worked over here and trying to replicate it over there

probably not the best idea in the world for any of us.

Charlotte Ward (52:11.778)
Yeah, yeah. I think, I think there's a, it is an art form, it is creative. I am sort of quite a creative individual in some ways, but I'm also weirdly analytical as well. I'm a kind of Dr. Jekyll, Mr. Hyde. So I do like magpying the data together and seeing what pictures, it's like building a mosaic, you know.

I've had all these kind of nice crockery pots from my previous roles and I've smashed them all up and make something new. It's not going to be the same pot I had in my last role. I don't know why that's an analogy, but it seems a good one for now. But yeah, I'm building something new this time and I'll do it again and again. You know, you have to, you have to be prepared to put aside your preconceptions because this place is different from the last and it will be different from the next.

Rob Dwyer (53:00.285)
Yeah, absolutely. And what's available and at our disposal will be different, whether it's budget, the types of tools that are available, the talent that's available, whatever. All of those variables are ever changing for all of us. So yeah, go smash some crockery and build something cool, folks. That's what we're going to do.

Charlotte, thank you so much for joining Next In Que today. It's been just an absolute pleasure talking with you.

Charlotte Ward (53:34.296)
Thank you so much for having me. It's been a pleasure to be a guest for once. Thank you so much.

Rob Dwyer (53:40.327)
We should also mention, everybody check the show notes. Charlotte has customer support leaders podcast. We'll have a link for you. You can connect with her on LinkedIn as usual. Just check the notes for all of those. yeah, go listen to some of Charlotte's crockery stories or whatever else she might have out there in the future.

Charlotte Ward (54:08.622)
Thank you so much. I can only apologize for the weird analogies. I end up on a story train and I can't get off it. weird.

Rob Dwyer (54:18.29)
I love it. I love

Charlotte Ward (54:21.998)
Thank you,