top of page

Why Your Training Request Is Probably Wrong

1 day ago
6 min read

A few years ago, a VP of Sales called me in a mild panic. Her representatives were closing deals more slowly than ever, the pipeline was backing up, and she needed it fixed before the quarter closed. Her diagnosis was already complete by the time she got on the call. "We need a negotiation skills workshop," she said. "Something sharp, something practical, two days max."


A group of professionals attentively engages in a corporate training session in a modern conference room, where a presenter is delivering a presentation on team development strategies.
A group of professionals attentively engages in a corporate training session in a modern conference room, where a presenter is delivering a presentation on team development strategies.

I asked her one question before agreeing to anything: what were reps actually doing in negotiations that made her think their skills were the problem?


She paused. Then she admitted she hadn't actually watched any of the calls. She'd heard from a regional director that deals were "dragging," and the word "negotiation" had simply been the fastest label available. It fit the shape of the problem well enough to say out loud in a leadership meeting. It just happened to be wrong.


This happens more than any of us in learning and development like to admit. A stakeholder brings you a request, dressed up as a training need, and most of us take it at face value because that's what we were trained to do. We ask about audience size and timeline and delivery format. We rarely ask the one question that actually matters: is this a training problem at all?


The Stat Nobody Wants to Hear


Here's the uncomfortable part. In my experience running actual diagnostic work across dozens of organizations, somewhere between a third and half of all "training requests" turn out not to be training problems once you dig even a little. Not because the people asking are lazy or wrong-headed. They're just doing what we've trained them to do: describing a symptom in the only vocabulary the corporate world has given them, which is almost always some version of "we need a course on X."


The sales VP's real issue, once we dug in, had nothing to do with negotiation technique. Her reps were excellent negotiators, actually, when you watched the calls closely. The real problem lay in pricing approval process that routed every discount above 8% through three layers of finance sign-off, adding an average of eleven days to every deal. No amount of negotiation training touches an approval bottleneck. A two-day workshop would have made her reps feel better and changed absolutely nothing about her pipeline.


That's the trap. It's not that training requests are usually malicious or careless. It's that they arrive pre-diagnosed, and the diagnosis is almost always wrong in some specific, fixable way, because the person making it doesn't have access to the tools that would let them diagnose it correctly. That's not their job. It's supposed to be ours.


Why This Keeps Happening


I think there are three reasons this pattern repeats itself so reliably, and none of them are flattering to our profession.


The first is structural. Most of us came up through instructional design, and instructional design's entire methodology starts one step too late. ADDIE begins with Analyze, which sounds like it should catch this problem. But in practice, "analyze" almost always means analyzing the content, the audience, and the learning objectives, not analyzing whether a learning solution was ever warranted in the first place. We were taught to ask "what should they learn," not "should they be learning anything at all."


The second reason is incentive. Saying yes to a training request is fast, visible, and safe. You get a project, a timeline, a deliverable, and eventually a course that ships. Saying "I don't think this is actually a training problem" is slower, less certain, and occasionally makes you look like you're pushing back on a client instead of serving them. Early in my career, I said yes to requests I privately doubted, because saying yes felt like doing my job and pausing felt like obstruction. It took a few expensive failures to unlearn that reflex.


The third reason is vocabulary. Business leaders don't have a rich language for describing performance problems. They have "the team needs training," "there's a skills gap," "people aren't executing," and a handful of other catch-all phrases that get reused for every kind of organizational friction imaginable. When someone says "our managers need better communication skills," they might mean exactly that. Or they might mean their managers have never been given clear priorities, or their managers are drowning in an unreasonable span of control, or the org just went through a reorg and nobody trusts anyone yet. All four of those get described with the identical sentence. Only one of them is actually a skills problem.


What a Wrong Diagnosis Actually Costs


The obvious cost of misdiagnosis is wasted money. Courses cost money to build, time to deliver, and more time for people to sit through. That's real, but it's not even the expensive part.

The expensive part is what economists call opportunity cost. Every month spent building the wrong solution is a month the actual problem sits there, uncorrected, quietly compounding. I once watched a company spend four months and a meaningful chunk of its L&D budget on a customer service training program aimed at fixing declining satisfaction scores. The real cause, as it turned out, was a staffing cut at three locations that had left frontline teams stretched too thin to serve customers at the pace expected of them. By the time the training rolled out and failed to move the numbers, another two quarters had passed. The company had now spent six months and a training budget without touching the actual problem, and morale at those three locations had eroded even further because employees kept getting told to "improve their service" while working short-handed.


There's a quieter cost too, one that matters more for those of us building careers in this field. Every time we ship a course that doesn't move the needle, we make it a little easier for the next executive to view learning and development as a cost center that produces content nobody asked for and nothing changes. We become, in the eyes of the business, an order-taking function rather than a diagnostic one. And once you're seen as an order-taker, you get treated like one. Nobody invites the vending machine into the strategy meeting.


The Question That Changes Everything


I don't think the fix here is complicated, even though it can feel uncomfortable the first few times you try it. Before accepting any training request, ask one honest question: what evidence led you to believe this is a training problem?


Not "what do you want the training to cover." Not "who's the audience." Just that one question, asked with genuine curiosity rather than skepticism. Sometimes the answer is solid. Sometimes a stakeholder really has watched the behavior closely, has ruled out other causes, and training genuinely is the right lever. When that's true, you'll know quickly, and you can move forward with real confidence instead of borrowed confidence.


Often, though, the honest answer is some version of "I just assumed." That's not a failure on the stakeholder's part. It's an invitation for you to do the part of the job that actually requires expertise: figuring out what's really going on before committing anyone's time or budget to fixing the wrong thing.


This single habit, asking for evidence before accepting the diagnosis, is the entire dividing line between building courses and consulting on performance. It doesn't require new credentials or a different job title. It requires being willing to sit with a slightly awkward silence on a call while someone realizes they haven't actually looked into their own problem yet.


Where This Goes From Here


I want to spend the next several posts walking through exactly how to do this well: how to tell a real capability gap from an environment problem in disguise, how to use data instead of anecdote to find out what's actually happening, and how to know when a gap isn't even worth fixing. None of it is complicated once you see it. Most of it just requires asking one more question than we've been trained to ask.


But it starts here, with the uncomfortable admission that sits underneath everything else in this series: most of the requests landing on your desk right now are, in some specific and fixable way, probably wrong. That's not bad news. It's the best opportunity available to anyone willing to ask why.

Comments


bottom of page