The enablement team plays a key role in the initial and ongoing success of employees. When training is set up properly, the company starts receiving value from the new employee much sooner.

So what are the key factors that have directly affect how quickly and efficiently new team members get onboarded? For a first-person account, we decided to speak with Adler Chan, the head of the Customer Enablement team at Wrike.

Artem: So first tell me about the role of the enablement team in the organization’s success in general. I’ll just tell you my opinion — please correct me if I’m wrong. I think there are 2 main goals here: to enable new team members and to educate existing if the need arises. Am I correct?

Adler: In brief, yes. In practicality, there’s a lot that goes on with enablement. And that word “enablement” has a couple of meanings: a noun, as in a team focused on enablement, and the function of “enabling,” which is a verb. The verb is actually much more generic. A lot of people use it in a lot of different ways. It’s synonymous with “training.” But really enablement, at least from my experience, is more than just training. It’s also coaching, documentation, sometimes facilitation, process improvement, process understanding — because you have to understand the process to be able to teach it.

And on top of all that, just contextually being able to connect the dots. So, if it’s Sales to Customer Success and Professional Services, you need to be able to understand and teach the two sides to that. You can teach Sales, “Hey, this is what you need from a PS/CS side.” And, CS/PS, “This is what you need from the Sales side.” Oftentimes people are very myopic and kind of only focused on what they need to do.

So the role of enablement (the noun) is — from my understanding — to be part of the glue, Enablement is a connector between teams. You not only enable the people to do what they need to do, but you also act as the squishy middle between the dots. And that’s usually really dependant on the organization — how effective the enablement team is. If it’s not very effective, they’re going to be relegated to pretty much just onboarding and training.

And, in fact, enablement teams oftentimes are in the HR department like L&D (learning and development). And most of the training and enablement happens there because HR, as of kind of general function, is often the glue in between departments.

When you talk about functional enablement, specifically Sales and Client Success, it is enablement from the functional-specific perspective of that gluey middle. So the person responsible for Sales enablement is going to look at all the stuff that touches Sales from a Sales lens and will want to make sure that the Sales team is enabled to work with all the other people.

For me, I’m going to look at all the teams that we, the Client Success Organization, deal with and teach them how to work with us from a CSO perspective. It works really well when Sales Enablement and CSO Enablement get together and collaborate: “So hey, what’s the best way to get our teams talking?” And understanding each other so they can do things.

Whenever you’re talking about enablement, it’s really fostering the capabilities of an individual in their role and connected to the role.

Artem: So the next question is very short: How many folks are currently a part of the enablement team, and how long has the enablement team in its current state existed in Wrike?

Adler: We utilize the divide and conquer approach — we layer advanced (function-specific) training on top of basic (product) training and currently have 3 enablement teams working together focused on each of those areas: Product, Client Success, and Sales. There are 9 people across all functional areas. We’ve been consolidating product training since 2014 and functional training layered on it since late 2017. Before our (enablement) teams, every manager was onboarding their new recruits however they wanted. It wasn’t consistent and it wasn’t comprehensive.

Artem: What would you call the 3 main challenges that stand before your team? You can name 2, or maybe even you have 1 super-main challenge. Because I know the 1 that we have been continuously discussing — with different offices and different time zones, how do you interact and gather everyone involved? Maybe you don’t consider this the main challenge.

Adler: The hardest thing from an enablement perspective is really to keep the car running while making new cars. Does that make sense?

Artem: Yeah.

Adler: Because especially with our product, it doesn’t stop developing, which means the training and stuff need to happen constantly. But then there are new people coming at the same time we’re training existing staff, and we have to make sure that the newcomers are up to speed as well. Balancing current training and new training is probably one of the biggest challenges — to make sure that everybody is up to date.

The second challenge, I would think, is not only to maintain all the input of information but also maintain the quality. Just because we develop and deliver training doesn’t mean that it’s effective or that people are putting what they learn into practice. So part of enablement is also making sure that what we teach is effective and people are executing it. That’s how we make sure that we have a world-class team.

A part of that is ongoing checks with either direct managers or even peers. And a part of that is spot-checking from a training perspective how are they doing. I will check in with PS consultants and CSMs even after they are out of training, because I feel responsible for them, and if they screw up, that’s a reflection of my onboarding as well.

Artem: Yeah, that actually takes to the next question. So how do you measure if a team member has been enabled successfully, and what are the metrics for your team?

Adler: A lot of it is qualitative, and one of it is quantitative. I evaluate the ability of a trainee to execute a given task. The rubric on which I grade them is: First of all, did they get the job done? Did they cover in the call or whatever it is everything that I expected them to? This is more or less quantitative — a scoring system of pass/fail. Secondly, how well did they do? What were their wins and opportunities to improve?

And the qualitative part helps me communicate with the functional managers' areas of strengths and improvement. Let’s take one of our recent trainees who just finished, for example. She is a really strong deployment consultant, but I see that there are some areas that she can still refine, specifically with the product and the polish of her delivery. How she juggles technology and areas like that.

