Basic training

Without roots, you can’t be radical

 

Talking about live backchannels recently led to talking about feedback, which is good (in my view).  It’s feedback that offers the chance not to change, which was the first word trying to get in as I wrote this, but to decide. As in, decide whether to change or to keep on doing what you’re doing.

The difference?  Well, here are the basic steps of a process:

John Barley was a hero bold, of noble enterprise...

You can take the point-of-view elevator down (say, to the process for harvesting barley) or up (operating the Talisker distillery).  Processes go inside larger ones, link to others; an output here becomes an input there.

But you’re not getting the full picture.  You don’t know how you’re doing without feedback.  Thus items 7 and 9 on this diagram:

Looking for trouble?  A chart for examining performance

Item 9 on the diagram is feedback about the process (here’s how things are going).  You can see item 7 as both short-term and long-term feedback to the performer.  That’s the answer to “how’m I doing?”  (Sure, there’s crossover between the two, especially if it’s a single performer, but I was going for simplicity here.)

I talked recently with Dick Carlson about the backchannel.  He’s far more technically skilled than I am; he sometimes uses custom backchannel software in a session.  Each participate creates an anonymous ID (like, say, a favorite comic book character or root vegetable).  He displays the backchannel during the session, which means everybody gets to see when Granola&Grits says, “been there, declined the tshirt.”  Or when ParsnipAmazon says, “YES! ima usin this TODAY!”

Potential for an interesting bit of DIY research: do some sessions with the Veggie ID, others with name-based ID, then see if there’s discernable differences between the quality or quantity of feedback.  Okay, now, back to the post…

Not to say a backchannel is a requirement.  I have reservations, especially if most participants don’t have access to it–e.g., 60% lack devices to get to it. Shooting an anonymous remark into the stream is easier and potentially less intimidating than standing out by speaking up.

I’ve already said I’d be very distracted viewing a backchannel if I were presenting on my own.  Though on that topic, Aaron Silvers just today told me he found great value in reviewing a backchannel following a session he’d given.  During the session, he didn’t think he was doing that well, but what he saw in the stream afterward helped him see differently.

All of which is to say that software like Twitter is one way, not the way, to collect and retrieve feedback.  Which reminds me that collecting (storage) and retrieval (application) aren’t a bad way to think about the fundamentals of learning.

That’s my own “Looking for trouble?” chart.
My process diagram adapted from these CC-licensed images:
Ripening barley by net_efekt / Christian Guthier;
stills at the Lagavulin distillery by Freddie H / Frederique Harmsze;
glass of whisky by smiling_da_vince / Eelco.

Share
 

At GE Information Services, our Software Development and Consulting people were technical consultants, working with the client’s IT staff before and after a sale.  When we hired new SDC people, some hadn’t spent much time with clients; they’d dwell  on networking, data communications, relational databases, and so on.  And on.

So: Technical Presentations for a Non-Tech Audience. I never liked the title, but the SDC people did, which was part of the point: does the audience like it?   I needed a topic for which I was the technical expert and they were not.  That ruled out electronic data interchange, the OSI model, and systems architecture.

But not Elizabethan drama.  That’s how I started.

Where you are: How would you feel about knocking off early today to see a 400-year old play?

  • Maybe you like Shakespeare.  I can tell you that on a 10-point scale, where 1 meant “I’d prefer dental work,” the first SDC group came in at 2.5.

Where we’re going: I promised to explain why people in Shakespeare’s time would choose to see a play, when the other entertainments included bear-baiting and bawdy houses.

What you know: I asked what the SDC folks knew about the battle of the Alamo.

  • From the “pretest,” I knew there weren’t many Shakespeare fans.  This apparently unrelated question (Shakespeare?  Alamo?) nudged the attention knob higher.
  • What did they know?  Not many “factual” facts–date, numbers, causes.  Something about Texans, Mexicans, the 1800s,  overwhelming odds.  And maybe Davy Crockett.  Or John Wayne.

