Sid: Recording is on. [clears throat] All right. Craig, nice to talk to you after a while.

Craig: Thanks, Sid. Thanks for having me.

Sid: I guess we’ll dig right in over here. I really wanted to sit down with you and get an idea of how you got into support, what you’ve been working on, and just give the people who would be listening to this podcast a bit of an idea about you. How about you start with a quick introduction before I jump into some questions?

Craig: Sure. My name is Craig Stoss. I am the director of support at a company called Arctic Wolf Networks. We’re a security-as-a-service company based between California and Ontario, Canada. I have been in support leadership for about seven years between three different companies. Before that, in various customer-facing roles for probably the past 13 years before that. It’s been a long customer-facing journey for me.

Sid: For people who don’t know, the journey started together. Craig and I used to work together at a small company in Waterloo not too long ago. I don’t want to make us sound old.

Craig: [laughs]

Sid: Not long ago at all. From your perspective, Craig, what got you started into support?

Craig: I got into computers quite early. I remember being in grade three or four and there was a computer in the back of the room. There was a Commodore 64. The rule in the classroom was is whenever you finished your work early, you could go and use the computer and learn different techniques. I really took to the diagnostic side of it. I loved looking at, in that time, QBasic code and just looking at it and diagnosing it.

That’s how I started to get more and more computers. As I got my first computer in my own home, which was a rarity back in the ’90s back then, and the internet started to evolve, I quickly learned that I really enjoyed working with the technology. I more specifically enjoyed the diagnostic side of things as opposed to many people who like to get into the coding side, for example. On top of that, one of my first roles, one of my first paid jobs was to train people on what the internet was and how to use it.

Sid: Cool.

Craig: It was through a local library program and it was a summer student program. Again, I found that I really enjoyed interacting with people. When I got out of university and started doing internships through the university program, it was just logical to combine people and technology. Some of the initial roles I took were in [inaudible 00:02:47] and then, of course, support. Eventually, I just settled on support once I graduated. That turned into more consultancy and then back into support leadership because it truly is a passion of mine to help customers and to be part of that diagnostic and investigation. That’s really thrilling for me.

Sid: Cool. Now, that’s a neat story. It’s the people that really got you into the role and it was the ability to work with them or you wanted to work with them as opposed to just be on the technology side. I guess from that perspective, describe the organization and the people who you work with today.

Craig: Today, I run a backline support organization. We’re actually not external customer-facing. We sell a service and our services operation engineers provide that service to our customers and then they become my customers. All of my customers today are internal customers, which has a unique set of challenges when compared to external customers because there’s, obviously, more visibility of internal things and there’s less of an opportunity to spin things or-

Sid: – buy time.

Craig: Buy time, yes.

Sid: [chuckles]

Craig: The team I work with is a team of seven people who are highly specialized in different aspects of networking technology and security technology. We’re considered a third-line support. The services operation engineers being the frontline support, then they have an escalation path through a set of security specialists, and then those security specialists will escalate into my organization.

It is actually reporting into the VP of R&D, which is also a different structure than traditional support. The reason for that is that, historically, this team has actually been, and until today, has been embedded directly within the various teams that are set up within support. We use Scrum methodology. The Scrum teams each have a member of my team embedded on them so that they can learn to be more specialized in their area.

Sid: That’s pretty cool. That’s actually a really neat way of doing more heavy lifting support without being directly in support so that you can actually get the time to delve into those gnarly issues, right? Because I know that’s been a challenge in the past in some other companies that we’ve had the pleasure of working at together.

Craig: Yes. I think this is actually the company that Sid and I were at. Actually, it had a very similar model to this. We had a team of highly-specialized senior support engineers. I think that the real advantage here is that my team, literally, sits beside these people every day, learns their sprints and their stand-up methodologies, learn where their strengths are.

When there is a problem, we can escalate quite fast to get to the right people. We can use the right language and we’re learning hands-on. Every day, we’re actually downloading information from a traditional development organization into support such that we don’t have to bother development as frequently as maybe some support organizations do which, of course, results in more QA, more features, more defects being fixed, et cetera.

