How We Train Technical Support Engineers
Presented by: Shane Ossa, Jamie Ede
Originally aired on February 25, 2021 @ 9:00 AM - 9:30 AM EST
A recurring segment on the topic of technical training at Cloudflare, hosted by the CSUP Technical Training Program Manager, Shane Ossa.
English
Technical Support
Training
Transcript (Beta)
Hello, welcome to how we train tech support engineers at Cloudflare, the Cloudflare TV segment.
My name is Shane Ossa. I'm the technical training program manager for the customer support team at Cloudflare.
I've been at Cloudflare about three and a half years.
It's been an amazing journey and we've built an amazing program to train tech support engineers and today I have with me Jamie Ede who's one of our amazing technical trainers.
Hi everyone. I was a technical support engineer for two years in the London office and then I took up this role as technical trainer to help with the CSUP training.
And I'm very lucky to have you Jamie.
It helps a lot to have someone who did the role for several years and who is an amazing tech support engineer and it just really helps to have someone with that depth of experience in the actual role.
We're going to talk today about our training program, about technical training in general at Cloudflare or anywhere else.
So if you have questions, if you have comments, if you would like us to talk about a particular subject to do technical training then send in questions.
If you look down below there's a little email somewhere down here and you can email in and we'll keep our eyes out for your questions.
We love that we like to answer your questions and and have conversations based on what you out there want to hear.
But otherwise we're just going to talk about the training we have, the training we give, the training we developed and also our amazing team and how it all works.
So just to start we want to talk about a little bit just to start like how we train people at Cloudflare customer support.
We have a lot of different ways of training people.
We have in-person, well it used to be in person, but we have what you might call hands-on trainings and we can take sort of a sidetrack down how we've had to adapt to everyone going remote and it is a little bit harder and there are a few challenges but we've been able to make it work.
But we have hands-on trainings which is one-on-one or maybe one-to-groups where Jamie will actually give people trainings on specific topics.
And then we also have a lot of e-learnings, what we call e -learnings.
These are pre-recorded trainings that people watch beforehand. We try to make them interactive and they have sort of learning checks at the end, you know your standard sort of quiz at the end, an assessment at the end, just to make sure that you didn't click through.
And we have what we do called shadow sessions.
This is on-the-job training where you're actually watching someone do tech support at Cloudflare, do it, and they share their screen and they talk through it.
And then we give people training time, time boxes, and we help them prioritize what they're going to use this time for and some of the things they need to use that time for is doing a lot of the reading that is required at Cloudflare.
We have a ton of documentation which is great and you need to review it. And we've curated the list for people and we've also written some sort of refined versions of some of the documentation with just what you need to know as a tech support engineer.
And so we sort of give people a massive checklist actually at the start.
Jamie, do you want to talk a little bit about our checklist? Yeah, so when you start as a technical support engineer during one of our first meetings, we give you this checklist.
It's like your main focus for your first, let's say, month or two where you go over the different subject matters like the main core subjects we do like DNS, SSL, how HTTP works, etc.
And then you have sections where it shows you the in-person training next to it and then the prerequisite like e-learnings as well.
So it all ties together like our whole program. Everything complements everything, right?
There's nothing exists on its own entity. Everything helps in its own way to make the whole program work.
So yeah. Yeah, and the checklist helps, you know, the person, the trainee, the tech support engineer who's learning to do the job.
It helps them kind of know what's expected of them, know what we expect them to know and where to go learn that thing.
And we've broken it down into like a sequential order, week one, week two, week three.
And we've broken it down by subject, like Jamie mentioned, by DNS, by SSL, by HTTP.
And we go through that in order what you might call a sequence of instruction and they check it off.
And we help them check off items and we kind of check in to make sure they're making the right amount of progress as expected.
And they just kind of use that as their main guide.
That's not the only checklist we have. We love checklists.
But that is sort of the main one we kind of start with. And it's sort of the center of the onboarding program.
It links out to places, documents you need to read.
It links out to e-learnings you need to watch. And it links out to trainings that Jamie is going to give you.
And basically, you're just using this as a guide.
Once you've completed that, then we feel pretty confident that you sort of have the basics down.
It also has links to your actual customer support issues that you've worked on, which we call tickets.
We use a ticketing system. Most support teams do at this type of scale.
And customers write in to us with their questions and their issues and whatnot and their problems.
And we use a ticket to correspond.
And that helps us a lot. And so basically, we can go back and also QA people and see how they're doing and give them immediate feedback on how they responded to a customer.
Hey, that looked really good. I would have said this a little bit differently, but otherwise perfect.
Or hey, that looked really good. Did you know that you could have pulled those logs from this other tool?
And it would have looked like this.
So kind of doing ticket QA. And we work side by side. And we actually do tickets with people a lot throughout the whole thing.
So it's not like we're not doing that and then having them do it.
But in addition to doing tickets with people at the start, we have them do them by themselves.
And we give them immediate QA.
So that's another big component of it. So that's really important.
Like once you've had the theory, right, you've had the in-person training with me where we do hands-on stuff with things that are in broken states.
That still isn't true to the nature of the job, right? Because the tickets are from real customers.
So when you start running into the queues, you will then start to really learn and focus your energies onto the theory that you've learned with me and in the e-learnings you've done previously and the shadow sessions you've had in the previous weeks.
Yeah, that's right. So I like how you mentioned that.
It's like we were giving you a lot of this theory at the start. You're reading these documents.
You're watching these e-learnings. Jamie's giving you a training on how HTTP works and how we can curl and how there's other ways to sort of, you know, test requests.
And then you're going to have to apply that knowledge to real customer issues.
And real customers' issues can be about anything.
And so, yeah. And Jamie and the team have started to really build a lot of what we're calling debug servers or issue reproduction servers.
And everyone actually has to have their own Cloudflare account, of course, their own web servers to use for troubleshooting, for reproducing issues, for just testing and playing with Cloudflare products.
But what Jamie started to build is a suite, if you will, or a platform of a bunch of servers in various states of misconfiguration, if you will.
And then we task people with debugging them. And we do this at specific points in the training.
So we give them that real life experience that's not really just a simulation, that's actually a customer issue that's exactly the same as what a real customer is going to write in about.
And just like Jamie mentioned, it gives people the real life experience.
And that's a big part of what we're trying to do is when you actually start to help a customer, that you're equipped with the tools that you need to solve that kind of problem, to solve any problem, right?
One of our challenges is teaching people more abstract processes.
How do I go about troubleshooting this?
Where would I look for this information? What tools would I use?
Who should I ask for help? Rather than we're teaching you these things you need to just memorize and you're just going to regurgitate them back to the customer.
That's not really going to work. That never works. No, because of how complex people's setups can be, and each customer is using different servers to talk to Cloudflare, using different frameworks on their websites, using different anything.
So it just causes – you need to have the technical knowledge and technical ability to take what you've learned and repurpose it for this customer, even if it's not exactly what you've been taught.
You know the theory of what it should be doing, so you should be able to use your terminal skills and the tools we have at Cloudflare to work out where the issue lies.
Is it Cloudflare? Is it the origin?
Could we give the customer some advice? That kind of thing. It's a really great technical role, and yes, we do not regurgitate things to customers.
When there's something wrong, we will try and help them as much as you can.
Plan depending.
If you're a free customer, we're not going to spend as much time with you as our own customers.
It doesn't work like that. We can't. There's no way. So we do try our best for every plan level to help you as much as we can.
That's how it works.
That's right. Jimmy, can you talk a little bit about what you think it would help someone?
If someone was out there watching going, I would like to be a tech support engineer at Cloudflare.
It seems like they have a training program that would help me learn this job.
What would you recommend they do to prepare that would help us and you turn them into a good tech support engineer?
What could they do to prepare?
Number one, play with Cloudflare. We have a free plan. Just put a web entity on it, even if you're not sure what you're doing.
You can look up free domains and then get some cheap hosting and just try and understand us.
If we see that you've spent that time and you have learned something and you're understanding it before you even get through the door, that helps a lot with us seeing that you are able to learn.
Number two is, are you able to learn? We look for effort and the ability to learn.
If you've got them two, you're more than likely going to get through the door.
You just need to show that. You have to prove it right.
There's a lot of things you can do. One suggestion is just a WordPress website.
They're easy to put up and you can use all of our free features on there and learn a lot about Cloudflare just via our free plan.
That's right. Bonus points, I would say, is if you got a server from somewhere like GCP or DigitalOcean or any of the other cloud storage services that are out there, which are fairly affordable as well.
We're talking about five bucks or something. This is like the cost of a cup of coffee or something.
If you live in San Francisco, maybe it's half a cup of coffee, like me.
For that, you get a web server and then there are easy ways to install a web server, like one click already installed.
What I would suggest is you actually go through the experience of installing Apache or Nginx or one of the other common web servers that are out there and get that going yourself and then put that behind Cloudflare.
That would really help. You don't have to have done this at all.
Jamie and I and the rest of the team, the training team, are going to train you regardless, but that would really help a lot if you did that.
In doing that, the experience would be you would need to be following some documentation, the documentation that's provided by the service you're using.
Let's say it was DigitalOcean and they explain, oh, this is how you install an Apache web server on DigitalOcean and you need to follow those instructions.
Then if you got stuck, you'd be googling or searching on the web for how do I do this?
How do I get unstuck here?
That's a lot of what we're doing in tech support, is we're looking how do you get unstuck and what have other people done?
Just going through that experience yourself of reading technical support documentation and following it would be great, something to recommend.
Can you talk, Jamie, about what about people who have less experience on the command line?
What are some tips for people if you would give people starting out with Linux?
Before I had joined Cloudflare, I had hardly used CURL.
I'd run it to download a couple of things or test some things extremely rarely, maybe five times in my life before I joined Cloudflare.
Wget is easier, right?
Yeah, that's what I used to use just to download things to the server.
A tip for the terminal, what Shane said already about installing web servers and learning that stuff or just following something.
Have a goal in mind. There's no point in me saying do this, do that.
You yourself need to have a project or an aim or a goal.
Let's say, I don't know, you buy a Raspberry Pi and you want to put an air quality sensor in your house.
Start there. There's projects online where you can learn the terminal commands for that and get the stuff together.
Have a project in mind and learn the terminal for something you want to create and you want to learn, you want to enjoy.
Yeah, follow the instructions that are out there. You'd be surprised.
Some of the most advanced and experienced tech support engineers and programmers are looking stuff up online as to how to do it and following instructions.
Exactly.
We have built a robust program. Let's talk a little bit more about that. I like to break it down and simplify it a little bit when I describe it to people.
We give a lot of different trainings.
Earlier, I described how we give them, but what do we train on?
If you really simplified it, you could categorize everything we train on to these four main categories.
That is Cloudflare products and features.
How do Cloudflare products and features work? We do a lot of training on that.
We train on the tools, the troubleshooting tools we use. We use some open source third-party tools, but most of the tools we use are in-house proprietary tools that we've built at Cloudflare.
We need to train people on how to use them and other tools that are like command line tools that everyone could go and learn like curl and other things.
There's tools. That's another big bucket. Another one is processes or policies.
We have very specific ways of doing certain things or we have policies about, say, when a customer writes in that we have to authenticate them and identify them in a certain way.
This is a security company after all.
That's just an example. That's another big category is policy and process.
Then the fourth big category is just concepts or subjects or technologies. This is how DNS works, how SSL works, how TCP works, and all the other acronyms and protocols and things that are out there.
We do train people on those things. All the training we give can be thought of as either being a tool, a process, a product, or a technology or concept, if you will.
Beyond that, that's very broad.
We have more specific things that we train on, like specific Cloudflare products.
Argo tunnel, how does that work and how would you debug it?
Where are the logs? How do you pull the logs? We train on tools that we've built, as well, like Crossbow, which is an internal troubleshooting tool that allows our tech support engineers to connect to servers from Cloudflare servers around the world, rather than just trying to connect from your client, from wherever you're sitting as a tech support engineer.
Well, I actually want to test this server from Frankfurt.
Crossbow allows us to do that. We need to show people how to do that and stuff like that.
What do you think is worth mentioning here? Do you think it's challenging to train on or challenging for people to learn or easy for people to learn?
I'd say different learning styles is a challenge because not everyone learns the same.
You always have to try and, early on, see who they are, work out how much they know already, how quickly they can pick up a new technology and adjust your training to that.
If you've got multiple people at different skill levels in the same trainings, then that's where you need to tailor it.
Over the time I've done this role, I have learned to notice the cues and assist people in different ways and make it easier for everyone to be on the same page by having these environments and wikis that explain how things work in more of a TLDR along with the detailed explanation below, so then people can understand the concept and then understand how it works.
So, yeah, a roundabout way of answering your question.
That's great. That's a great point. I'm glad you brought that up because everyone's different.
Everyone learns differently and a big challenge for us as trainers is to cater our instruction to each person's individual needs.
Some people really love the e-learnings and they just want to watch all the e -learnings, right?
I don't need as much time with you. Let me just read all the things.
Some people are readers and some people don't want to read that much and don't want to watch the e-learnings.
They just want one-on-one time with you. Show me how to use Crossbow.
Show me how I can pull the logs on this one product. Then some people are like, I actually want to watch somebody do this job, right?
So, that's why we have the shadow sessions on the job training.
I just want to watch Jamie do tickets and just see what he does and just sit there and observe.
There's all the things in between that.
We need to cater to each person's individual needs in that way.
Yeah, it does make it challenging when we start a lot of people at once, right?
At this point, the size of our training team, we don't have a one-to -one ratio with every new person that starts, right?
So, when we have five people start, Jamie's got five people in a video meeting and he's explaining how to troubleshoot this one type of issue.
Yeah, remote has changed this a ton, right? As a trainer.
So, before COVID, it was so much easier to gauge people. Body language. Are they understanding you?
Just looking at the screen, helping them. When you're all in a call, you have to keep switching screen shares and all that jazz just to try and get everyone on the same page.
It is a lot more difficult, but adjustments, expect change, et cetera.
So, it's going well. Yeah, I think it's doable and I think we have had several people start since we've all gone 100% remote.
Those people, hats off to the work that you've done as a trainer and to the work that they've done to learn and become proficient with these tools and whatnot because it's not easy, but you get people to do it and they've become successful tech support engineers at Cloudflare that now everyone relies on and that, you know, are doing a great job.
So, we know that this is possible. What I've found is a big challenge is the sort of casual, informal knowledge sharing that kind of occurs all the time when people are in the same room with each other.
You just say, hey Jamie, have you ever seen this kind of issue?
Oh yeah, this is what you need to do and you just kind of, or you can roll your chair over and let me show you something cool, right?
That's what we're sort of lacking now. We try to reproduce that. We have a couple of ways.
We have a sort of open video meeting that everyone, the whole team is sort of kind of coming in and out of all day.
We do these sort of smaller groups for new people for a while where they can kind of come and we rotate.
It's not just Jamie.
Other people, some of our managers, some of our senior people will staff it.
Oh, I've got a little visitor here.
It's my daughter. And some people, so, you know, it's just hard to reproduce what we had when we were all in the office at the same time.
Yeah, it does make it very, very difficult. Yeah, we do our best. So, one of the things we also do is review people's tickets, right?
And, you know, when they're early on, it's really great to look at their early tickets to see what small, you know, soft skills they need slight improvements on or slight knowledge gaps early on are great to find.
So, we try and do that as early as possible so then we can help them.
But then we know that they're learning and we know that they're getting it and they're enjoying their job, right?
We want to make sure all of our technical support engineers are enjoying their role, are helping our customers, and yeah, are happy everyone.
Yeah, so that's, I mean, we might call it ticket QA.
So, we do a decent amount of ticket QA as trainers. The managers do ticket QA of the people as well and just because before, you know, we were all in the same room and so now we sort of really have to schedule all these kind of events.
Other things we do, I can mention some stuff on our list that are pretty fun.
We've also mentioned our test servers to debug that we have everyone install and try out pretty much every single Cloudflare product over time so that they can get the customer experience so that they can have a reproduction environment if they have a real customer issue that they need to reproduce that issue they have an actual Cloudflare account in the server.
We help them build all of that over time.
We certainly can't do everything in the first week so it is sort of a longer progression.
Other things we do are what you might call micro learning opportunities, knowledge shares, lunch and learns type of things.
We do a monthly knowledge share in every region and we do lunch and learns periodically kind of ad hoc.
We used to do a lot more when we were in the office together but knowledge shares are really useful because yes, we have this kind of program that's well structured and charted out and Jamie's giving you trainings on specific things and we mentioned earlier how we're not all in the same office now so just that kind of casual knowledge sharing is harder but even when we were, we had monthly knowledge shares and we invite everyone on the team to present or to just mention something.
It doesn't have to be a fancy presentation. It could just be you saying I found this great browser extension that's really helped me out in these type of problems or I wrote this script or I created this alias because I kept having to anything that you find and that you can share because what we found is we have people from all over the world on our team and from all walks of life, from all, you know, with different amounts of experience in their careers, with different specialties before they came to Cloudflare and we can really benefit from all that.
Not all of the knowledge just comes from the managers and the trainers down to everyone else.
It comes from each other to everyone else and so part of our job is to sort of facilitate that.
Document that, right? Most of the knowledge comes from these people's experiences like our own documentation wouldn't exist without actual experience of X issue or actual experience of said technology unless it's a policy, right?
A policy can be written but knowledge can only be, you know, curated.
That's a great point. One other thing is like learning never ends because Cloudflare, we have so many products we're releasing all the time.
These new innovations, these new products. So as a training team and as a technical support group, we are always having to learn these new technologies as and when we release them, try and get ready to support the customers, play with them.
So this continuous training and learning throughout being a TSE technical support engineer at Cloudflare.
Yeah, that's a big part of it.
That's another thing we sort of screen for is curiosity, right? We really are looking for people who are curious, who like to know how things work, who want to keep learning more because Cloudflare has like a really broad spectrum of products and technologies and we're innovating new things all the time and so yeah, we're constantly being kept on our toes as trainers and as tech support engineers and as a team in general learning new products that are being released, learning new tools that are being developed and so yeah, that's true and that's a big challenge for us but it's also what makes it really fun at the same time.
We're always trying to improve the program. We're always asking people for feedback.
The standard practice is to sort of administer a survey at the end of a training but we take it a step further.
We do assessments, knowledge checks. We also do a lot of QA to see if people are applying the skills that we've taught them but we're also just asking for a lot of raw feedback.
Each time someone goes through our training program, we learn from it and we get better and we ask them, you know, what could have been better?
You know, was there anything that was out of sequence?
Was there anything missing? And we ask people actually later on because sometimes they don't really realize straight away.
We ask them a few months on and we say, now that you've been doing this a while, what were we missing back at the start, right?
You don't really know the questions. You don't really have that perspective at the start but later on you do and so each time someone goes through it, we tweak the program.
We make it a little bit better. We add a little more to this course.
We take a little away from that course. Maybe we put this one in that order and we change the sequence and instruction so we're sort of constantly adapting, evaluating, and adapting ourselves and that's really important.
Our team setup is we have a technical trainer in each region.
Jamie's the U.S. trainer, although he's British and he moved over from England about a year ago, was it?
November, I think.
Almost exactly a year ago and but now we have a trainer based in Europe, in England, and we have a trainer in Asia-Pacific region in Singapore, which is where one of our big hubs is.
We also have an LMS administrator who also does a lot of our e-learning development.
As a really important member of the team, we have over 100 e-learnings and some of them are required and some of them are optional and supplemental, but he helps build them and develop them.
He's really great at that and he also helps us make sure everyone is completing them if they're required and they're completing them.
So that's sort of our team as it is now. The whole support team is about 100 people almost, so that's the sort of ratio we have right now.
We'll be looking to grow. The whole company is growing. The team is growing.
We're hoping to grow our training team as well. We've got like one minute left.
Is there anything more we could say, do you think? Well, yeah, it's been fun to talk about training with you again, Jamie.
We do this every now and then. I mean, we talk all the time.
Yeah, it's great.
I could talk about training all day, the training that we have and also just general training philosophies and strategies.
Yeah, we could go on for hours about certain topics or best ways to engage certain types of people or subjects.
It's a huge, huge area of learning. Yeah, and it's really fun. So if you're out there and you're interested in tech support engineering at Cloudflare, sign up.
We're hiring especially multilingual people because we're a global company now.
So click apply in any of the places that we're hiring people and especially if you speak other languages, if you'd like to help people and help fix computers, we'll show you how to do it.
We'll show you how to become a tech support engineer at Cloudflare.
Okay. Well, this is Shane Ossa signing off another segment.
See you later.