What you may not know: I spent about 5 minutes getting here, and took three more to make the connection:

  • Most Americans know few historical facts about the battle of the Alamo (like the date), but we know emotional facts.
  • Since 1836, people have made songs, stories, books, plays, and movies, each connecting the events of the Alamo to its audience, playing off those emotional facts.  (This is where John Wayne comes in, along with Fess Parker, Brian Keith, and Billy Bob Thornton.)
  • The battle of Agincourt — the heart of Shakespeare’s play Henry V – was roughly as far removed from his audience as the Alamo is from us.
  • The main difference?  At Agincourt, the Texans won.

This probably wouldn’t work for a multinational audience–those emotional facts about the Alamo are common in the U.S. but not in, say, Norway or New Zealand.  Which means it’s not the specifics of my story here, but what my audience already knew, and what I could use from that knowledge to to explain something new to them.

I went into details that fit the categories, to reinforce the connection.  Details like:

  • Factual facts about Agincourt (just a few, paving the way for what would follow), including  the 5,000 archers with longbows who were five-sixths of Henry’s army.
  • Emotional facts: everybody in Shakespeare’s audience “knew” Henry V had been a great king; everybody “knew” his army was vastly outnumbered; everybody “knew” the French were snobs.
  • Connections: examples of how Shakespeare started from these facts, like having Henry disguise himself as an ordinary soldier (“Henry LeRoy”) to check morale.
  • Features and benefits: everyone “knew” that Henry won not only the battle, but the daughter of the king of France.  Shakespeare plays off that by having Henry try to woo her, even though he can’t speak French and she “cannot speak your England.”

And of course, I gave a demo, with a little help from Kenneth Branagh.  (Right at the opening, there’s great exposition by Shakespeare, as the  earl of Westmoreland wishes for enough men to get the odds down to 2 to 1.)

Salespeople know the difference between features and benefits: a feature is a thing, like satellite radio in a new car.  A benefit is a value for the client, like tailored entertainment.  If the audience sees no value, a technical presentation isn’t much of a present.

Share
 

I’m reading e-Learning and the Science of Instruction by Ruth Colvin Clark and Richard E. Mayer.  I’ve admired Clark for years; she energetically and effectively applies research to the problem of learning at work.

One strategy they recommend for elearning (and that you’ll find applies in other situations) is the use of worked examples.

A worked example is a step-by-step demonstration of how to perform a task or solve a problem.

That means that in some cases, a worked example can look a lot like a job aid.  Especially for procedural tasks (those you perform the same way each time), worked examples are natural ways to show specifically how to accomplish some task.

Clark and Mayer offer four guidelines:

  • Replace some practice problems with worked examples.
  • Apply good practice when using text, audio, and graphics in worked examples.
  • Provide diverse, job-realistic worked examples to help build mental models.
  • Train learners to self-explain as they use worked examples.

Practice: less can be more

Remember homework?  It’s an attempt to strengthen the use of procedure skills.  Clark and Mayer cite research (as they do throughout the book) to suggest that you can save learning time by replacing some practice with worked examples.

“One [caveat] is that worked examples are only effective if the learner studies them.”  So design some worked examples as completion problems: partly-worked examples that the learner finishes.

Other approaches: make the worked example interactive — like, say, a widget that allows the learner to change one or more factors and see the result.

The authors point out that worked examples seem to benefit novices more than they do people already skilled in a topic.

The media can work

I heard more than an echo of Ten Steps to Complex Learning. (That’s no coincidence; the book cites research by Ten Steps co-author J. J. G  van Merrienboër.)  Clark and Mayer advocate applying sound principles for media use when you create worked examples.  For instance:

  • Integrate text with graphics; don’t restrict text to a caption at the edge.
  • Use audio to expand on visuals; don’t use it to narrate text on the screen.
  • Personalize.  Use conversational tone.  Use virtual agents (like a coach who addresses the learner).

Act like work

It’s almost depressing to think this point needs stressing.  When you create worked examples, make sure they involve realistic tasks that people face on the job.  (All the more reason to involve typical performers in the design, if you ask me.)

And vary the examples.  That’s more than changing the names; change the structure of the example.  Doing so helps you approximate the range of problems that show up on the job, where not everyone comes in asking the same thing.

…When teaching tasks that require judgment and problem-solving–tasks known as far transfer–more than one example will be needed…