I pass that assessment on to the managers, and it’s up to them to kind of come through and work with her on those areas, so that she can continue to operate on a high level.

Artem: Alright. Can you briefly describe how the enablement process is organized? Are the stages always the same or can they vary from role to role?

Adler: It depends. The enablement process is pretty broad, so I’d break it up into onboarding and ongoing. The process for ongoing oftentimes comes like this — Product or PMM or someone will come to me and say we have something we need to train CSO on. And depending on this, I would sit down with them and figure out the scope. How big is this, how much time do you need, who needs to be on the calls — all the logistic stuff. And at that point in time, I will make a call to say what’s the best way to do this.

If it’s a simple update, maybe it’s better to combine it with another meeting. If it’s a kind of long thing, maybe we need to book a specific time and that would require a much longer time frame because we want to make sure everybody can attend. Or maybe one of these things just needs to be an update in Guru or something like that — some sort of documentation and we will push it forward. So we kinda discuss it with the people who’re either requesting or asking for help and figure out what the best medium is and then we will just execute.

Onboarding is a lot more complex because it starts with an interview and hiring process. We need to know when people are coming in so we can kind of get ready for them. Onboarding has two major components — product training and functional training. Product training everybody gets, regardless of who you are. It’s a little bit different with product training. With Sales, it’s much simpler. Marketing gets a little bit more complex but still not very complex depth of product. CSO gets probably one of the most complex, and then Customer Support is even deeper because they have to troubleshoot.

So depending on the role, the training will have a different level of depth of knowledge and on top of that, there is functional knowledge. So for Support, you need to know how to answer email, you need to answer Zendesk tickets, you need to be able to talk on the phone, you need to be able to troubleshoot those things. For CS, you need to be able to do EBR/ABR, health checks, demos, and really talk to customers about retention and growth. For PS, it’s the deployment process. Then we can go into the individual functions to be able to say, “OK, that’s how we train.” And depending on the role, it would determine the curricula that was developed by me and my team, alongside the managers.

Artem: Yeah, all right. That’s pretty clear. The current process of enablement, according to a lot of feedback from my colleagues, has a good structure and is well organized. So from your perspective, how many iterations did it take to reach the current level of quality?

Adler: Just like Wrike, it’s always changing. It’s never-ending. I’m still making edits to it as we speak. And if you think that it can ever be done, you’re in a bad place, because as the business changes, your onboarding and training have to change. It needs to meet the requirements of the next step, not the current step. If you’re training for what is right now and you’re not looking ahead to what is coming, you’re already behind.

So actually I’m in talks with Product to understand when they are going to release something a little bit earlier because I need to know before the rest of the people know. Otherwise, how am I going to train them? I hate to tell you, but there is no iteration number because it just keeps going. The goal is to set up a structure that works. I would probably do the 80/20 rule. It’s probably good, and then based on it, keep iterating, keep evaluating. And one other thing I do pretty consistently is I get feedback during the onboarding and after the onboarding, and then also every once in a while, I’ll hit up people who’ve been onboarded for a while and say, “Hey, now that you’re fully wrapped, what do you think about the onboarding process?”

So, kind of in progress, just after and then long after, and taking their feedback and saying, “Look.” Looking at it quantitatively, what’s good here, what is valid and not just personal preference. What is common? And then let’s take that and move forward, apply those changes to the front end so that people get a much better experience

I would say that people that I’m onboarding now probably have a much better experience than people that I’ve onboarded 6 months ago vs. 9 months ago. And I would think that the people that I’ll get to onboard in 3 months from now are also going to get an even better experience. And the goal is as I’m making it better on the front end as they come in, I’m also working on the people that didn’t get the niceness.

Artem: Just keep up to a certain level.

Adler: Yeah, and that’s why it’s never going to end, which I guess is good cause it’s job security. But it’s also bad because it’s never going to end. You need to know that this isn’t a project that you’ll finish. These processes need to keep going, otherwise what happens with a lot of e-learning and learning and development teams is that information grows stale. And then they have to go back and redo it, which takes even more time, effort, and resources.

If you keep doing it and it’s always in a state of improvement, then you’ll never have to take the time to stop and go back and fix what’s broken. If you have the mentality that it’s always broken, it’s always incomplete, you’re always tweaking and fixing and improving. That’s my personal take on it. I’m pretty sure that other people have different takes on it. But that’s kind of how we keep a world-class status.

Artem: This question might seem a little bit weird, but still… Is there a backup plan if something goes wrong? For example, if you or your teammates feel that a certain team member needs some more time to process the materials and understand the product?

Adler: Yep, absolutely. You should almost always start up with the backup plan. You shouldn’t start with plan A. You should actually start with a plan B, because if you plan for the worst-case scenario, then creating plans for other scenarios is going to be easy. So, yes, there is a contingency plan if people don’t do so well in training. Basically, the contingency plan is staged at different touchpoints.

