I don't like "enablement" as part of the name of a job role or department. That's despite (or maybe because of) having worked for several years in partner enablement roles and having plenty of experience collaborating with colleagues in sales enablement. In the last ten years, enablement as a function has exploded. In 2023, "Sales Enablement Specialist" was the sixth fastest growing job title on LinkedIn. Sales enablement is the most common enablement role, but a quick look at job listings shows a variety of others like technical enablement, operations enablement, revenue enablement, and so on.

As a term, "enablement" invites miscommunication. Stakeholders bring their own set of expectations, informed by their role and needs. Consequently, they experience gaps between those expectations and the enablement services being delivered. Where formal definitions are attempted, they are so broad that they do little to resolve the miscommunication.

Consider Diane Krakora's definition for partner enablement:

"Enablement is the practice of ensuring a partner can independently initiate and complete the sale process AND effectively implement and support the customer solution. It includes both sales and technical aspects."

That definition is so expansive that almost any activity that touches a partner could be considered enablement or at minimum has an associated need to provide enablement. With very minimal changes, it could be applied to the internal sales force (if one includes sales engineers as well as account executives), customer success professionals, and even the customer! Similarly, it provides no guidance regarding who should be responsible for enabling the target audience.

The definition is good in that is focused on action and outcomes - the person being enabled does things like "sell" or "implement". For them to do that, they need more than just training and supporting content. Enablement should be a company wide shared and orchestrated process to provide the necessary conditions (training, supporting content, tools, and coaching) for every person who directly impacts the customer to complete their role specific tasks so that a customer is created, realizes value, and is willing to renew and expand their relationship with the company.

Consequently, it doesn't make sense to speak of enablement as a thing that is "owned" by one group or another. Rather, in order to ensure that the needs of everyone who participates in the customer journey are diagnosed, to eliminate duplication of effort, and to measure the impact of enablement on the customer lifecycle, the process must be intensely collaborative. A centralized enablement group or a tightly allied set of groups with defined responsibilities (which could be audience oriented (i.e., partners, sales, internal) or capability oriented (e.g., training design, technical coaching, tool creation, etc.)) must work together to align the resources of the company and ecosystem to drive the desired results.

There is inherently a performance management aspect to enablement. Production of enablement materials by itself does nothing but create cost. A return on that investment only occurs when a person in the role to whom it is targeted makes use of it and as a result improves their success rate or their efficiency in completing the task that is being enabled. Whether you are talking about a sales manager, a partner manager, or a customer success manager, a necessary step in the enablement process is that they can diagnose the needs of the people whose performance they can influence and direct them to the enablement materials that will drive performance. Similarly, as the front line observers of performance, they should be in the best position to inform the enablement team(s) of the performance gaps they see in the groups for which they are responsible. They can provide the best evidence regarding proper enablement prioritization, both through anecdotal evidence and by ensuring availability of clean data related to performance of the tasks that have been targeted for enablement.

Similarly, enablement drives all the way back into product, engineering, and enterprise technology. Requirements for extensive training or copious documentation are evidence of opportunities to improve user interfaces, clean up APIs, and provide better contextual help in the tool or environment where the worker is performing the task. In many cases, it would be cheaper and more effective to change the process than to invest more in training, creating job aids, and asking managers to beg people to follow the existing process.

So back to the question I posed in the title. Would we be better off if we had a different name for enablement? Maybe. I've thought about this for several years and haven't come up with a different term that isn't equally open to misunderstanding.

Hopefully, I've made the case above that there is much more to enablement than just training and content. Unfortunately, anecdotal evidence suggests that a lot of organizations have relabeled the sales training function but haven't actually empowered them to collaborate with functional leaders in revops, product marketing, and sales management to fulfill an expanded mission. Attempting to solve that by giving direct responsibility to enablement is more likely to create turf wars than to solve problems. The enablement team inherently has to be a trusted partner of those functional leaders, with a clear vision for what everyone is to accomplish coming from a top-level leader like the chief revenue officer, chief customer officer, or chief operating officer. I've seen the best results when leadership and key roles in the enablement function have previously worked in one of the functions that they are serving rather than coming from a pure learning or education background.

‍