Between Two Clouds - A Look Inside Cloudflare Support

Hello everyone and welcome to Between Two Clouds Inside Customer Support at Cloudflare. My name is Shane Ossa. I'll be your host today. We normally talk about what's going on inside Cloudflare customer support, but today is a little bit different. Today is a special treat. Today I have with me two amazing guests. I have my friend and manager, the head of customer support at Cloudflare, Otto Imken. Hi Otto. Hey Shane, how's it going? Good. And I also am honored to have Phil Verghis on the show, who's from Clever Insights. Hi Phil. Hi Shane. Hi Otto. Hi. Thanks for coming on. So today we have a special treat, but first I want to sort of set the stage and let you know who we all are. So my name is Shane Ossa. I've been working at Cloudflare for about four years now. I am the training manager for the team, so it's my job to make sure everyone gets the training they need to do their jobs. And Otto Imken has been the head of customer support at Cloudflare since 2016, but he's been doing customer support forever, since 1997, since Al Gore invented the Internet, at companies that you've definitely heard of, big ones, and some other startups that you might not have heard of. And Phil is an industry titan in the customer experience industry as well, was the founder of the support team at Akamai and ran their network IT and operations groups, and then went on to do some other amazing things, including co -founding the award-winning Clever Insights solution, which comprises of options such as consulting services, software as a service, pilot and accelerator programs. It helps service and support teams evolve and improve their processes. So he has a ton of insight into what the whole customer support, customer experience industry is doing. Otto has tons of insight in that as well, but also what we're doing at Cloudflare and I do as well. So today we're just going to have a conversation about the Cloudflare, how we make the sausage inside Cloudflare, but Phil's going to give us some great Clever Insights, if you will, or perspectives on what's going on in the rest of the industry. So I've been talking a lot, so I think I'm going to just welcome our guests and facilitate this conversation and just start with Phil. Hey Phil, how's it going? What do you want to talk to us about today? Well, thankfully, you gave me a chance to prepare for this. So I thought I'd just walk through sort of musings from my side. So as you see, I've lost lots of hair as I've prepared for this talk, but the point is I've been in the support industry my entire life, even though I've run many other groups. So taking care of customers is my passion. And I thought I would share some of the things that I've seen, especially now that some of the best companies on the planet are doing in terms of support. So will that work as a thought? Yeah, definitely. I mean, that's one thing I always love is to get reinforcement from you and other people in the industry is like, is it just us? Are other people seeing the same things we're seeing, feeling the same pain? And it's always so reassuring to talk to kind of fellow support people and go, oh, okay, we're all dealing with similar problems. So this will be great. Thanks for joining us, Phil. My pleasure. So I think the first thing to know is that sort of managers in most industries are trained to keep trains on track and to keep them running on time. That's what we and our teams are measured on. And when disruptions happen, our job is to get them back on track if they're derailed and to get things back on time. So we consistently bring things back to a steady state. And that works beautifully until big disruptions happen, like COVID. When the shock is so big, we actually have to lay a new track. And we don't know how. This is when we have to make complete changes to what we do, how we think about it, how we train people, because it's a completely different skill set and we don't train or teach or measure this new skill. So what I thought would be useful is to talk a little bit about how world -class organizations, small startups that are starting without any baggage, companies that are scaling massively like Cloudflare, and large enterprises around the world are doing the best of the best as we go to this new world of figuring out and preparing for laying new track. So the three areas that you have got to make the biggest, that they make the biggest changes on. The first is this concept of managers going from enforcers to player coaches. The second one is building the complete shift to a knowledge-first environment that's going from cases, cases, cases, backlog, escalations. How many cases do you close to a knowledge -first environment? And the third is moving your measurement system completely from cases to knowledge and other things that are important but not obvious. So those are three areas I want to talk about. Enforcers to player coaches, knowledge-first environment, and then measures, a new measurement system. Just to kind of jump out a little, when you talk to different companies about these three areas, do you get resistance from people and say, or are people usually open to things like knowledge-first? Do people think this is a bad idea? Knowledge-first and the manager pieces and measures are all interrelated. And once people understand how they all help each other, it becomes easier. Knowledge-first, the hardest people to convince typically tend to be the mid-level managers. Frontline staff loves a knowledge-first culture because very few people like being stuck doing the same thing over and again. Because you feel like the idiot, you know there's a problem, you've reported the problem, it's going to be fixed sometime in the future, you have no control. You've got upset customers or partners, you've got to deal with it. Leaders obviously want to get away from escalations and you want to use the product and have joy. None of the traditional support stuff is joyful. But the problem is that we have not really helped managers move from their reward system being cases and firefighters and keeping the train on time. So that's why that linkage is there and also that linkage back to the measurements. If we don't change how we measure, then it's a vicious cycle for the mid-level managers. Yeah, if all I look at is the number of tickets my team solves every week and you shrink that from a thousand to a hundred, maybe you don't need me anymore. Maybe I need to artificially have tickets going through the system all week long in order to make myself useful. So yeah, I guess that's a change in mindset. Absolutely. And I know you've been one of the leaders in this, Otto. You've seen this at other companies, you're doing it at Cloudflare as well. And I'm really keen to hear what you guys have done. So let's just briefly go through each of these three. And the thinking is we'll just have a conversation. You may or may not agree, but I'd love to hear your experiences and I suspect people watching would as well. First is enforcer to player coach. So these are all things we do as consulting gigs and as training. This is just rather high-level snippets of the kinds of things. Typically, when we manage people in the early days, when you're coaching little league or very young kids, it's really funny. All you're trying to do is to make people stay safe and have fun, right? You have 10 people chasing a ball around and you as a coach know more and you're the teacher and you're also the enforcer of rules. So when you go through the ranks, you develop expertise in a technical or a functional or a professional domain. Being the coach or the leader means you have the right answers. Once you've proven yourself, you can keep rising up and then you move into people management, at which point you rinse and repeat the cycle. You get people to teach people the basics, you enforce the rules, you know best, move it on. That makes sense. And at the beginning with new teams or junior people, it's fine. You're trying to let people become the best version of themselves. You need some skills, right? How to use this tool, this product. But when you go to a coach, sorry, Shane, were you going to say something? No, I was just agreeing. Yeah. Yeah. We teach people, I mean, almost all the training we give sort of falls into these kind of four high-level categories of, you know, Cloudflare products, how they work, how to break, how they break, how to fix them when they do break, the tools you need to use to troubleshoot them, the relevant technologies that are at play, DNS, SSL, caching, and so forth. And our team's processes and policies, right? So everything sort of fits into those four. But tell me more about sort of coaching and development growth topic. So I think if you move from sort of coaching kids or junior people, where you're teaching them basic skills and how to be the best at that skill or job, to a coach, the issues are different. You can't coach a college-level team the same you would a kindergarten team, or you could, but you wouldn't be a good coach. Fundamentally, as a coach level, you're helping the team see around corners. You're anticipating issues for them. You're helping them to see what's on the schedule, what a different opponent is, how you have to adapt your play. Shane may be fantastic and the superstar versus team A, but versus team B because of their structure, their team players, the schedule, etc. Maybe Shane has to take a supporting role. And it's Otto who needs to take over, supported by three people. These are very different skill sets, right? So it's moving from rules enforcement and doing the job to how you work together. Yeah. Connecting them to a purpose. What is the purpose of this game? To win the championship or is it just to get through the game and have fun? These are contexts, again, that you don't give any teaching individuals, right? You don't have the time and the luxury. But coaching gets much harder. But fundamentally, I think the difference is instead of coaching people to become better versions of themselves, which is necessary, but not sufficient. For coaching, you've got to enable all of us to be better than any one of us. And that's not an easy skill. Yeah. We talk about this all the time because the nature of Cloudflare is our products are so complex and there's so many products. We have dozens of very different things that we release that are going on all the time. And so no one person can know everything. And so Shane and I and the other managers are constantly reinforcing, we're a team. You have to ask questions. You have to collaborate. No one's expecting you to be the hero and jump in and solve every problem. It's really interesting the more you talk about the team and the coaching, I'm starting to picture on a typical shift in North America, for example, we have a team lead who's the team lead in charge for the shift and that we call the on-call backup. And at this point, there's so many things going on that there's even too much for that one person. So I'm starting to picture like a basketball team or a football team where they have an offensive coordinator and a defensive coordinator and have one person coach this expertise and one of this one. And we're really getting to the size and the complexity where we need a whole team and we need a whole team of coaches to help you with different things. So, yeah, I think that's an absolutely good point. And that's exactly the kind of stuff in our trainings we talk about. As you move to scale, how do you specialize? How do you actually bring the best out of people? So it's not by role or function, but it's what they want to do. It's what they want to do, they're good at and they're willing to listen. That's, again, just a higher level skill set. But the more people feel a trusted, safe environment where they can do that, the easier it becomes. And I know that's something that you, Otto, in all my years working with you, you've always done, build an environment of openness and feedback. Shane, I'd be curious from your perspective, is that something you've seen? Oh, yeah, definitely. I mean, there's so many threads that you mentioned so many different things. I mean, the first thing I was thinking about was the specialization component where it's even better for the customer experience if the customer is dealing with someone who's a specialist in a particular product line versus someone who's a generalist, who's good with that product, but maybe not the subject matter expert on it. It makes it a better customer experience. We can solve their issue more quickly when we route them to a smaller pool of highly trained individuals in each region. But I really liked how you mentioned if it's what they want to do. So I like to think of this sort of a marriage between what someone wants to do and what the team sort of needs in each region. OK, we really need someone to specialize in this subject. Does that align with what someone wants to learn and where they want to take their career? It also helps us sort of start pathing towards career goals, right? Security specialist, right? A CVN specialist, layer three, four networking specialists. We've tried to create growth paths internally on our team that sort of align with these specialist groups that allow people to then decide, you know, in terms of their career progression, what they want to specialize in. We provide them that. We give them the professional training from engineers at Cloudflare, you know. And then they go on to help customers and eventually they can grow into these amazing roles on our team, keeping them in support, which has always been a struggle for support, right? I mean, there's people that work in support forever, Otto, myself, other people, you know, and there's other people that graduate to you, Phil, and there's other people that graduate to other roles, and that's OK. But we're trying to develop a system where how can we keep these amazing, talented people engaged on our team, contributing, because there are such challenging products or problems to be solved on the front line customer level that we notice over and over again. The engineers are wonderful and they're great at debugging and they have a huge backlog that needs to go through product management. And then we have our tech support engineers that want to solve this issue and they reach the limits of their power. How can we sort of unlock more power for them? And the third thing you mentioned was whether they want to learn it or not is a huge component to learning. What I've learned in my career as a trainer is you can assign someone to learn something. If they're interested in learning it, it's an uphill battle. If they're interested in learning it, that's the biggest prerequisite to someone learning something. If they're like, hey, I want to become web security, like InfoSec is, you know, my raison d'etre, I want to be an InfoSec person. Great. Now we know we're going to put them on the security path. They want to learn this. We need someone to learn that. And you've got them there. So those are sort of the things I was thinking as you were mentioning that. So I love it. Yeah. And it seems like a cliche, but if someone is passionate about something, they're going to do so much better at it and they can take ownership of it. I'm thinking of a shout out to our billing team. Our billing support team is amazing and they are passionate about it and they own it and they know all the ins and outs of all of our different systems. And they're so much better at it than having, you know, it being everyone have to know everything. They can really specialize and own that area. Oh, I have fond memories of billing support. It's tough. Yeah. Shane, one little anecdote from my early Akamai days, I made a bet with my counterpart, the VP of engineering, more people believe engineering to join support than the other way around in the first year. And we won. Wow. That's awesome. Because basically we said none of us know, the CDNs didn't exist. SaaS didn't exist. Customer success didn't exist. DevOps didn't exist. We kind of helped create those industries along with other companies. So my pitch was, if you're really, really smart and you want to just work by yourself in a little hole, go for engineering. If you want to know how it's used, why do you use it, all the context, work with sales, work with engineering, work in legal, come to support. And we have great dim sum. So that was our story. Oh, that's what did it. Snacks are crucial. I say a similar thing all the time. If you want to learn everything about Cloudflare, support is the best place to go and start at, because we touch all the different products, all the different teams, and you can learn everything. And we'll let you, also new to Shane's team, and you can specialize where you want, and you can learn everything on the Internet through support. That's something that some companies do. In fact, there's a company called MathWorks out Boston area that does this. Every employee has to be in support for a couple of months before they go to any other job, tech writing, legal, HR, anybody. I've heard of that. That's pretty cool, right? Because it forces you, it builds alliances. Anyway, lots of cool things you could do. So Usman, if you're listening, we want all of your engineers to spend a month with support. There's no better way to make sure that bug fixes get done properly. Actually, I will say that the product and engineering teams, all the teams, but engineering has been a great partners and they have sent people in to shadow with support. We encourage and facilitate engineers spending a lot of time with support to learn about what's happening on the customer level. So we do do it to some degree, but I'd love that kind of fixed. Okay. I've heard of other ones where you do sort of like a rotation where engineering, one month, a year or something spends in support. Yeah, I think it really depends on the culture. For me, I know at Akamai, I used to be one of the first VPs that used to do welcoming for every new employee. Because again, our premise was SaaS. Again, the concept internally, people didn't really know that concept. So if you sold software or whatever you did before, just once every three to five years, you need to understand every conversation from how do I get directions to the office to how clean the office, every interaction, we've got to own that experience. So that was my story. I said, if you are not interested in that, just leave, don't come to the company. That was the pitch, but I insisted on being. So even now, 20 years later, I'll get people who I don't know saying, oh, you are the guy who introduced me to Akamai. Great. I hope you listened. That's amazing. So I thought the next pillar I'll walk through is this case first to knowledge first. Another key thing that people are doing as they look to helping people understand how to lay new track. So if you look at issues from different, slightly different lenses, if you look at the workflow, a customer has to come in and we'll call that the customer effort. How much effort does the customer has to go through to get their issue to you? So CSAT is interesting, but not very important. It's interesting as a snapshot because some people are really happy, some most people are really unhappy. You have to deal with it. Don't get me wrong. Net promoter score is also interesting, but support, we can't do anything about it. If it's done properly, it's the person who's buying the tool or your service or Cloud Play. But I, as an engineer, support frontline can do something about effort because I know, I have feedback, I know what to do. So the point is, this is a snapshot of a really well-known company. This is a summary of the kinds of things we did when we dug into customer effort. It is really hard for the customer to find knowledge, to search, and to find it in their own words. It is technically correct, especially for you in the CDN space, right? It's technically correct, but I have no clue what the heck you're talking about. I've heard that so many times from customers. Yeah, we send them the correct answer and they say, I don't know what you just said. Right. And that's our bad, right? Because again, if you're technical, yes, I can understand it, but most people won't, especially as you scale. I think that's where we almost add the most value. It's one of our huge value adds as customer support thresholds is taking what the engineers have said and making it human readable for the general public, right? I mean, there are some developers out there that just want to tell it to me straight, but most of the other people we're dealing with, we have to make it understandable, especially at the content knowledge level. Yeah, absolutely. And then if you dig further into it, into your portal, typically people find that it's obvious to us that they've got to enter things like, hey, this is severity one or severity two, but if they don't know what the implication is, they might always go to sev one and get irritated when you go down or they don't understand what the heck it means. So if you don't give them clarity on the implications of what happens and make it clear, this is what this means in my context. So they have their own service level agreements, customers beating on them, escalations. You're just one of the vendors or partners along the pathway to getting back to a steady state and the trains running on time. So if you give your view of it, that does not translate to their view, they're going to bump it up to a higher one just to make you jump. And then all sorts of bad, but this is just one small friction point where the effort is painful. Not just while I'm thinking about what to submit, but how to submit it. But also later when you come back and tell me bad boy, bad girl, that's the wrong thing to have done. It's like WTF, that's not what I said, right? Attaching files may be hard. I can't add colleagues back to your point about specialization. If it's the two of you need to bring in a third person and the customer knows that you need to, or you know you need to, and you can't do it. Again, waste of time because the machinery will swing into action. The train will go off to three other stations before it comes to the station it needs to. It's a tooling limitation. It's also secure. There's also security implications for us as well. It's really hard to just bring any old person in on very sensitive security related conversations. But the point is, we have to understand that and see if we can get hacks that get to at least partly addressing it, right? Instead of saying, no, we can't do it. It's not possible. What can you do? Yeah, this is one thing. So for the past 10 years, the support industry has been moving towards customer effort scores instead of satisfaction. And I think that's definitely the right way to move. This might be kind of a technical question, but how would you score the customer effort? So would I count the friction points here? There's like five friction points. So it's a five. Would I count the time it takes the customer to get from beginning to end? If I do both, or is it all just relative? Everyone would agree today, your effort is high and we're going to change things. And now it's lower than it used to be. So it's relatively better. Is there a good best practice around those different options? Yeah, the simplest way to do it is actually just like a CSAT survey, customer satisfaction survey, ask the customer. And actually there's a customer effort 2.0 says effectively something based on how hard you thought it would be. How easy is it? So I know if it's a complex CDN issue that's going across data centers and multiple vendors, I expect it to be painful. I may not like it, but I expect it to be painful. If it's delightful, wow, I'm going to be really happy. The effort is lower because in my mind, effort has to be less than you expect and better than the competition. Those are the two things you've got to watch for. So that's the lens I would look at it from, from the outside in. If it's difficult to get and add another survey question in, I think then you can do proxies like you're saying. Would a reasonable person of this persona with this level of skill set and this access to our tools and this training, take a snapshot of what your assumption is. This is what we interpret would be difficult for them. And then try it and see if that's better or worse. And then you can do things like there's five things. Is it now three? Is it two? High level, this is an opinion that you're trying to move. As long as you have a stable snapshot of the beginning and the end, it's relatively as good or as bad. It doesn't matter if it's right or wrong. You're just looking for the relative improvement. And as long as you're focused on it, it gets better. That's okay. And you must see, we can't ask about anybody specific, but you work with a lot of different vendors out there and partners, and you must see people administer the survey at different times. Is it most common to just administer the survey at the end of an interaction or are there other little sneaky places that you can put this survey, maybe just on the KB in general, if someone stumbles across it, or does it have to be like cases solved now tell us, or can we slip it in somewhere along the self-service journey? That's a scarily good question. The most common replacement is for CSAT. Whatever you do with customer set, you'd replace it with this, or maybe do an A-B test. Some you do CSAT only, and one you do CSAT, one you do customer effort and try. Because in the Asperger's Co itself, you can have the sentiment come up that shows satisfaction. So there's ways to get both. But I would just try it that way to start. That's the simplest, least friction internally to do. But if you get more nuanced and people are doing a lot of self-service without coming through opening cases, then absolutely, that will be a place to ask. Did this knowledge-based article help you or not? Even within support, we rarely ever fill it out. How do we expect the average customer to do it? So that may be a good one saying, okay, you look for three things. We're paying or useful. Yeah, that makes sense. So the point is, look at customer effort. Today, when we're doing a case first, we don't really think of customer effort, despite as Otto said, for 10 years, we're trying to. But when you really put this lens on, you realize it's high and can be lower. The second one is, when you do a case first approach, case, case, case, solve, solve, 60 to 90% of what you've seen has been seen by somebody in your ecosystem before. And this is not just the simple stuff that people think of that frequently ask questions, but the really complex stuff that in the CDN world may come once every two years. That somebody seen before, in fact, is as important to capture with knowledge. How did I know that it was this direction and not that direction? It's as important as here's a recipe to follow to fix this problem. Two different types of knowledge solutions. But the point is, more complex the effort, I would say that the more have been solved by somebody. This may be less people who have never documented how they thought about solving it. That's just incredibly painful, the effort when you're doing case first. Again, frontline knows this, leaders know this. It's a mid-level managers because we are often rewarded by throughput. So that's a problem. And the third one we rarely think about is manager effort is very high. We rarely think about it. We're too busy fixing things the second time around. We never have time to fix it the first time, the root cause. We're dealing with escalations, break-fix, meetings, updates, quarterly business reviews. The average manager, according to McKinsey, spends less than 2% of their time, not just support, all industries, 2% of the time thinking strategy, which is what the business wants you to think about, not just the break-fix, get the stuff cleaned. Going back to the last one about the 60% to 90% cases, I think in my head, this is where I was flagging our community forums. You mentioned FAQs, the easy to spot ones, but as you know with CDNs and the Internet, there's an infinite amount of combinations of hardware and software infrastructure someone could be running. And our support engineers are wonderful and they will get to the bottom of your problem, but there's a finite amount of support engineers. And we're in the fortunate position of scaling so exponentially that we have tens and tens of thousands of customers with tens of thousands of domains and namespaces and assets behind Cloudflare that we have to leverage our customers. They have to work with each other and we have to facilitate that. So we have a huge initiative right now going on internally to make the community forum more vibrant, more robust. We participate in there, but we're trying to make it this place where it's part of where the customers go to get their answer because it may in some cases result in a faster full resolution time for them. Absolutely. And I think this is something that companies have realized, but I think we're relearning that point, which is especially in complex environments, customers know more than us or partners know more than us. So how do you then move from we know best, we internally, to we, capital we, all of us know best. So we have worked with, for example, a large bank that actually enables using the standard called KCS, a Knowledge Centered Service, a way where external third party can be temporarily licensed to enter in content as if they were level three or the senior most group in support or engineering directly into the KB, bypassing even internal people because they are the experts. So you got the cycle of time to publish and things from weeks, days, to minutes, to seconds. I'm going to have to trust it. I'm going to have to convince our product content experience team to go along with that. They are such wonderful technical writers and they want to make sure that everything Cloudflare puts out is really well done. And I can emphasize, but the developer, I know the developer community, you look at things at GitHub and they want people to make pull requests to update documentation. They want everyone to participate in making sure there's accurate knowledge out there for the rest of the developer community to benefit from. So you have to have this kind of balance. So the beauty is, sorry, Artur, go ahead. I was just going to say, it's tough. It's a full-time job. Our knowledge base used to be a thousand articles and some were one sentence long and some were five pages long. And the product content team and the support team have worked really closely over the past years. It's 400, 450 articles now. They're really well edited and really nicely done and tell the story well. And now we went with KCS, with Knowledge Centered Support. We want to open that up again and have lots of different people touching it and updating it to try and collect this info. And it's hard. We don't want it to balloon up to a thousand articles again that are all random. So then you need good editing and good processes around that. And so I completely sympathize with our product team. It's like, no, we have this great product that we built, the knowledge base and the developer docs, and we have a bunch of different repositories. You're going to come in and start letting customers touch it and mess it up? How do you manage that? So I think there's a very simple way that I tell people to think about that, which is sunlight is the best disinfectant. Every interaction that's happening is often happening without you knowing. Agents are talking to people, customers are talking to other customers, partners are talking to customers. You have no clue what they're saying. You've got no control. So let's not fixate on the tiny proportion of people who actually come directly to you for support and try to control that when the rest of it is the stuff that's below the iceberg. So when you think of it in that perspective, that's why this knowledge-centered service concept says, let's assume that people have a sort of a licensing kind of model. Some people will be allowed like a driver's license. Some people based on experience, skill sets, training will be allowed to put this out, but only certain types of people can view it who are capable of understanding that this may not be fully correct, may not be fully spellchecked, may not be right from a legal point of view, but it's a right of visibility. And other people will not have access to it. So there may be the correct caveats. The second set of things is then as you do it, the other big difference is that it's everybody's job. You're creating a culture. And this is the most fundamental piece, in my opinion, in a knowledge-first world where you're creating an environment where every time anybody touches a piece of information, they're leaving it in a better place for the next person. And it has to be simple, joyful, and in my workflow. So it's not editor's jobs or publishing's jobs to fix everything. If I say, wow, this is good enough, it fit the need it had. Thumbs up. That's already a form of validation for that article. If it needs some tweaks, but I don't have the privileges because of security or whatever to make that change, I can flag it for the right person to fix it. If I have the training and the skills and I've proven I can do it and I have the availability, I can just make the fix. Or I can say, I have no clue, somebody needs to add to it. But that takes that command and control, I know and I will do. So quickly, there's three measures that are interesting, and we'll move into measures in a second. But two are relevant to knowledge. One is something we call level zero solvable that effectively says, make what we have available to the customer in their own words. So that addresses the point you brought up about it's their auto, but customer says, I didn't have a clue that this doc, which I looked at, actually meant what you thought it meant. I couldn't translate it. In two different languages, here's the super technical version and here's the one my mom can read. Right. So the idea is make it available and each time in a simple way so that you bridge that gap. So actually the right people see the right lens and get what they want. So that's level zero solvable. Make what I have available to you in your words. So back to whatever camp you're in. Second one that's really powerful in the knowledge world would be time to publish. If it's not there, how quickly can it be made available? One of our customers went from a very, very well admired, won so many awards in multiple areas, including in knowledge, went from weeks between the frontline in a very complex environment, being able to know the solution to a problem for it to be published for all the reasons that you brought up Shane, right? And you brought up auto. They went down to days, 12 minutes, and then tried to bring it down to within less than a minute. First time seen frontline publishing in defense department. You talk about lives could be lost if something is off. Sunlight is the first disinfectant. Here's a nice, simple process where everybody improves it every time. It's not that you open it up to everybody all the time. You slowly can do it. All these checks and balances are done and that's at KCS methodology. If it's simplified, it's really, really dramatic. So that's the second one. Level zero solvable. Make what we have available in your own words. Second is time to publish. And the third we'll talk about is a time to proficiency, which I'll bring up in a second. So back to the high level piece, change from enforcer to player coach is important because managers have to know how to go from bad boy, bad girl type to this area. Knowledge first we just talked about, why it can help the customer effort, employee effort, and manager effort. Quickly go into the third thing we see customers do across the best people do is really changing measures. So what we did was most organizations try to measure success with metrics that don't align with what you're trying to accomplish. So if you don't know what you're trying to accomplish, whatever you measure is nonsense. We frankly in support measure too much because we can and almost everything we measure doesn't mean anything. It doesn't matter. We just moved from one reporting platform a year ago from one reporting platform to another and there were literally like 5,000 reports in the one platform. And we were trying to figure out which ones we want to move and there was like 100, 200 of them we moved and there were 4,900 of them left behind. My goodness. And that's heads off to you as a leader, right? There's a lot of pressure to keep it just in case, but it's rarely ever needed and it doesn't really matter, right? So we suggest people start with something simple called a guidepost statement. And that's something that, you know, we have mission statements and vision statements. A vision statement is what you want to be when you grow up. A mission statement is how you get there. To us, the guidepost says, I've got no time. I'm completely lost in the middle of the ocean in this robot. What do I do? I don't have any time to think. I'm panicked. I have no time. I have to juggle resources. That's what the guidepost statement should tell you. And every measure you have should be based on helping you succeed against that guidepost statement. That's it. Do you guys have a guidepost statement? Is that something you've thought of? Because very few companies actually do it. Gosh. I mean, for the team as a whole, we look at it as creating customers for life and meeting the customer where they're at. But I don't think that we have a good statement where we're aligning the team around. We haven't condensed it down into one. I like the term North Stars as well, which I think is similar to guideposts, right? You can draw the ancient mariner analogy. How are you going to find your way? You look for the North Star. So I mean, my North Stars tend to be customer experience, employee experience, and business goals, right? So we're making the customer happy, we're making our teammates happy, or we're meeting our business goals. So I'm always trying to keep those three things in mind as my North Stars. Both great points, right? One is, Shane, to what you said, keeping it simple, because you've got to help people decide what to do against, in that example, those three buckets. And Otto, for you, maybe one suggestion would be it's worthwhile polishing this off, especially as you scale, there's more confusion. If you go back to COVID again, an example, such a complex, multi -dimensional, societal, environmental problem. It comes down to masking, distancing. It takes time to get to it, even though we knew in theory what to do. But having that allows you to at least start having a basis for a discussion with other people. And then you can have debates and political debates and all the things that are different, right? But that's what I'm trying to get at. So if you don't know what to do, make it simple. As you scale, I would suggest this is really important. So as you maybe revamp your knowledge piece, that'll be a good thing to start with because it all ties back in together. So we believe a good measurement system should focus attention on just a few things. And that's the example of what you guys have done as well, right? From your 5,000 measures to a few. And so what we found a couple of years ago is that across all the companies we worked with, it was a mess. Measurements were all over the place and we're measuring easy to measure, but not important things. So we created this Open Customer Metrics Framework, which is an open source Creative Commons kind of licensed idea. And this is at a high level what we talk about. We suggest that every support organization should bucket their measurements and their focus on how to do it into five. A customer category, how well are we meeting the needs of customers? And focus percentage says only 20% of your time as a leadership team should be spent on the customer. Like what? We are customer support, customer success. Yes, but it's interdisciplinary, right? Other things matter. Employee, 20% of the time should be spent on as much time on employees as you do on customers. And when you really look at it, lip service is great. You go down two or three levels, you're like, nah. We look at attrition, we look at training, and that's about it. But why? I mean, if we are so important, why not? The business is what you touched on, which is the financials for the most part, throughput, efficiency. Most companies, if you look at it, there's a tool on the site called the ocmfgroup .org site. You can get much more detail completely free. We have licensed it out to be completely open to everybody. You can do a self-assessment and see kind of where your measures are. Most companies, I would say 90% of the effort is between customer and business, as opposed to what we recommend, roughly about 50%. Knowledge and collaboration should be as important as customer-employee for the reasons we mentioned. So this is a pretty big deal and is very, very rarely done. But if you don't start with managers going from enforcers to coaches, if you don't go from case first to knowledge and reinforce this with a new way of measuring, you cannot get to an organization that can think about laying new tracks and keeping things running on time. It's just incompatible. So I could go through a few examples if that's useful for you. Would that be interesting? And some thoughts? Yeah, definitely. I mean, I'm thinking that we always focus on our team, on the employee first. And we always say that you're not going to have a happy customer if the employees aren't happy. And it can show very quickly when you call your cable company and talk to an unhappy person. It makes you unhappy with the company. So as far as the percentages, we probably over -index, hopefully, on employees and customers. Knowledge is, we have way too much knowledge. And that's Shane and I and a lot of KCS champions on our team have really been trying to raise the percentage of focus on knowledge across our team. And we have a bunch of initiatives going on there. Yeah. So go ahead. So I'll just give some philosophies very quickly. Then I want to talk about some of the specific measures. So some of the things as you go from enforcer to player coach would be, which also goes into how you measure properly, would be this concept of going from grading to guiding. Nobody likes to be told bad. Maybe we overcompensate on being told good and get the shiny trophy, but it's the same problem. Grading means it's to somebody else. Guiding is a much longer, much tougher conversation. It depends. Let's have a conversation. And I know, Otto, in all my years of working with you, that has been something that you've been superb at. Many people, as you get more senior, just say, this is good. This is bad. Buzz off. But you've always taken the time. So hats off to you. And I hope Shane sees that in his day-to-day role. But that is rarely done, but critical to grade. That's true. I'm sure I fail at this plenty of times, but we try and go in that direction. Yeah. I like the way you use the word conversation. We want our managers to be coaching and we want them to be able to have conversations with our team members about lots of different things, not just how many tickets they've solved in a day, but how much they contributed to the knowledge and all sorts of the other things. And we think that support engineers don't just want to solve tickets. We think they want to contribute to the team in a variety of ways. And some people in some areas more than others, right? Not everyone is the same. But yeah, we want to create a scorecard. I've heard Otto use the word balanced scorecard, but it's not just hard numbers we're looking at. There's other qualitative things as well that we want to have conversations about and be able to say, hey, you contributed to the team and our business goals in these other meaningful ways. That's a great point. I was going to say one overall way of looking at it that I always say is that I don't really care how many tickets you do per day. I want to see improvement over time. I want you becoming more efficient and more productive in month six than you were in month one. And it doesn't mean 10 tickets, 20 tickets, 30 tickets. That doesn't matter. It just means more productive, more efficient over time. And that's really the guiding, right? You're not beating people up along the journey. They might have issues at home. They might have a difficult customer. Something they do may take them much more effort. So they may not like to do it. So they may be worse at it, but it's conversations. It's like a team again. You're not saying how many at-bats, what's your run rate? Today, you messed up three balls. What's wrong with you? It's like, no, how can we get you better, right? The mode is very different from bad boy, bad girl to this whole conversation, right? The other thing we forget often is that measures are like a tax. Measures are really for the team to do better, not for you to manage the team. That's a subtle but very important difference. Same way, tax means that you're supposed to be getting more good out of it than whatever penalty and overhead you have with that measure. So that's what we need to fix. And this is similar to the guiding, not grading. It's this whole concept of, again, Otto, I've seen you do this. And Shane, I can see you do this in your training from what you've told me. Guidelines. Instead of just saying, here's how to do it, here's how I think it could be done. Otto said this, so this is the only path forward. No, this is the overall direction. How you get there, you'll figure it out or we'll give you guidelines. And here's guardrails, because maybe we have more experience. Maybe we've seen this in three other companies. But it's not, I'm better than you, so I'm telling you to do this or do that. Maybe you'll say, forget the guardrail. I don't care. I'm going to do it this way. I know a shortcut. Otto is old school. Phil's man is so old. He's before Al Gore, so let's forget what he says. Figure it out and then lay your own guidelines and guardrails and share it out. This is such an interesting challenge to solve in so many ways, especially in the training world, where we want to empower people to be able to solve problems and not necessarily be so prescriptive about when you see problem X, you must solve it in method Y. And sometimes people really want that. And so there's really want to be told, like, tell me exactly how to solve this. And we do do that. But we also need to be able to help people learn how to solve problems that we could never anticipate, that we could never have a prescriptive process to solve. What the actual solution is to a given problem, I'll always defer to the support engineer or the team leader, the manager. They're much more in touch with what the best solution might be. And absolutely, I just want to give guidelines. I want people to bring me solutions and explain them. I don't want to prescribe, you need to do it this way. That takes time and you have to hire the right people. You need smart people and confidence to bring that solution and make suggestions. And so it's a training process. You've got to work them up to that or some people come in that way. I'm thinking about our product specialist team. We have a special specialists on our team that are product specialists that were tech support engineers that we have now devoted to helping us create internal and external content on how products work and how to troubleshoot them and help us get prepared for releases. And they partner with the product team to help make the product more supportable, right, and communicate support feedback and customer feedback and how many tickets are we seeing and what features do we need to build up to the support team because we're the eyes and ears of the company. And I'm remembering what one of them was saying is we're having this healthy debate about what the documentation should be that a support engineer needs. And he was very much aligned with what you were showing here, which is that I can't tell them exactly what to do. We're going to say, here's all this information we have, here's some common traps, here's some tools, you know, here's some things to watch out for. And I do agree with that approach. But all this, as you can see, is difficult, right? It's not a simple matter of saying do this or this, which is easier to manage in theory, easier to get reports on for sure. And that's why these three things have to be done together. And they're transformative, but when done together, you could have this solid, simple environment where people want to improve knowledge. You've got to have managers who really understand it's going to take more time short term, but transformational to move to a player coach, not just somebody I tell you to do this and go do it and come back. And then this concept of measures we're talking about. So, and this is all the part of that conversation. So I want to talk quickly about three common sort of measures that we see used. I think we've got eight minutes left. We'll be done in maybe three minutes or four minutes, depends on the conversation and the questions. So customer effort is one we talked about, right? You can measure and I think Otto, you'd ask some good questions, but basically keep track of how much effort does it take? Pay some attention to that because support can impact it. Second one that's important in this new measure is employee effort score. How difficult is it? How much effort does it take for the employee to do this job? So take that same customer workflow we had before and then look back at it and say, great, why do I have to bounce through six steps? Because very often when we make things simple for somebody else, it makes it much more complex internally, especially when you have to scale and go across departments and technologies and countries and partners. Wow. So pay a lot of attention to this and knowledge will help a lot in this customer effort as well, as well as employee effort, right? The third one I want to briefly end on, which I think is really powerful, is this time to proficiency or time to competency, which is most often we only measure people passing an exam as some measure of you're competent or not. What really bleeding edge companies, and I believe we're talking to one of them, have done, which is really cool, is how quickly do you get proficient based on your team telling you you're proficient? That's really the most important measure, right? Does the team trust you to do critical work alone or not? So I know this is something that you guys have talked about. I'd love to hear what you're doing. This is one of the most powerful applications of good knowledge and these concepts we're talking about. I think I'm going to have to incorporate this idea because I've heard it before, but we could be doing more of this as, I guess, peer feedback on your competency. We do measure time to proficiency and we measure how long it takes us for someone to become capable of performing a specific task. That's based on our workflow model, right? Is that working with our enterprise customers who have access to every single product in the Cloudflare suite? Is that actually a certain category? Can you do DNS type tickets up to the most difficult variety of tickets, level three difficulty? We can measure those things and we've created a series of assessments, and you mentioned tests, that assess people's knowledge and we have trainers that evaluate those assessments and give people guidance, like you mentioned, and feedback on whether they have competency in that skill area or not. But I think this is an area where we could grow. I think this is an opportunity, an area of opportunity for us to look into something and evolve how we're thinking about proficiency and how we're thinking about competency. We're aware of it, but I still think there's some opportunity to grow here. Yeah, I do like the peer review side of it. That's a really good idea because I can think of a couple of different support engineers where everyone will turn to them and say, tell us what's going on here, or they'll be the ones who take time to go help train a new person and help them get up to proficiency. So their peers would say they are a level three subject matter expert on this. So I think that's really important. One thing I love too is our labs will have people get a raspberry pie and set up all products on it, and Shane's team will set up broken versions of it. It's like, it's giving me an error. You go fix it. I'm going to watch you fix it. I'm going to watch your thought process while you do it. And you're going to get it wrong the first time, and you're going to learn, and the second time you're going to do it, and now you're proficient. I love that kind of stuff. Yeah, I mean, there are so many components to our training program. I mean, we have labs, we have servers and broken states that we challenge people to debug. We have everyone, and we facilitate that everyone tries nearly every product. Now we mentioned specialization earlier, and now not everyone can try every single product, right? So there's some interesting coordination that we do, but there are so many. We have online trainings that you watch that are interactive as well, so that people are engaged and not just clicking through. We have hands-on trainings with our technical training instructors who are all technical support engineers. But even they have the, you know, our team has a problem of not being able to specialize in everything. So we work with S&Es on the team in different areas to deliver deep dive technical trainings on other things. And we have broken servers, and we have test environments, and we are measuring time efficiency, and it's a multifaceted organization. It's frankly very impressive. And I know you said you feel you've got to improve, but I would certainly take a moment or two to pat yourselves on the back, because I know from experience working, of course, in the early, early days and scaling Akamai massively, how hard this is. And I've worked with a couple of other CDNs as well. It's a very, very tough technology world, right? Supporting people to the level they deserve support. You've done, it sounds like a lot more than many companies. I think with a few tweaks, this idea of working independently, the point is the team kind of knows, do I trust, is Otto the person to pull in, is Janice, is it Usha, whoever it is, is Mohammed, who is the right person to pull in at this time? That's all I need. It's like to Otto's point, it's not every time it has to be this or 95% of the time it should be this person. Is it more often than not they're saying, thank God so-and-so is here to help me. Internally, we are going to play with just very quickly another thing like a plus minus score, like in basketball. That's a score in basketball that says when a person is on the team, is a team doing better or not? That'll be an interesting model to play with within support, but that might get us some way to get this too. And everything we've done in terms of the training and the other things is based on the feedback of the people that have gone through it. So we didn't just come up with stuff out of nowhere. We asked people, how can we get better? And we do that a lot. I mean, and I think that's something Otto's built into the culture is retrospectives, feedback. Please tell us how we're doing, how can we get better? It's like, we need to talk to people doing all the work and doing everything. They have the best insight for us. And I talked to all of our new people and to a person, they all say the training has been amazing. And they've never been at a company where they get such complete training on so many different levels, so many different ways. So I think we're doing a great job there. We really need to next turn to knowledge and get better at using our knowledge. We have literally tens of thousands of pages of info, trying to collect it. And if we can get smarter about that so that we're using Knowledge Center to support with our customers and with all of our employees, we have it all there. It's just finding it, using it at the right time. So that'll be the next. Hey, I want to thank Phil. Before it gets cut off, I want to thank you, Phil. I want to thank you, Otto. Thanks, everyone who tuned into Between Two Clouds. I think we could have you on again, Phil, because it seems like we're only at the tip of the iceberg. So thanks for your time. Thank you, guys. Yes. Yeah. Thanks so much, Phil. That was fantastic. And thanks for coordinating it, Shane. Of course. And enjoy the next Cloudflare TV segment out there, viewers. And tune in again for Between Two Clouds Inside Customer Support. And thanks for joining. Yes. Bye. Take care, Phil. See you, Shane.