The first contingency is after product training, and there is actually a report card that product trainers give to me to say how this candidate did. If the candidate doesn’t pass, we send them through another round of product training. Probably not the full curricula, but they have more time with the trainer, which will delay the functional training so that a trainee can catch up. If you don’t have a good foundation of the product, you’re going fail in the back when clients ask, “How do I do XYZ?” “Oh, I don’t know.” Oh, well, you should’ve learned product better. So, that’s the first stage.

The second stage is really in the functional training, where we take them through mock scenarios. It used to be 4 different rounds of mocks that everyone went through. Now it’s 2, but again with contingencies — if you don’t pass the first mock, you have to do another and another till you get it right. In the final mock, I try to make it as challenging as possible to finish the mock easily and throw every sort of real life (past) difficulties all into one.

Artem: It sounds challenging.

Adler: Oh, yeah. And it should be. The reason why I do that is…there is a quote that I think Norman Schwarzkopf, a general in the U.S. military, said. He quoted Napoleon I think. But basically, “The more you sweat in peace, the less you bleed in war.”

That’s not saying that we’re going to battle with our clients, because it’s not the case. But if I can throw near-impossible challenges at our trainees and prepare them for the absolute worst-case nightmare scenario and they can get through it, then any trouble a customer who they deal with in the field has is going to be easy.

My goal is that they get off the really difficult client call and are like, “Wooh! That was rough but it wasn’t rough as rough the advanced mock!” That’s kind of where I think training should be. Because that way it gives the trainee the confidence to step into any situation and be able to say, “I got this. I trained for this. We went through boot camp. I’m ready for this”.

That gives them the confidence to do what they need to do, and it gives the clients the confidence because these guys come in and are like, “Yeah I can take care of you. I got this and here is why I got this: You never have to go through Wrike training.” If we challenge them in the training, when they get into real life, they are ready for anything.

So that’s another checkpoint. The backup plan is absolutely important, so if they don’t pass the beginner mock, we send them through another time. If they don’t pass the advance mock, we send them through another time until we get to the point where we could be like, “I trust that you can go and handle a client. Now go and handle a client.”

Artem: And the last one. It’s more from my experience. I have encountered a lot of companies and even worked in some that don’t have an enablement team. They don’t have a training team. They just provide the list of things newbies should learn by themselves. In your opinion, what are the negative consequences of this approach?

Adler: There are pros and cons to that approach, so it’s not all negative. Pros: For people who are hungry, you speed up their onboarding time quick. You can just throw the dictionary at them and then say, “Hey, know the dictionary.” People who are hungry, they’ll take that content and read the dictionary within the week and they are ready to go. Cons: For most other people, though, you have a wide range of outputs from training because different people learn different ways.

So you can’t expect that one person who is really hungry and really book-savvy and someone who is not so hungry but is really good at client management…you can’t compare them on the same scale because they’re coming out of training completely different. What companies do with learning teams and training teams, or even enablement teams, is to take the understanding that everybody coming in is different and put them through a regiment so that everybody going out is going to be the same or the output that they do is the same.

The way we do this is we adapt our training to be learner-centric. Rather than giving you a dictionary, we’re giving you a textbook. Then you can read this textbook from cover to cover and you’ll know everything in the dictionary, but it’s tailored to be more learner-centric. If I’m a reader, I can read a lot of stuff and go through the curriculum and have what I need. If I’m not a good reader and I need some help, we still have some trainers that help coach you through that. Everybody who comes in, no matter your background, the output will be the same. You’ll be a Wrike Consultant or Wrike CSM or Wrike Support agent who’ll be able to handle everything that life throws at you.

The cost is that you need resources — people who understand how to develop learner-centric content, people who actually can do the training, people who can actually build the e-learning. You actually need people who will sit down and understand the process from start to finish. That’s not easy. And I think that’s why a lot of companies don’t have that because they’re just like, “Hey, we just have what we have. Go and figure it out.” And the goal is by investing in the front end, we get a lot of efficiency on the back end.

Traditionally (for organizations without proper L&D/training), people would have a week or 2 or whatever of reading then get thrown into the wild to do their jobs. If they encounter a situation they are not prepared for, they would have to slow down and figure out the process before they go on. However, if we’ve done the due diligence ahead of time and prepared them for pretty much anything, they won’t have to stop and slow down and figure it out. When approached with different situations, they will have already figured that out during training. So it depends on resources and how you want to approach it.

For us in a growth mindset, it makes a lot more sense to invest in training and enablement, because it’s scalable. Our methodology of training is to not only to teach them what they need to know, but teach them how to think, so they can figure out problems that we didn’t train them to handle.

Artem: Yeah, totally. Well, that’s everything I had, and that was very insightful.

Key factors of a Successful Team Enablement