Thre is no one right method for performing these tasks, since each job situation will be different.  Solving these far-transfer tasks, whether in highly structured domains such as programming…or in more ill-defined areas such as sales…requires more flexible knowledge in long-term memory.

Interestingly, worked examples help to lower extraneous cognitive load (the mental burden imposed by the course design).  A variety of examples adds to the intrinsic cognitive load, which can improve learning.

The idea is that the learner works at figuring out what the different examples have in common, and thus builds up her own mental model for the skills in question.

Do-it-yourself explaining

“Successful learners can explain worked examples to themselves, and their explanations focus on the principles behind the examples.”

So Clark and Mayer suggest that a virtual coach can demonstrate how to work through a worked example.  In other words, the worked example is an example of explaining a worked example.  From the text:

  • (Onscreen text in a quality-control unit)
    Take 4 sequential widgets off the line every hour for 24 hours.  These are your subgroups.
  • (Jim, the onscreen virtual coach, in audio:)
    First, I notice that the subgroups are selected on a regular basis–four in a row, every how.

So what?

Here’s what I think is worthwhile about the use of worked examples (and about the book generally):

  • It’s based on research, not someone’s preferred way to present.
  • It works for both procedural and non-procedural skills.
  • It suggests that design does, in fact, matter, so that even an advocate of informal learner can benefit by applying the principles to things meant to foster that learning
Share
 

Procedural steps to a desired result...

Long before I ever heard of Ten Steps to Complex Learning, I developed my own principle for helping people in organizations learn how to use software:

They’re applications.
Apply them.

What that means: people learn a software application best by applying it to work they want (or need) to get done.  Few things focus your attention on the details of Excel formulas, say, than having to produce something with a few of them.

Just as there are two sides to a web page–the content that you interact with, and the code that underlies the page–there are two sides to working with software.  Those are the how-to (the procedures) and the for-what (the desired result).

And the for-what is always contextual: it’s a goal that makes sense to the individual learner.

Don’t work on software; put software to work.

For one client, I was in change of training design for a gaggle of standard office applications and half a dozen client-custom ones.  The target audience: sales reps and their supervisors, most having no experience with personal computers.

During the pilot phase of training, we taught the off-the-shelf applications first. In part, that allowed more time for the developers to finish Legion, the sales-force automation system that would replace 80% of the sales reps’ paper-based procedures.

In part, too, I believed that having learned less “risky” software — programs that weren’t job-critical — the reps would have an easier time a month later when they returned to learn about Legion.

So…about an hour into my first session of Legion training, one of the reps  leaned back and shook his head.  (This was not a guy who’d had a good time in the “easier” training a month before.)

Escape from routine software training.“Geeze, Dave, why didn’t you teach us this stuff first?”

So much for my skill at instructional design.  I’d worried so much about the size and complexity of the Legion software that I overlooked the point I keep harping on here: the training isn’t about using software, it’s about doing work.

The sales reps already knew how to make sales calls, report findings, analyze accounts — they just didn’t know how to get that done with Legion. Why not have them use it as fast as possible?

Thank goodness it was a pilot.

In the redesign, the office applications got shoved to the second session of training.  For the first session, the sales reps spent about two hours on the basic basics: they individually unpacked their new laptops, connected everything, started them up, and learned the absolute minimum in terms of cursor movement, single click, double click, use of menus, and so on.

Next they had about an hour on email, which was new to them, and which provided a vehicle to practice basic editing (backspace, delete, insert, click-and-drag).

For the next two and a half days, they were working with Legion. And they were learning, mostly because:

We started with what they knew. Instead of talking about the Initial Account Data screen (the label from the IT folks), we used their own terminology: “Here’s the store profile.”

We didn’t spoon-feed. Instead of a mindless field trip ( “Here’s the name field.  The name goes here.  Next is the address field.  The address goes here…” ), we’d open a screen and ask questions:

  • Got the store profile?  Good–so what was last month’s volume?
  • Who’s the wholesaler for Acme Retail?
  • (And, to double-check) How do you know that?

We encouraged (or demanded) practice with what they’d learned.  “Okay, this is the wrong store code.  How do you change it?”  (The answer was to click a radio button.  We didn’t care about the term; we just made sure people clicked, and let the result be the reinforcement.)

