Improving the Performance of People, Processes and Organizations
Articles Columns Projects Resume Services Tool Room
Why Those Darn Training Problems Won't Go Away
© Fred Nickols 2012
An earlier version of this paper appeared in Performance & Instruction, the journal of the National Society for Performance & Instruction (now the International Society for Performance Improvement).
Despite some 30 years of persistent carping by human performance technologists, those darned "training" problems just won't go away.
Despite plenty of evidence to the effect that most so-called "training" problems are really problems of feedback, or consequences, or expectations, or of the design of the work itself, or simply a case of having the wrong tool for the job at hand, problems bearing the label "training" keep cropping up.
Why? The answer is simple: "Training" is a safe as well as useful problem label. Other labels are fraught with risk and much less useful. To understand and appreciate the safety and the utility of the "training" label, it helps to understand the role that the label placed on a problem plays in solving it.
Problems, Labels, Models and Problem Solving
A problem exists when action is required but the required action is not apparent. Hence, the notion of problem solving as a search activity. But search where and for what? Unless you are inclined to look everywhere and anywhere in a hit and miss fashion , an approach known to technicians of my generation as "easter egging," the search for a solution must take place within some set of boundary conditions, within what Newell & Simon (1972) termed a "search space."
The boundaries defining the search space for a given problem are determined primarily by the model or representation of the problem used by the problem solver. A performance technologist investigating a "performance" problem, for example, is likely to use a model containing constructs or factors such as desired performance, actual performance, feedback, consequences, and so forth. These factors and their relationships define the relevant search space for a performance technologist. A computer programmer investigating a "production" problem is likely to use a model containing variables or factors such as inputs, outputs, and processing routines. (And he or she is likely to wind up reviewing source code, line by line.) Again, these factors define the search space; they determine where the analyst will look and for what. In both cases, the purpose of the model used is to focus the investigator on those factors relevant to the problem at hand.
The selection or construction of a model to use in guiding the search for a solution is determined in large part by the label placed on the problem. The label classifies the problem. In classifying the problem, the label also specifies the class or classes of solutions that will be appropriate. The role played by the problem label, then, is to fix the locus of the problem and the focus of the effort to solve it. In short, the problem label directs and focuses attention. Consider, for example, the shifts that might occur in your own thinking if you were to hear of the following kinds of problems: a "financial" problem, a "business" problem, a "performance" problem, a "feedback" problem, a "production" problem, a "motivation" problem, a "training" problem, or an "attitude" problem.
Obviously, labeling a problem using a label that invokes a model useful in solving it is an essential step. Less obvious is the importance of not labeling the problem too early in the process. If a problem is labeled too soon, those working on it run the risk of invoking the wrong frame of reference and they might find it difficult to shake off this set of referents later on. Even less obvious is the idea of deliberately changing the problem label so as to enable examination of the problem from a different perspective. Varying the label on a problem helps vary the frame of reference being used, it is a way of getting "out of the box."
The Main Point
The essential function of a problem label is to direct and focus attention. Those who are interested in directing or focusing attention during the course of a problem solving effort are or ought to be interested in problem labels and their purposeful manipulation. They also ought to be interested in the second order effects of label manipulation; that is, in what else is manipulated as a result of manipulating the problem label.
A Case in Point
Now, let us see why the "training" label is so darned persistent and so useful.
Lois Barnes, a field sales representative, works for Elmo Steffen, who is a district sales manager. Lois isn't doing what she's supposed to be doing. Elmo wants her to push Product B but Lois is pushing Product A. Why? For several reasons.
Elmo has the situation pegged as a "training" problem. Despite what you might think, Elmo is no dummy. Elmo knows that the reason Lois isn't selling Product A instead of Product B isn't because she doesn't know how to sell or how to sell Product B. In fact, Lois is his very best sales rep. Elmo also knows, in intimate detail, all the many reasons why Lois sells Product A instead of Product B. Yet, he insists on labeling the problem a "training" problem.
Why? Well, if the failure to sell Product B in sufficient quantities to meet the quota were labeled a "management" (or worse, a "sales management") problem, Elmo would take the heat. He would be the locus of the problem and the focus of any solution. Attention would be focused on him and action would be directed his way. Elmo certainly doesn't want that.
If the problem were labeled a "feedback" problem, Elmo would be in the politically awkward position of "pointing the finger" at someone in the home office, probably in the systems shop. The same is true if the problem were labeled a problem of "product quality," or "pricing," or "sales reporting," or "incentives." In quick order, Elmo would be pointing the finger at engineering or manufacturing, systems, and perhaps his own management. Elmo is not about to do that; he's a "team player" and a survivor. Elmo also knows that he's accountable for results, no matter the obstacles or barriers in his way, and regardless of whether or not they fall under his control or influence. "Make it happen" is the order of the day.
So, under intense pressure from his regional vice president to "do something" about the sluggish sales of Product B, Elmo hires a training consultant to develop some new sales training materials for Product B. Elmo, ever-mindful of the long-term consequences of his actions, softens this blow to the corporate sales training staff by claiming that his market segment has some unique differences that are better addressed locally. Some mumbling and muttering is heard from the head of the sales training staff, but nothing serious. Elmo is free to proceed.
The training consultant, Charles "Lucky" Luciano, is no dummy either. After a couple of days spent poking around, he's got almost as good a fix on the factors driving the situation as Elmo does. Like Elmo, "Lucky" Luciano is paid to produce results, regardless of the extenuating or mitigating circumstances. "Lucky" also knows the difference between effective and efficient solutions; namely, that a solution is effective if it produces the desired result, and it is efficient if it has no off setting side effects. Mr. Luciano also knows that if he insists on labeling the problem for what it really is - a "mess" - and on addressing the underlying factors in a head on fashion, there could be plenty of "off setting side effects."
And so, Charles Alphonse "Lucky" Luciano proposes the following: He will develop and conduct a one day sales training seminar, focusing on overcoming specific customer objections to Product B. He will also prepare and submit a report detailing the other factors that should be addressed if the proposed training is to have any lasting effect.
The training is subsequently developed and delivered, and the report written and submitted. Elmo forwards the report to his boss who forwards it to the vice presidents for sales, marketing, product development, engineering, manufacturing, and finance. A copy of the report somehow makes its way to the president, who promptly commissions a senior level task force to "iron out the remaining wrinkles in the launch of Product B." Later, Product B is quietly consigned to the scrap heap.
Elmo subsequently receives a note from his boss's boss, congratulating him on his extremely diplomatic handling of the "sales" problem. The note makes no specific mention of Product B.
"Training" is a safe and useful way to label a problem. It situates the locus of the problem with the performers and it publicly focuses on remedying what are generally excusable knowledge or skill deficiencies. In other words, "training" problems are understandable and forgivable; other kinds of problems are not so forgivable.
The "training" label does not "point the finger" at any one for any reason that might bring grief to the accused (leading me to conclude that the "training" label constitutes its very own form of "no fault" insurance for managers).
The "training" label leads to the involvement of training people who, as everyone knows, ask all kinds of seemingly dumb questions about all kinds of things that seem perfectly obvious to everyone else. As a result, there is no better group of people to use in gathering information.
In good times, training people are forgiven their multitude of sins for very good reason: training is consciously and deliberately used as a way around having to confess to sins committed elsewhere.
In bad times, the reason training people get the ax so quickly isn't because training isn't valued, it's because all the usual pretense and posturing is shunted aside and the sins committed elsewhere are addressed directly. There is no need for a cover story. And, in bad times, as you might guess, the "finger pointing" is fierce.
In good times or bad, a wide range of interventions can be effected under the umbrella of training. Thus, it often proves desirable to label a problem a training problem, no matter its underlying factors, and then do whatever is required to solve it.
All things considered, the ubiquitous "training problem" is likely to be with us for many years to come. The training label is safe and useful, making "the training problem" an important and convenient maneuvering and positioning mechanism for management.
To illustrate, consider the following little story.
I made a good living for many years by "posing" as a training consultant. My "cover" was blown only once. After completing two successful projects for a new client company, both of which were labeled "training" and neither of which had much of anything to do with training, I was invited to have lunch with one of the two executive vice presidents who ran the firm. We chatted amiably for a while, and he then began asking questions about my approach to the completed projects. As I responded to his questions, he categorized my answers. Once he said, "That sounds like systems analysis." Later, he said, "That sounds like operations research." Still later, he said, "That sounds like work design." Finally, he leaned forward and said, "Tell me, why do you go around pretending to be a training consultant?"
Finally, I am much less concerned about managers who sometimes mistakenly use the label "training" than I am about the performance technologist who insists on accurately labeling a problem, no matter the consequences of doing so. You see, as Confucius said: "The truth is always good to know, but it is not always good to speak."
For those interested in exploring further the implications of problem labels, and the very important distinction between effective and efficient solutions, I heartily and respectively recommend the following two books:
This page last updated on June 25, 2015