Sid: That makes a lot of sense. Tell me a little bit about the metrics you guys use. I’m assuming it will be significantly different from a standard support environment. How do you merge support metrics into a Scrum-based environment for all practical purposes?

Craig: That actually was my first challenge once I was hired here, is to start to understand the metrics behind it all because they traditionally didn’t even have a system. They sort of half-used the development system, which in our case is Jira. At the same time, because they were known entities within the company and the company expanded so rapidly, there’s a lot of tribal knowledge. People are using Slack or email. The customer-facing tool that our security engineers use is Zendesk. Often, we get brought into that tool as well.

We were spread across many, many places. The single biggest one for us is SLA. The reason for that is that we live in a security world. Security incidents, I don’t want to call them breaches because that’s not what it’s about, do have a higher priority of investigation because you have to react very quickly. The single biggest metric is the time it takes us to triage and assign a ticket out to the right people. Beyond that, most of our metrics rely upon the resolution time. We don’t focus as much on things like NPS and CSAT as we probably would have in an external-facing world. I also focus a lot on the net amount of iterations.

Sid: Iteration being like a handoff between front and backline?

Craig: Handoff as well as responses back and forth. For a customer, you sometimes get in this loop of you email the customer, wait a day, the customer emails back, and you email the customer back with some more ideas, and then they email back. You get to these iterations of conversing. We’re all internal. We have access to Slack together. We have access to our conferencing tools. We can see each other’s calendars. My customers are internal.

That amount of iterations, that amount of back and forth needs to be zero as much as possible because it’s instant. As opposed to the whole traditional model of I’ll email the customer back and wait, it’s now off my plate until the customer gets back, we’re all internal. It’s never off of our plate until the customer is satisfied. That might entail waiting for the customer to take some action on their side.

Generally speaking, I really do focus to cut down on the amount of waiting time between responses because we just don’t need to do it here. We can call the person. We can book a meeting with that person. We can Slack them a message quickly. Those are probably the three big ones that I focus on right now as part of my team. We’re constantly trying to figure out what metrics we can look at even further to be able to show the value to the organization.

Sid: It’s an interesting one. Because you said since you guys are internal and you’re providing that internal layer of support, you’re not looking at CSAT or NPS, which it makes sense from an internal organization, right? Because if someone doesn’t like something, they’ll tell you. I guess the part that’s interesting to me is the flowthrough of the experience to the end customer.

Even though you’re not measuring CSAT internally, there is a direct impact on customer satisfaction externally based on the services that your group is providing or the manner in which it’s providing it. Have you guys thought about how you’re measuring the impact if not the actual CSAT there? What are your thoughts on that?

Craig: I should have clarified that. We do NPS and CSAT as a company. It’s done by our services operation. The other thing to note is that as part of our service, this customer is not always involved in it. Sometimes the actual service means solving the problem and then notify the customer after the fact, “Hey, we noticed this problem at 8:05 and we renovated it at 8:10. We just want to make you aware it happened. Here’s the summary of the issue. Have a nice day.”

Sometimes the customer is not even involved just by the nature of the service we provide, but there is NPS and CSAT run. How we impact that as far as my team specifically is really important. That’s why the timing metrics to us are really important because for every minute we delay, triaging or not getting the right person on the phone or whatever it might be, that’s a minute on the customer side or maybe even two minutes on the customer side by the time that person translates it for the customer to read and understand.

We haven’t started doing anything specific to that, but I really wanted to– The way our systems are integrated, I’m hoping to be able to start saying, “Of the customer cases that were escalated in R&D, here’s the time of resolve versus the time of resolve ones that were not in R&D and how do we shrink that delta.” The key for us is getting the right people as fast as possible. Just be of the nature of security issues. How I can improve that is just making sure that structure is understood, consistent, and smooth. It’s foolproof.

Sid: You actually touched upon something that’s a bit of an ideal scenario in some support environments, which is the customer’s not even involved. When you see the problem, you fix it and then you go and notify them. It’s almost the epitome of support to have that proactive level of service. That’s great. The question I have is given that it’s a security environment, how do you engage them in a way that it makes for a constructive conversation around, “Hey, look, we were proactive and resolving this,” as opposed to telling them about something bad that potentially happened and they should be worried about? Do you know where I’m going with that?