We used their everyday tasks as the framework for topics.

“First, you need to plan your call list (the stores the rep visits each day visit).  And when you get to MegaMunch, you’re going to sell a JD-27 contract (which means the rep has to cancel the incompatible, existing contract).”

We provided both paper job aids and digital help for routine, procedural tasks.

And, to help transfer the learning, we had each sales rep bring paperwork for her last 10 store visits to the training session.  By the end of the second day, she’d download her entire territory from the mainframe, and then enter those calls.

It’s amazing how on-task and how collaborative a bunch of sales reps are when they’re messing around with their own account data.

CC-licensed images:
Origami by adobemac.
Keyboard by Nils Geylen.

Share
 

Someone asked about ways to help “virtual learners” — people learning through webinars and similar formats — get the most out of the experience.

I haven’t done many webinars, but I’ve facilitated other types of online learning going back to phone-only “teletraining.” For learners unused to webinars and similar non-classroom events, I see these questions:

  • What’s in it for me?
  • How does this thing work?
  • When do I start learning something?

Vision...objectives...Maslow...menu...navigation...yeah, yeah, yeahWhat’s in it for me?

My experience tells me that the average learner / participant / employee has virtually no interest in the underlying technology. The fact that it’s a webinar is about as important as the brand name of the computer that the facilitator uses.

(As evidence, look at your own reaction when an incoming message ends with “sent from my iPhone.”)

Thus a lot of talk about how to be in a webinar, no matter how well-intentioned, distracts from my hope that I’m going to learn something I think is useful.

Consider the much-maligned in-person lecture. If you find the content sufficiently compelling (like “how to negotiate a huge pay raise”), you’ll gladly put up with a dull presenter and those eternal PowerPoint bean people.

So my suggestion on this front would be to offer a brief, specific guide to how the webinar might work — say via a show-and-tell demo like this one for Evernote.  Specific.  And brief.

How does this thing work?

During the webinar, of course, participants aren’t going to recall everything they saw in such a demo. How do I raise my hand? Can I go back to some visual I saw earlier? Can I say something privately to the facilitator? To another participant?

(They will recall how to check their email, work a bit on the project that’s due tomorrow, and even check the news, so you don’t want to lose their attention too quickly.)

This kind of how-to support needs to be available during the webinar, in a form that the participant can use.

One idea is to make a short online job aid based on questions from actual participants (because you do pilot this thing with typical learners, right?). Then, instead of a lot of blather about how the webinar software makes things easy, helps you learn, and prevents dental cavities, the participant has something like:

  • How to change the size of the screen
  • How to ask a question
  • How to control the sound
  • How to send a private message to the facilitator

For heaven’s sake, don’t leave out the private-message guide; that’ll be the first thing they try.  Though probably not to the facilitator.

When do I start learning?

If this were classroom based, at least there'd be doughnuts.I think that many designers (like me) and many presenters (like me) have an almost irresistible urge to overexplain. We know a lot about the knowledge and skills in question, and we just love sharing what we know — in part because we enjoy the knowing, and we figure that others will, too.

It’s a natural error to make.

But just as learning is in the mind of the learner, so too is value. In the world of work, I believe that participants value things that look like they’ll make a difference in how they do their jobs.

The sooner you get to where people are doing things that look like useful work, the better.

In a classroom-training exercise, I once had to walk newcomers through a startlingly complicated process to set their computers up so they could access a report-generation system on a company mainframe. The pilot test helped me understand not only the pitfalls of the process, but also the high value of one particular online document.

That allowed me, in the revision, to frame it appropriately:

  1. Next I’m going to guide you through some complicated steps.
  2. It’ll take about 25 minutes to get through this stuff.
  3. When we’re done, you’ll be able to print a management invoice.

Previously, printing that invoice involved a telephone request to someone in another city. One participant literally jumped out of his seat and said, “God-DAMN! You’ve just saved me three hours a week!”

Now that’s a post-training evaluation: number of participants jumping out of seats.

CC-licensed images:
Woman at computer by Sarah M Stewart.
Woman with headset adapted from a photo by meddygarnet.

Share