Before we get into it, I moved this newsletter from Substack to Beehiiv a few months ago. I would love to hear from you if you prefer the new way, or miss the Substack version of The Learning Stack. Maybe it makes no difference to you. I am considering posting the newsletter on both. Maybe you would prefer LinkedIn instead.
Whichever way, I would love to know - drop me a reply to this email and let me know. Thanks.
Now back to it:
For a good chunk of my career, I owned Customer Education. My budget, my roadmap, my team.
This year I made a move: I am now in an individual contributor (IC) role inside a Go-To-Market (GTM) Enablement team.
The adjustment has been interesting.
Customer Education answers to retention and expansion. Success looks like a customer who keeps renewing, keeps growing their footprint, keeps needing you less because they've actually learned the product. GTM Enablement answers to pipeline and quota. Success looks like a rep who closes faster, with fewer stalled deals, this quarter.
Same instinct underneath both, help people do the work better, but different stakeholders, different metrics, and a different timeline for proving it worked.
One thing I am trying to translate cleanly across the move: a framework that's shaped how we can decide where to actually add value versus where we just add activity.
A sales team misses target for the third quarter running. The instinct in most Learning and Development (L&D) teams is to build training.
James Swift, who runs enablement at Leyton, has a structured process for this instead. I saw him present it at Offbeat Fest in London earlier this year, in a session called "Enablement Beats Learning." Seven steps, run every time part of the business underperforms.
Credit to James Swift and Leyton. Original post here
1. Business challenge
Define the actual problem. Not "we need better onboarding." A specific, named challenge.
Example: a software company launches a new product module. Six months in, deals that involve it win at half the rate of deals that don't. Nobody's sure why.
2. Identify blockers
Work out whether the block is capability or environmental. Do people lack the skill, or is something around them, process, tools, incentives, blocking work they can already do?
Example: Call recordings show reps clearly talking about the module. Where it falls apart is the follow-up: buyers ask pointed technical questions, about security, integration limits, how it holds up under load, and reps fall back on generic reassurance instead of specifics. That's a skills gap, not an environmental one.
3. Identify top performers
Find who's already excelling at the thing that's stalling everyone else.
Example: a handful of reps consistently close these deals despite the same tough questions coming up. Worth finding out why.
4. Observe and codify
Watch them work. Document what "good" looks like, from what they do, not what they'd say if asked.
Example: sitting in on their calls shows they anticipate the same three technical questions every time, and answer with specific numbers and examples rather than reassurance. They'd clearly worked this out for themselves. Nobody else had.
5. Build a useful tool
Turn that observation into something practical: a playbook, a coaching asset, whatever fits how people already work. The format matters less than the fit.
Example: those three questions and their specific answers become a short technical briefing reps can pull up before a call. Not a course to sit through, something to actually use.
6. Test in environment
Validate it in context first. Does it work where the work happens?
Example: a small group of reps gets the briefing and uses it on live calls for one quarter. Their calls get reviewed and their win rates on module deals get tracked, to see whether anything actually changes.
7. Scale
Only once it's proven does it go org-wide.
Example: the briefing rolls out to the full team, and gets built into onboarding for new hires.
The elephant in the room: connected data
Swift's own model puts a data foundation underneath all seven steps: Customer Relationship Management (CRM) data, analytics, performance metrics. Not an eighth step tacked on the end. What the other seven stand on.
Look back at the example. Step 1 only exists because someone could see the win rate on module deals sitting at half the rest of the pipeline. Step 2 only reached the right diagnosis because call recordings showed reps handling the demo fine, which is what ruled out the environment and pointed at the follow-up questions instead. Take that data away and both steps collapse into guesswork.
In many businesses, that foundation isn't there. CRM data, product usage data, and call recordings usually sit in three different systems that don't talk to each other.
If that's the state you're in, connecting them comes before step one. Call it step zero.
That means sitting down with Revenue Operations (RevOps) or whoever owns analytics, and treating "can we tag which deals involve this module, see how they perform, and hear how the calls actually went" as its own project. Sometimes that's a genuine infrastructure gap. Often it's smaller: a CRM field nobody's filling in consistently, or a report that exists but nobody's built.
What to do while the data catches up
Waiting for perfect data before starting costs you time you don't need to lose. The people doing the work already know things a dashboard doesn't show.
Talk to frontline sales leaders. Ask where they see deals involving new capability get stuck, and what they think is actually causing it.
Talk to individual contributors (ICs) directly, not just their managers. The person on the call often has a sharper, more specific read on where the friction sits than anyone above them, precisely because they're the one hitting it every week.
In the example above, a few honest conversations with reps would likely have surfaced "I don't know how to answer the security question with any confidence" well before the win/loss data confirmed it. The data proves the diagnosis. It doesn't have to be the only way to reach it.
Why this matters beyond Leyton
Most L&D functions are built to produce content. Ask them to fix underperformance and they'll reach for the only lever they have.
Swift's process forces a harder question before any content gets built: is this actually a skills problem?
Sometimes it is. Often it isn't.
This week's newsletter is sponsored by Sana.
A quick word from this week's sponsor, Sana.
Everything in this newsletter rests on Swift's ""step zero"" - connecting the data so you can actually see what's going on. In most companies that's the hard part, because the content, the usage data, and the record of how work actually happens all live in different systems.
Sana Learn is built the other way round: one place where your content and your data sit together, so the platform can answer from what your teams actually know. Doctolib used it to double the learning hours their people complete. Worth a look if you're staring down a step zero of your own. Find out more here.