Craig: Yes, I do. I think that in our world, it’s all about transparency. The common phrase we hear around here is, “Security is a people problem. Let’s solve it with people.” Automation can only take you so far. I don’t know the exact numbers, but it’s in the tens of billions of observations that our systems handle every day. Only a very small, small percentage of that has any real meaning.

We do use certain AI and machine learning algorithms to make sure that we are focused on the right things. When something comes to us, it’s all about ensuring that our investigations are thorough, provable, et cetera. If we go to a customer, we don’t say something like, “Oh, there was a potential malicious login from a foreign country.” We had a person attempt to log in five times with wrong credentials at 10:17 AM on Tuesday from this location in this city. We immediately shut down that IP address. “Here’s the IP address for your reference.” It’s a very, very specific investigation that’s done because the idea is to show that we know exactly what happened. We knew how to stop it. If you–

Sid: You have the right people on the job.

Craig: We have the right people and then the customer can look at it and say, “Well, actually, that IP address is familiar to us. Maybe this was something that we didn’t need to block for whatever reason.” Someone was traveling to a foreign country or whatever it might be. Whereas if you just said, “Oh, there was a potential malicious login and we blocked it,” you may not have that level of engagement of conversation.

I’m a big believer in proactive support. I’ve given talks on it and written articles on it. I think that we’re getting into a world where that’s becoming so much easier to do in the SaaS worlds with machine learning in the background. Being able to diagnose problems in real-time and either prevent them or recognize they’re about to happen and divert the customer all together is becoming easier. I think that that’s going to reflect in a lot of companies in the future.

Sid: You mentioned something there almost towards the end saying you either resolve the problem beforehand or divert the customer in a way where it would be easier for them to get that help. Where do you see support heading in the next 10 years with the evolution of AI where a lot of the service is either self-service-based or proactive like you defined it? I guess two parts to the question. How do you see that evolving and how do you see customer expectations evolving as part of that? Because now, they’re coming to expect more of things, right?

Craig: Yes. No. Well, I think the crux of what you just said is that customers are going to go to the vendors that provide that level of detail in their support and that level of service. How do I see it evolving? I really see SaaS-based companies specifically and IoT device companies too. I really see them embracing that. Embracing the fact that they have all the data, that they can collect whatever data they want. They can split it in any way they want and they can start to understand. I call it where your customer is.

The idea is that if you understand where your customer is when they hit a problem, you can then solve it in that spot as opposed to forcing them to pick up a phone or send an email. My example is if you have an IoT lawnmower and that something bizarre happens in the back 40 of your life, are you going to really have someone have to then pick up the lawnmower and move it inside and screen capture error codes or whatever is on the screen or you can have a support button that says, “Hey, there’s a button here,” or there’s a menu option that says, “I have a trouble. Here’s all the diagnostics.”

It uploads it to some server and the university calls you back immediately or is able to diagnose it. My example I talked about once was the idea that we can wake up. We can ask our Google Home to reduce the temperature on our smart thermostat. We can walk out the door or take a smart car to a mall. We then can use a big tablet in the mall to find the store you want and then we can use an app on our phone to pay for the purchase.

At none of that point are you on someone’s support contact page to find a phone number. At none of those points are you near a chat widget. If that payment fails in the middle of that store, what are you going to do? Are you going to send an email to your payment app company and say, “Hey, please support me,” while you stand there in the store waiting to buy your shirt?

You’re going to want that error message or whatever that is to immediately notify someone at the other end and call you back. I remember this happened to me about several years ago. Probably about 10 years ago, I was making a purchase online for a flight. When I hit the button to buy the flight, my phone rang simultaneously. I thought “Well, that’s a weird coincidence.”

Not only was it a weird coincidence, it turned out it was the airline calling me to say that they had just got a transaction from my account. Sorry. It was my credit card company. I apologize. My credit card company calling me saying they just got a transaction from my account for a flight and wanted to make sure that it was me that did it. I thought that service. That was 10 years ago. Today, you can do that in any aspect. That’s how I see it evolving.

