This is likely a situation you're familiar with. A problem surfaces — customers complaining more often, a process breaking down, performance slipping in a team, or people standards dropping gradually. Then somebody suggests training. It sounds reasonable; you have a Learning & Development function after all. You commission it, see the completion reports and the quiz results, but six months later you're back in the same conversation wondering why nothing has changed.
I've spent a decade on the inside of this cycle. Inside L&D functions that build great and engaging courses one after the other — sometimes dozens each calendar year. And I want to tell you something that most L&D practitioners may not: training was often never going to fix the problem. Not because it was badly designed. But because it was solving the wrong problem.
Here's where I believe part of the problem stems from.
The moment someone decides training was the answer, they made an assumption so quietly that nobody noticed it being made. They assumed the problem was a people problem. That your people didn't know something, wouldn't, or couldn't do something, and that a course would close that gap.
This is a comfortable assumption.
A people problem is manageable. It doesn't implicate a broken process that has existed for years, or a technology investment that was the wrong call, or a structural issue that would take real organisational force to fix. Compared to those, a people problem is easy, cheaper, faster, and tidier.
So L&D gets the brief. L&D builds the course or the workshop. And the assumption goes unexamined.
I want to be clear that I am not absolving the function I work in. Most L&D practitioners — myself included earlier in my career — accept that brief without asking a single hard question. Yes, we do discovery (at least we should), but that discovery occurs with the expectation of an L&D solution at its heart. The discovery is skewed by a pre-conceived assumption. We are trained to design and build, not to interrogate. From a commercial perspective, there's logic to it: a client who wants a course is a client that is happy when a course is delivered and can see that people have completed it.
Pushing back on the brief can feel like pushing back on the relationship. But the cost of that silence is exactly what you've experienced — and exactly why L&D is in such a precarious, untrusted place in most businesses. Work gets done, money gets spent, completion rates get reported, and the problems quietly continue.
Let me show you the way I think about this now, because it changed how I work entirely.
Every business exists to achieve something. Revenue, growth, reputation, impact — at minimum, survival. Let's call these the organisational goals. To achieve these goals, an interconnected set of task workflows need to be actioned well. Contracts need to be negotiated, customers need to be served, problems need to be diagnosed and resolved, products need to be built. Each of those tasks sits in a chain that goes from the simplest actions all the way to the organisational goals.
So we have the goals, and the system of tasks designed to achieve them.
Ignoring automation for now, we next need people to execute those tasks. When those tasks are being executed poorly, there can be many reasons. The process they're following is broken, the tool they're using is the wrong one, the management around the people isn't working. Or — and this is where L&D genuinely earns its place — the people don't have the knowledge, skills, awareness, or the ability to execute those tasks well.
That last category is the only one where a training solution actually helps. Not because the others don't matter, but because putting people through a course doesn't fix a bad process, doesn't fix the wrong software, and doesn't fix a management problem (unless that management problem itself stems from a knowledge, skills, or awareness gap).
You can train someone to use the wrong tool more efficiently. But if it's the wrong tool, the fundamental problem will persist.
So the first question I ask before I agree to build anything is: "Are we actually looking at a people problem?"
Not because I'm trying to reduce my workload. But because getting the answer wrong is expensive. Not just in terms of the training budget, but in terms of my own credibility cost when the problem persists after the intervention. Every time L&D delivers something that doesn't move the needle, it makes the next conversation harder. It reinforces the suspicion that the whole function is a box-ticking exercise.
When I interrogate a brief now, I'm looking for something specific.
- I want to understand where this problem fits in the Organisation → Goals → Tasks → People system.
- I want to understand what the problem is actually costing the business — in revenue, in reputation, in customer trust.
- I want to know if this has happened before and what was tried.
- I want to understand what the person bringing me the problem thinks is causing it, and I want to ask them what good looks like in six months if we get this right.
That last question is important. It demands specificity. "Better performance" is not a success metric. "Customer complaints about X reduced by Y" is. "The team is managing silence in customer calls more effectively" is. The gap between where things are and where you want them to be in six months tells you more about the real nature of the problem than any number of competency frameworks can.
Sometimes that conversation confirms it is a people problem. Knowledge is missing, or a skill hasn't been developed, or people genuinely aren't aware of why something matters. In those cases I can help — and I can connect whatever I build directly to the task it's meant to improve and the goal that task serves. That's how you get an L&D intervention with a measurable outcome, rather than a completion report.
Sometimes that conversation reveals it isn't a people problem at all. The process is the issue, or the technology, or the way the team is structured. In those cases the most valuable thing I can do is name it clearly and point the business toward the right lever. That's not a failure of L&D. It's precisely the contribution a rigorous function should be making. Someone examined the problem properly and stopped the organisation from investing in the wrong solution.
I recognise this is not how most L&D functions operate. The order-taker model is the industry default, and it exists because it's easy for everyone involved. The commissioner gets a deliverable. The practitioner gets a project. Nobody has to have an uncomfortable conversation about whether the brief is right.
But it's also why L&D is chronically undervalued and constantly at risk when budgets tighten. A function that can't demonstrate a clear line between its work and a business outcome is a function that gets cut when things get hard. And the honest truth is that most L&D functions can't draw that line — not because the work isn't real, but because it was never designed with that line in mind.
I built my practice on a different premise. Every piece of work I do has to connect to a task that connects to a goal. Every success metric is agreed before the build, not after. And when a problem isn't mine to solve, I say so — because that kind of honesty is what earns the trust to have a real influence on the problems that are.
That's what good L&D looks like. It's rarer than it should be.