Undercurrents surfaces insights from leaders driving capacity-building
and performance improvement beyond traditional L&D
to explore where learning happens and where it’s headed.
By Mark Britz
Paul Liberatore began his career where you might expect a learning professional to begin: He studied instructional design, learned the models, understood the importance of analysis, and spent years developing training. He was doing sales training early in his career, building curricula around new products and working with subject matter experts to determine what people needed to know.
His view of performance began to widen when he joined a process engineering team organized around three interconnected elements: people, process, and tools. Paul focused on the people side, working alongside colleagues responsible for the other two. The arrangement exposed something that seems obvious once you see it but can be remarkably easy for learning professionals to miss: What someone knows is only one of several things determining whether they can perform.
“There are several pillars that a person’s performance is built on besides just what they know … components that go into a person’s ability to perform, a person’s success—a department’s success,” Paul told me.
That realization eventually carried him from instructional design and sales training into sales enablement and later revenue enablement. But the interesting part of Paul’s story isn’t really the career transition—it’s what he had to let go of along the way.
Training on Loose Leaf
Instructional design had taught Paul to value analysis, and he still does. What changed was his expectation of how much analysis he could reasonably do before acting.
Working in SaaS and startups meant entering environments where the business was moving, whether the learning function was ready or not. A company might decide to move from commercial to enterprise sales while simultaneously recruiting the people who would need to execute that strategy. The first new seller could be arriving in four weeks, leaving no opportunity for an exhaustive front-end analysis followed by careful development, piloting, revision, and launch.
Sometimes Paul was developing week two of onboarding while people were completing week one. He came to describe that work as “training on loose leaf.” Nothing was bound, so if something didn’t work, you tossed out that page, replaced it, and kept moving.
For someone grounded in instructional design models, that pace felt uncomfortable. Paul described the adjustment as less of a learning curve than a “comfort curve.” He had information to start with, about the audience, product, market, and business, as well as immediate objectives for the training.
“You’ve just got to trust yourself and trust the information, get something that will meet the objectives—and then just continuously improve,”
Paul Liberatore
That doesn’t mean abandoning rigor; it means recognizing that rigor that occurs after the business needs the answer isn’t particularly useful.
I think this is an important distinction for learning teams because we often talk about becoming more agile as if the answer is simply producing learning faster.Paul’s experience suggests something different: Agility comes partly from knowing when not to do everything our professional discipline tells us we could do.
If They Can Do It, It Ain’t Training
Paul carried a key lesson from a professor who gave him a shorthand he has used throughout his career: “If they can do it if their life or job depends on it, it ain’t training.”
It’s a simple performance test with significant implications. If someone suddenly performs correctly when the boss is watching, the problem probably isn’t knowledge. If a salesperson knows how to do something but consistently doesn’t do it, Paul starts looking elsewhere. What he finds can reveal how quickly a performance problem gets mislabeled as a learning problem.
At one company, a team had built high-quality customer training and certification programs. Customers valued them; the certifications made their jobs easier and could even make them more marketable, yet salespeople weren’t selling them. The assumption could easily have been that sellers didn’t understand the value of the offering, which would naturally lead to more training.
Paul looked at the system instead and found that the salespeople weren’t compensated for selling the training. It was easy for them to sacrifice a line item that did nothing for their compensation. They knew its value, yet the reward structure told them that something else mattered more.
In another situation, salespeople were expected to update a CRM from the field after each customer visit. In practice, that meant going back to their cars, tethering laptops to their phones over a cellular connection, waiting roughly 20 minutes just to get into the system, navigating a difficult workflow, and then facing what Paul described as roughly a 50-50 chance that the record would save. Sellers adapted by accumulating notes and trying to enter everything later, often during a Friday office day, which meant they fell behind and the CRM data became stale.
Again, they knew what to do, but the workflow made doing it unreasonable.
This is where Paul’s process engineering experience becomes particularly relevant to L&D: Performance problems rarely respect organizational boundaries. The first response to a consistent issue might be to “get the training guy in here, because obviously they don’t know what they’re doing.”
While the cause of a breakdown might be lack of knowledge—it might just as easily be a flaw in process, technology, incentives, expectations, or some combination of them. Training might still be part of the answer, but accepting the request for training before understanding the performance environment can mean solving the wrong problem very efficiently.
Turning a Mountain into a Molehill
Paul’s applied his broader view of performance to organizational change. At one point, his team was involved in several substantial changes at once: The sales organization was shifting from relationship selling toward a new sales methodology; sellers were receiving new mobile devices; and a new content management platform was being introduced. The vendors supporting these initiatives warned that launching so much simultaneously was a recipe for failure.
The safer approach was sequential: Introduce the methodology; allow people to adjust. Roll out the content platform, and let them become comfortable with it. Finally, introduce the new devices. Paul estimated that approach could stretch across roughly 18 months.
He and his team went in the other direction.
Rather than present three separate changes, they created one coherent experience: Here is how we’re approaching sales differently; here is the content that supports that approach; and here is the device that puts that content in your hands.
The technology, content, and methodology fit together “hand in glove,” meaning that what appeared organizationally to be multiple transformations could make sense to the salesperson as one change. As Paul put it, they had “turned that mountain into a molehill.”
Paul had another reason for moving quickly: The population itself was moving quickly. Sales organizations can have considerable turnover, with lower performers leaving—or being asked to leave—while high performers may pursue their next opportunity. Paul knew that, in 18 months, the makeup of the sales team could be very different.
The slower approach wasn’t necessarily wrong; it was wrong for that environment. Business context changed the appropriate design.
The Truth Isn’t in Here
One story Paul shared captures how he kept enablement from becoming an internal training factory. A sales leader once walked into his cubicle and asked where he was going the following week. Paul told him he would be in the office.
The response stuck with him: “The truth isn’t in here. The truth is out there.”
Paul subsequently established a 20% field requirement for himself and later for his team. One day a week, or roughly 20% of their time, someone from enablement would be out with salespeople. Not at sales kickoff meetings or dinners; actually working alongside the team.
Paul rode with sales representatives, watched them interact with customers, saw what happened when a busy physician gave someone five minutes of attention, and observed the difference between the seller who could turn those five minutes into an invitation to continue the conversation and the seller who couldn’t. He spent hours in cars between customer visits, held bags while reps demonstrated products, stayed at the same hotels, ate breakfast with them, and shared lived experience.
That immersion was essential; as Paul discovered, when you spend six hours in a car with someone, the small talk eventually gives way to reality and truth.
That kind of honesty requires trust, however, and Paul made it clear to leadership that he couldn’t return from a ride-along and report who had complained about what. Do that once and, as he put it, he becomes a “snitch,” and the honest conversations disappear.
Instead, his team looked for patterns across people, territories, and regions; brought those patterns back to the business; and, importantly, acted on them. Salespeople began seeing their experiences reflected in the next iteration of training, tool rollout, or change in strategy. Paul stopped being just the guy from corporate taking notes and became someone who listened and did something with what he heard. The salespeople found the “satisfaction of seeing [their] input included or incorporated into the next version of training or the next rollout of a tool” to be very motivating.
This may be the most transferable lesson in our conversation. Learning leaders talk endlessly about understanding the learners, but we often understand people through surveys, stakeholder interviews, focus groups, personas, and needs analyses. Those methods have value, but there is a difference between collecting information about work and experiencing work closely enough to recognize what that information misses.
Follow What People Are Rewarded For
When I asked Paul what he would want to understand first if he walked into a new sales organization tomorrow, his answer was immediate: What are the executives measured and rewarded on, and what are the salespeople measured and rewarded on?
“If I know those two data points,” he said, “I can find where the connections and the disconnects are. And that tells me where to focus first.”
Doing that requires looking beyond what leaders say is important. An all-hands meeting, Paul pointed out, is orchestrated for an effect. It may be motivational, informative, or corrective, but it doesn’t necessarily reveal what senior leaders are actually worried about. If possible, he wants to understand what the board is seeing, which reports finance and revenue teams prepare for executives, and which numbers leadership is really sweating over. That is where organizational priorities become clear.
It also helps explain why Paul sees revenue enablement as genuinely broader than sales enablement when organizations do it well. The work can extend beyond sales to customer success and others who contribute to winning and retaining customers and generating ongoing revenue. The organizing principle is the business outcome.
That matters for learning teams. Training and Development became Learning and Development—without changing our basic products. Revenue enablement could similarly become a broad label wrapped around training programs.
Paul’s approach starts by asking what the business is trying to accomplish, what people are actually experiencing, and what is preventing performance—and only then deciding what to build.
Be Careful What You Outsource
Our conversation eventually turned to AI. Interestingly, Paul’s perspective echoed much of what he had already said about enablement. He sees enormous value in AI as a time saver: AI can help analyze information, pressure-test thinking, and identify things he may have overlooked. He wants AI tools to challenge or extend his thinking rather than replace the generative process.
That distinction led us into a larger conversation about creativity, synthesis, and what Paul called the “human spark.” He is less concerned with whether AI can assemble existing information into useful answers than with what happens if humans become satisfied with letting it do so. “Be careful what you want to outsource from your brain, because as soon as you give up that innovation… when does that start to atrophy certain parts of your cognitive processes?”
For learning professionals, that caveat feels particularly important as we rapidly gain tools that can create scripts, images, video, voiceovers, courses, analyses, and recommendations. The efficiency is real—and so is the temptation to equate producing something with thinking.
Paul’s career shows that much of what made him effective came from things that were inefficient: riding around with a salesperson; listening long enough for the real story to emerge; noticing how incentives shaped behavior; watching a workflow fail in context; connecting signals across people, processes, and tools; and trusting his own judgment when the prescribed approach didn’t fit the environment.
AI can process an extraordinary amount of information about work, but Paul’s experience suggests there is still considerable value in actually being there when the work happens.
The Undercurrent
What stayed with me after talking with Paul is that his move from instructional design into enablement was more a widening of the lens than a move away from learning. Once you distinguish ‘knowing’ from ‘performing,’ a lot changes.
A request for training becomes a question about performance. A reluctant employee becomes someone operating within a framework of incentives, processes, tools, and constraints. Analysis becomes something you do continuously, by staying close to the work. Finally, the learning professional evolves from a provider into someone who understands why performance happens.
That may also be the more important lesson as AI becomes increasingly capable of creating the products that learning professionals have traditionally produced. If our value is the course, the deck, the video, the analysis, or even the answer, AI will increasingly compete with us. But if our value comes from seeing what others miss, uncovering connections, understanding people in context, exercising judgment, and developing novel responses to problems, the future looks very different.
Paul learned that lesson long before generative AI arrived, by getting out into the field and discovering that the truth was somewhere else. Maybe L&D can do the same.
