I came across an email in which I’d noted a contribution that Terry Seamon made to an online discussion about learning at work:
Ultimately, the answer to “Do you understand?” is “Yes, let me demonstrate.”
Sometimes–especially at large conferences–it can seem as though many trainers and instructional designers lapse into a kind of cognitive ritual, reciting orthodox objectives, sometimes for every 15-minute segment of formal instruction. “At the end of this topic, the student will be able to advance to the next topic.”
I’m in favor of performance-based objectives, but mostly as a tool for design, not as a benediction recited over the heads of people who would much rather get something done. I firmly believe that what learners would rather hear is more along the lines of “This segment shows you how to calculate flood insurance rates for residential property.”
Or, if they’re dealing with softer skills, “Next, you’re going to practice planning and conducting a counseling session when an employee’s performance has become unsatisfactory.”
That’s 15 seconds, not ten minutes plus time to post the flipchart. It’s a virtual course? Then you have a much shorter audio/video lead-in.
Sometimes people benefit from knowing theory and concepts about a field, but as van Merriënboer and Kirschner say, you can’t practice theory. Theory is a kind of map, an effort at organization, like Samuel Champlain‘s maps of New France. Maps and theories get better as you put them to use, incorporating mindful experience into the previous effort at organization.
Champlain’s 1612 map of New France (from Wikipedia)
There was a time in my career when I’d strenuously avoid using “understand” as an objective, and I still think that on the part of someone planning any kind of structured learning, it’s at best oversimplification and at worst a sign he should have gone into another line of work. I’m speaking of the developer, though, not the client; more often than not, the client’s using “understand” as shorthand for a fistful of skills (and, frequently, a bucketful of facts).
Seamon’s statement above offers a way out of the dilemma without having to rant about behavioral objectives. How can someone demonstrate that he understands the difference between a single-life annuity and a joint-and-survivor annuity? Maybe he describes key differences; maybe he identifies examples of each when presented with descriptions of various types of annuities. Maybe he role-plays a conversation and gets feedback on his answers from an expert. You choose among demonstrations like these depending on what someone needs to accomplish in the workplace, and both you and the learner are better off for the choice having been made.
For a few months, I’ve been head-down in my new job (I’m a curriculum developer with the BC Pension Corporation). Much of it involves helping our staff adapt to changes in the tools they work with or in the processes that those tools work on, in order to serve our members–the people covered by various public-sector pension plans here in British Columbia.
There’s a significant procedural component to that. Pension plans in general are governed by all kinds of rules — vesting requirements, contribution tracking, tax issues — and can have so many options that they’d daunt Benoit Mandelbrot. That’s one reason that a few weeks ago I noted this post by Misty Harding at the eLearning Brothers site.
One trigger for her post on handling boring content was boring content:
I realized that I didn’t need to spend any more time wrestling with that yawn-worthy content, and neither did the learner. I achieved this through (brace yourself Instructional Design World), not focusing on the content.
Much of what she then offers will strike many people as common sense, but those people are probably turning out pretty good stuff. This is a quick summary; read her full post for helpful details.
Give them something to do that isn’t at its core touring the boring content.
Violate expectations: approach the learning challenge (as opposed to “the content”) in an unexpected way.
Let them take on a role so they need to solve a problem.
Part of what Misty Harding is addressing, I think, is the gap between proceduralknowledge and tacitknowledge. In any organization serving individual customers, be it BC Pensions or Zappos, you’ll find reams of procedures. Invariably these deal with routine processes — or at least processes that can be routine-ized, because at some level the steps and the decisions are predictable and the range of outcomes is fairly small.
What’s far more challenging is combining these procedures effectively–a point that Harold Jarche makes in this diagram:
If like me you’re trying to help people who have to deal with things on the “routine work” end of the diagram so they can deliver things of higher value, then whatever training and support you produce benefits from being set in a realistic context.
It also benefits from avoiding stuff that doesn’t relate to that delivery. (I recall an EEO compliance officer who insisted that people needed to know the dates of EEO-related legislation–in a course on helping an employee to pursue a discrimination complaint.)
“Realistic” also does not mean the typical software Field Trip:
This is the Last Name field. Enter the last name here.
This is the First Name field. Enter the first name here.
This is the Street Address field. What do you enter here?
(ad blooming infinitum)
The training course I’m working on at the moment deals mainly with changes to our procedures caused by legislation going into effect next month. It’s not earth-shaking; it’s not going to reset paradigms for everyone who works at the corporation. Even so, our design relies heavily on teaching the rules and principles by having participants work through a series of problems.
Even the initial look at procedures for choosing the beneficiary for a pension will involve opening the online procedures (just like you do in the target jobs) and working a sample nomination form (our term) through the initiation, evaluation, and entry stages.
What about things that are new or significantly changed? Well, take one new on-screen button. It enables a feature that didn’t exist in the previous version, because the underlying capability didn’t exist. No matter what the label is on such a button, without context people are likely to misinterpret it.
Rather than introduce it as part of a field trip (“here are 27 changes you’ll see on 9 different screens”), we’ll deal with it in the third practice exercise, which will be the first time clicking that button would make sense.
What’s all this got to do with tacit knowledge? In part I think tacit skills emerge as you combine procedural skills (and interpersonal skills) in job-related contexts. You’ve got to build them up, and working with realistic problems–including relating them to your experience, speculating about variations, and exchanging ideas with experienced people–is one way to help foster that construction of knowledge.
I think it’s well worth reading in its entirety. Here on the Whiteboard, I wanted to summarize some of those truths in part one, and add comments for which Boller has no responsibility whatsoever.
ILT is not dead.
When I read this, I tell you, you could have knocked me over with a smilesheet.
I’m not mocking Boller–far from it. Among the many useful features in her whitepaper are summaries of facts. For instance, ASTD said last year that 59.4% of companies reported using instructor-led classroom training, and another 13.3% use instructor-led by online or remote (such as video).
Self-paced online? 18.7%, and a whopping 1.4% are using mobile as a distribution method.
I looked at this summary from ASTD about the State of the Industry report that Boller mentions. While this isn’t the entire report, I found a comment about “content distribution” striking:
Technology-based methods have rebounded to account for 37.3 percent of formal hours available across all learning methods.
If I read that right, then non-tech methods (you know, like instructor-led classroom training) accounts for more than 60% of “formal hours available across all learning methods.
Even the phrase “learning method” is telling. I’m not the kind of fanatic who goes around correcting punctuation and menus; I can even hold a civil conversation with someone who uses “understand” as part of a training objective–because I’m inclined to see it as shorthand for something that can eventually be observed.
So I do understand that people in the industry use “learning method” for things that can only aspire to encourage learning. I do think it’s helpful to state that explicitly from time to time. Absolutely, you can design and create activities, experiences, exercises, games, what have you, that are aimed at supporting, encouraging, and so on, just as you can find recipes, buy ingredients, set a table,and prepare dishes. What you can’t do is guarantee that people will eat your food.
mLearning: lots of talk, little action
That ASTD report tells us that 1.4% of formal learning is delivered via mobile. Like Boller, I’m sure the current figure is higher. After all, an increase of nearly 50% would get you all the way up to 2.1% .
I can’t help wondering whether one serendipitously limiting factor is that you can’t easily cram a 300-slide barrage of PowerPoint onto a smartphone screen. Tablets are an easier target for this pumpkin-headed kind of leveraging, though, and are probably already plagued with far more legacy content than the Geneva Conventions should permit.
I want to underscore that in this first section, Boller’s talking about the way things are, not how they will or should be.
I confess that I’m a little leery of “mobile learning” in a learning-industry context. I fear it’ll be stacking and tracking: loading stuff up because it can go onto a mobile device, and then using ever-better software to track whatever somebody thinks ought to be tracked. It’s always easier to track a score on a quiz than the quality with which someone handled an actual problem from an actual customer.
Outside vendors matter.
One thing Boller says in this section is really about attitudes inside an organization:
Most companies are NOT in the L&D business; they are in business to do something else.
This ought to be obvious, but it’s sometimes only a ritual nod that L&D makes toward the reason there’s a organization at all.
Employees don’t get much formal training.
31 hours a year is the average in ASTD’s data, or 1.5% of a year’s worth of 40-hour weeks.
There’s a way in which much “formal learning” in the workplace is really “focused introduction with maybe a little practice.” 31 hours is like a 2-credit course in college (which may explain my level of skill when it comes to History of Art).
Boller says she thinks of this time spent in formal training like driver’s education. “Would you rather have your kid spending more hours in the classroom… or more hours behind the wheel practicing driving with a qualified adult providing constant feedback?”
In Maryland, where I live, the formal training requirements for a new driver, regardless of age, include completing a standardized driving course with at least 30 hours of classroom instruction and 6 hours behind the wheel.
That’s the formal-training requirement. But obtaining a provisional license also requires 60 hours of driving with “a qualified supervising driver (parent, guardian, or mentor)” who completes and signs a practice log documenting those 60 hours.
I can picture the diagram in my driver’s ed textbook that explained how to parallel park. That was helpful, in the way that a dictionary definition of a word is helpful. But if your goal is more than “repeat the definition when asked,” you’ve got to work up to fitting your car in between two others on the street.
That might not take 30 hours–but it will take spaced practice; it will take varying conditions; it will probably benefit from scaffolding (such as starting with a span of three empty spaces behind a parked car).
And that’s just the parking part of the driving-a-car set of skills.
Majority of eLearning “doesn’t match” what’s optimal.
I can’t possibly improve on what Boller says:
Clients ALWAYS say they want something that is “engaging” and not too content-heavy. Yet the stuff we routinely see looks very much “Text and Next” with tons of content and little relationship to any behaviorally-based outcomes. Sometimes this is the result of a subject matter expert who ruled with an iron fist in terms of focusing on content rather than outcomes. Other times it was the result of an internal person who decided to get Articulate or Captivate and started creating his or her own stuff – with no background in learning design.
Most of the people we talk to inside organizations HATE taking eLearning courses (including lots of folks who hire us to produce it). They hate it because most of it is boring, bad or it’s not really eLearning – it’s a communication piece squished into an eLearning shell so someone’s completion can be tracked via an LMS.
My only quibble is with the “not really eLearning” part. My hunch is that most people in organizations hate elearning because it’s far more about the E (as in ease of delivery and easily outsourced and easily tracked) than it is about the learning.
LMS: few pull data, but they all think they need it.
Boller says is that the majority of people “do not actually access or use the data available to them within an LMS.”
This sounds so much like the SCORM evangelism I used to hear–“there’s so much good stuff in there; it’s just not implemented right.”
To which my (occasionally spoken) reaction was, “No kidding.”
There must have been places where SCORMification actually helped increase the likelihood that people learned on the job–but that’s a belief on my part, or perhaps a hope. My own experiences with projects where the management team included a SCORM hall monitor was that the fetishization of the SCO could overrule any argument based on ephemera like principles of learning or on-the-job relevance.
Just as with mainframe-based CBT back in the olden days, just as with the 12-inch laser disks and players grafted between the PC and its VGA monitor, just as with the nearly unavoidable audio response systems that have reanimated the multiple-guess question, there are convention-halls full of vendors eager to explain how their particular magic beans are just the thing you want to trade your corporate cow for.
As a girl from a small town in Nova Scotia, my mother had to go a long way for her professional development. It’s 1,200 miles (and they were miles back then, not kilometers) from Inverness to St. Michael’s Hospital in Toronto, where she did her nurse’s training, just before the outbreak of World War II.
Apart from a belated recognition of Remembrance Day, the Canadian term for what the U.S. calls Veterans Day, it’s as good a way as any to mention Toronto (known in the Victoria era as “Toronto the Good,” for its alleged propriety). I spent a week there recently at the CSTD Conference there and led a session called Building Job Aids: How, When, Why.
I have some biases regarding job aids.
One is that an awful lot of people who call themselves instructional designers like to design instruction. So they write objectives and plan activities and encourage discovery and structure experiences. Some of them go on to embalm these things in SCOs. All in pursuit of that elusive transfer of learning.
A corollary to that bias: it never seems to occur to some of these people to not design instruction. For example, they don’t create job aids. They don’t see job aids as a way of reducing or eliminating the need for formal training, nor as a tool that people use on the job and thus should practice using during formal training.
Instead, job aids get crammed to the back of the cognitive closet, next to the icebreakers and under the smile sheets. Besides, you can’t track job aid use in an LMS, so how good can they really be?
Guys: if people don’t use it on the job, it’s not a job aid.
I kid because I love. Actually, I kid because I’m puzzled by the non-use of so practical a tool. So, in part because I’d like to make myself better known in Canada, I created a session that I thought would appeal to people who’d thought about job aids, or wondered about them, and who were interested in finding out if job aids made sense for the workplace problems they grapple with.
I included lots of examples of job aids, which I’ve been adding to my show-and-tell blog, Dave’s Ensampler. I included an exercise in which people would describe to a partner some task they knew about, with the listener assessing that task’s suitability to job-aiding using questions that I’ve discussed here before (When to Build a Job Aid).
What I did not do was to first walk them through–which, let’s face it, often means talk them through–that process. Given their likely backgrounds, people in my session were likely capable of putting a decent job aid to use on their own.
So: this allowed more time for the exercise, since I wasn’t going on about the exercise. Second, it provided a clear albeit small demonstration of a job aid taking the place of instruction. If people could get through the task-assessing exercise without my telling them how, even though they hadn’t made this sort of analysis before, then it’s pretty clear you don’t have to train people just because you’ve uncovered a skill-and-knowledge gap.
We discussed the decision questions afterward, and if you can imagine such a thing, there was very little puzzlement or confusion about what goes into the decision and why.
So then I did talk a bit, showing how a good task analysis is whispering very loudly that certain tasks would be great to job-aid. My experience is that this would be a new concept to many, so I demonstrated with a short example, and using that example showed some features common to all job aids.
At that point, we went into a second hands-on exercise. The day before my presentation, I created this as a replacement for what I’d originally planned to do. As I had been rehearsing, I felt that people weren’t getting enough opportunity to do things for themselves.
Why not have them try to create a decision table? From the web site of the Superior Court for King County, Washington, I copied instructions on how to file for a protection order (an anti-harassment protection order, a domestic violence protection order, and so on). I chose this topic to emphasize that job aids can apply to important real life tasks and not just to refunding a store purchase.
Participants started with a set of descriptions (created by me based on the court’s actual guidelines), along with a job aid for creating decision tables. For an exercise at 4:15 in the afternoon, less than an hour before conference-sponsored drinks and snacks, people seemed very engaged–lots of talk within the table groups, not too many obvious signs of boredom or frustration.
Thanks to comments from participants both in the session and afterward, there are changes I’ll make. My original thought was that I needed to add a detailed demonstration before the exercise. A week later, though, I think that’s just my internal instructor dying to explain something again.
Instead what I’m going to create is a better job aid for how to build a decision table once you’ve analyzed a task like choosing which protection order a person needs. I think an example–a model of building such a table–makes a lot of sense, and it too will probably be a handout.
In other words:
Provide details for the task that’s going to be job-aided
Provide guidance in drafting a decision-based job aid
Provide the least amount of description / explanation / instruction possible
Then, get out of the way. Let people work with the tools. Let those synapses fire. Stand ready to respond to questions or comments, with the aim of helping people come to their own answer.
I’m grateful to CSTD for accepting my proposal, and I’m indebted to the people who participated in the job aids session. Thanks to them, I’m putting together what I think of as a workbench (rather than a workshop): an engagement of three days or so in which I work with clients to build up job aid skills and immediately apply them to real work challenges. I’ll act as a guide in the skill area and as a coach for the client’s own efforts to build job aids.
Part of an email I received yesterday; I’ve changed a few [specifics] for privacy’s sake:
My friend [Veronica], a retired lawyer, has just started training as a part-time [Stratosphere Airlines] ticket agent at [Overcrowded Airport].
She has started with some computer-based self instruction that seems to dump lots of info on students before any application, like memorizing the airport codes for cities that Stratosphere flies to. She says there will be interaction–role-playing-like simulations of conversations and problems a ticket agent will predictably experience.
She said the trainer has confessed to her that the info dump without application is neither his own preference nor his design. It is imposed.
I’ve never worked for Stratosphere Airlines; I’ve hardly ever flown them. But I recognize this situation and this approach, because they’re a direct flight to 1975, when this dull-witted, learn-X-before-Y approach was pandemic in the travel industry. It’s how I started learning what was Amtrak’s reservation system at the time: memorize a trainload of facts.
One of the many unfortunate assumptions is the value of such memorization. Like Latin or limp broccoli in your school lunch, it’s supposed to be good for you. In the context of becoming competent as a ticket agent, though, it’s as misguided as memorizing the name of every street along your 25-mile commute, rather than learning the most sensible route and then useful variations, like when to avoid driving past the high school.
The assumption in Veronica’s training program is that you have to know the city code before you can look up a schedule. The reality is that you have to have the code, which isn’t the same thing. Let me demonstrate with an example from based on Amtrak’s old reservation system:
Use the A (Availability) entry to find the schedule between two cities.
Here’s how to check availability between Chicago (CHI) and Los Angeles (LAX) on July 5th:
A 5JUL CHI LAX (don’t use spaces; they’re here just to make the example clear)
How would you check the schedule for May 9th from San Francisco (SFO) to Portland (PDX)?
The odds are that 80% of people, given that example, will come up with one of the two correct answers(A9MAYSFOPDX or A09MAYSFOPDX–the leading zero in the date is optional). Which means that for them an instructor or course can respond, “That’s right” and then show what the reservation system would show: the schedule from San Francisco to Portland on May 9th.
I’m skipping some nuance here, like taking note of the leading zero if the person uses it (and pointing out it’s optional). I’m also skipping what a good instructor or course would do with what I call expected wrong answers–someone using the correct city codes in the wrong order, or using a code from the example.
To me, this example is a bite-sized authentic task: it’s a small accomplishment that makes sense in a workplace context. Your customer asks what the schedule is from Point A to Point B, and you find out. Looking up city codes is a useful, even essential skill (if you don’t have the city code for Moose Jaw, you can’t find a flight that goes there), but it’s just one component in a cluster of authentic tasks.
What’s more, I can put together a logical sequence of such bite sized tasks into a complete customer transaction suited to a novice ticket agent. And I can then expand parts of that sequence to give practice in applying the system’s power (which is to say, its complexity) to meet a customer’s requests. “Is there a flight that will get me to Moose Jaw by 3? Can I leave Moose Jaw on Saturday morning? Is there a discount fare when traveling with small children on the weekend?”
I worked in an Amtrak ticket office for four years, and no customer ever asked me for a city code. We used them all the time–but our practice was to teach ticket agents to look them up at first, and not guess. We also has job aids for frequently-requested cities–storing the information in the job aid instead of trying to cram it into someone’s head. The training-wheels effect would kick in, so that after a week or two on the job in Detroit, you did memorize the code for Jackson, Michigan (JXN), a destination people requested from us far more often than they did Jacksonville, Florida (JAX) or Jackson, Mississippi (JAN).
There’s an awful lot of stuff to learn in a railroad or airline reservation system. I often use ticket-agent training as an example of a potential drawback to using only informal learning approaches. Yes, it’s true, if I dropped you in the middle of Budapest with a tattoo on your forehead that said “Kérem, ne beszélj velem angolul” (“Please don’t speak to me in English”), you’d probably start picking up Hungarian quickly. Depending on your interests, though, a scenario-based course on Hungarian for Travelers–focused on realistic situations that made sense to you–might be a better idea.
It’s almost certainly a better idea than beginning by studying verb conjugations. You’ll need those, eventually, but you can probably find out what time the flight arrives without having to study the subjective first. Except, maybe, if the Stratosphere Airlines flight from 1975 were to arrive.