I see it evolving to a point where companies understand where their customers are, when they hit problems or when they need help, and proactively solving it or helping them in that location. As far as the proactive bit, that could be as easy as a little pop-up on your screen or on your app or whatever that says, “Hey, we notice you clicked buttons one and three. Maybe you want to check button two too. Here’s why you would check button two,” something like that. That just prevents future errors.

As far as where this is going, to me, that’s the crux of it, is that I think customers are going to start demanding that service. They don’t want to email us. They don’t want to text us or chat us. The cost of an omnichannel is fantastic. If you think about it, that’s actually fantastic for the support agents because they can work within a common tool for the user. They don’t care. They just want a convenient channel.

I don’t want to be using an app on my phone and have an error message that says, “Please go and email support,” because I have to switch screens from your phone. If it says you need a serial number or you’re going to manually type that serial number, you want to send that all to support automatically. When you call, the support agent is like, “Oh yes, I know exactly what you’re calling about. I see the error message right here in the logs that were auto-forwarded to me. Here’s your solution,” or whatever. I truly believe that’s the future of our support in general.

Sid: I think if you talk to a lot of people, we can’t get there soon enough. The number of times you’ve had to call into your cell phone provider to say, “Hey, it’s me,” and go through a rigmarole trying to prove to them that it’s you before they even answer a question for you, that’s happened way too many times to a lot of people, right?

Craig: Yes, absolutely.

Sid: Craig, I know we go back a while. The one thing that I wanted to ask you was, who has been the one person who you’ve learned a lot from about support operations and customer experience? You can’t pick me, so it makes it a little hard.

Craig: [laughs] That’s a great question. That’s a really tough question. I think that probably the person that was the biggest influence on me specifically was the boss I had right after I left the company that we worked at together. He was very senior in the industry. He had been in technology for the better part of 30 years. He was the senior vice president of customer experience. I think his analogies were just really poignant.

That really stuck with me is just the thought of, “Okay. How many of the things that you do every day that are easy?” They’re made because they’re easier for the support reps as opposed to easy because they’re made for the customer. That was his philosophy, was that we tend to think about what’s– Ticketing systems like Zendesk are easy for the support reps. There’s one tool. All the updates come into one place. The notifications come to them. They don’t have to worry about it.

They can see the statuses. For the customers, that’s not necessarily easy. There’s a lot of stuff in those notifications that customers don’t care about, all the preamble to those auto-responses. They have to create accounts for each of their vendors that they need to contact if they want to be able to see their statuses. That’s a lot of passwords and things to manage. It’s not necessarily set up for the customers.

When you start thinking about it that way, you start to think about even the wording you use like what are the phrases we use because that’s the simplest way for us to say it as opposed to the way the customer understands it. I talk a lot about action plans. What I define as an action plan is as opposed to me saying, “Hey, Sid, can you check if the value of this configuration is a 10?” and you come back and say, “Yes,” which was a dynamic iteration of conversation. I could say, “Hey, Sid, if the value of this property is greater than 10, you need to make sure that this setting is done.

If it’s less than 10, you need to do something else. If it is exactly 10, you need to do this third thing. If the property doesn’t exist, you need to call me back immediately and provide me with this set of information so that I can solve your problem.” That’s easy for you because now, you know exactly what my thought process is. You know why you’re looking at it and you’re not feeling for the customer. You’re not feeling helpless by just saying, “Yes, I’ve answered your question. Now what? What’s next?”

Sid: “Now what?” Yes, “What’s next?” You giving them the whole plan for where we are going to go end to end without them having to guess the next step of the process?

Craig: Exactly, correct. That’s what this leader gave to me, was that sense of, “Think about what the customer needs to be successful in all cases even when you’re delivering bad news, not what makes it easy for you.” It’s easy to fire off that question. Put the status to waiting on customer and forget about that question altogether. Move to the next thing because it’s quick.

Sid: That’s perfect. In fact, that’s a very impactful statement. If you take away one thing from this podcast, it would be put yourselves in the customer’s shoes and look at it in a way that’s easy for them to understand than us. Cool. Greg, this was a great conversation. Thanks for sharing all your insights. We’re almost up for time here and thanks for being on the show.

Craig: Thanks, Sid. It was really fun. Great conversation and look forward to speaking again soon.

Sid: Awesome.

[00:24:41] [END OF AUDIO]