On the job

Otherwise, it’s babysitting or psychotherapy.

Surgery via text message

 Improving performance, On the job
Feb 132012
 

(Click image for a downloadable version of the regulations on Scribd)

I have a collection of job aids, some going back more than 50 years.  I keep them for various reasons: some are amusing, many are creative, and all of them are examples of helping people to perform some task.

What makes a job aid a job aid?

  • It presents information that’s external to the performer.
  • It’s used on the job.  It’s part of how the performer carries out some task.
  • It enables accomplishment: when a person uses the job aid, he can accomplish some result that he couldn’t otherwise.
  • It reduces the need for memorization.

I use “memorization” here only as a label for some of what we call learning, which is storing certain knowledge in your memory so you can retrieve it and apply it in the proper context. (I know, I’m oversimplifying.)

Job aids, when used appropriately, offload some of the cost of memorization: instead of learning all the information or steps for some task, the person learns how to use the job aid to carry the task out.

Just as not every task is suited to job-aiding, not every person can use every job aid.  A job aid supports the performance of a particular job, or at least the completion of a particular task.  Implicit in that is a certain level of background knowledge and overall capability.  If you don’t know much about photography and digital images, than a job aid for some advanced feature in PhotoShop probably was not designed for you.

Please understand that I mean no offense, and realize I’m making a possibly unjustified assumption, when I say that you, esteemed reader, probably couldn’t make good use of a job aid for a forequarter amputation.

That’s the surgical removal of someone’s arm and shoulder.  It’s not a common procedure.  In the UK, doctors perform about 10 per year, mainly on cancer patients.

David Nott performed one, too.  He’s a vascular surgeon who volunteers with Médecins Sans Frontières (Doctors Without Borders).  In 2008, while serving in the Democratic Republic of Congo, he was confronted with a boy who’d lost most of his arm.  The child was at grave risk of dying; Nott knew the only procedure that could help him was a forequarter amputation.

As the  BBC reported, Nott believed he had the surgical skill but wasn’t sure he knew all the steps for this specific operation.  There was no way to get real-time support (say, over an open phone line).  So he contacted Dr. Meirion Thomas of London’s Royal Marsden Hospital, who provided performance support… via text message.

Click to view video on The Telegraph's site

Notice how Thomas’s instructions rely on skill and knowledge that Nott already had.  ”Cont(r)ol and divide (the) subsc(apular) art(ery) and vein” is one highly compressed step.  Professor Thomas knew that the intended performer could get around the typo, could identify the vessels, and would know the meaning of “control” and of “divide.”

Nott told The Telegraph he was able to carry out the three-hour procedure thanks to the guidance, which is one of the truly distinctive job aids in my collection.

Share
 Posted by at 9:30 am  2 Responses »

Flight 1549: Expertise and how it gets there

 On the job
Feb 032012
 

On January 15, 2009… US Airways Flight 1549…experienced an almost complete loss of thrust in both engines after encountering a flock of birds and was subsequently ditched on the Hudson River about 8.5 miles from LaGuardia Airport (LGA), New York City… The flight… had departed LGA about 2 minutes before the in-flight event occurred.

That’s from the 200-page report (NTSB/AAR-10/03) issued by the National Transportation Safety Board. Among the reasons I’ve been reading the report is to learn more about the interplay between training, learning, performance support, and the environment in which this emergency took place.

The NTSB report cites four major factors contributing to the survival of all 150 passengers and 5 crew members:

  • The decisions and “crew resource management” of the flight crew
  • The airplane itself, which was equipped with forward slide/rafts although these were not required on this flight
  • The performance of the cabin crew in expediting the evacuation of the airplane
  • The proximity and rapid arrival of emergency responders

A quick timeline:

  • At 3:24 p.m. Eastern time, the tower cleared 1549 for takeoff.
  • At 3:25:51, the captain reported the plain was at 700 feet, climbing to 5,000.
  • At 3:27:10, “…the captain stated, ‘Birds.’ One second later, the CVR [cockpit voice recorder] recorded the sound of thumbs and thuds followed by a shuddering sound.”

The report notes that the altitude was 2,818 feet and that engine speed started to decelerate.

  • At 3:27:23, the captain took over control of the plane from the first officer, telling him, ”Get the QRH [quick reference handbook] loss of thrust on both engines.”

Captain Chesley Sullenberger later reported that when he said this, First Officer Jeff Skiles already had the checklist out–showing how the two worked smoothly throughout the emergency.

  • At 3:27:50, the first officer began calling out steps in the Engine Dual Failure checklist.
  • At 3:29:11, the captain announced to the cabin, “Brace for impact.”
  • At 3:30:41: the cockpit equipment broadcast “a 50-foot warning.” The flight data recorder reported 33 feet.

From impact to ditching, about three and a half minutes.

Who Does What, and What Gets Done?

In an interview with Air and Space Smithsonian, Sullenberger discussed his collaboration with First Officer Jeff Skiles. Typically, he said, the first officer flies the plane, and the captain monitors.  In this case, “even though Jeff was very experienced…[with] as much total flying experience” as Sullenberger, it was the first time Skiles had been on an Airbus A320 since training.  So Sullenberger decided “we were best served by me using my greater experience in the [A320] to fly the airplane.”

I also thought that since it had been almost a year since I had been through…recurrent training, and Jeff had just completed it…he was probably better suited to quickly knowing exactly which checklist would be most appropriate, and quickly finding it in this big multipage quick reference handbook that we carry in the cockpit.

Checklists and Focus

The NTSB report, in Appendix C, reprints the three-page Eng Dual Failure checklist.  Skiles and Sullenberger lacked time to get through more than the first page.  As it is, the checklist notes “optimal relight speed” [for the engines] is 300 nautical miles. Skiles at the time said, “We don’t have that.” The report states that the maximum airspeed after the bird strike was 214 knots.

The checklist also assumes far more altitude than 1549 had.  Step 3, on page 3 of the checklist, starts with what to do above an altitude of 3,000 feet.

Accidents and incidents have shown that pilots can become so fixated on an emergency or abnormal situation that routine items (for example, configuring for landing) are overlooked. For this reason, emergency and abnormal checklists often include reminders to pilots of items that may be forgotten. Additionally, pilots can lose their place in a checklist if they are required to alternate between various checklists or are distracted by other cockpit duties; however, as shown with the Engine Dual Failure checklist, combining checklists can result in lengthy procedures. [NTSB report, p. 92]

It seems clear to me that both captain and first officer believed that the engine-failure checklist was the best procedure to use.  While there is a procedure (a checklist) for ditching the A320, 1549′s crew never got to use it.  ”Time would not allow it,” Sullenberger said in the A&S interview.  ”The higher priority procedure to follow was for the loss of both engines.  The ditching would have been far secondary to that.”

Elsewhere the report notes that  ”low-altitude, dual-engine failure checklists are not readily available in the industry” — in other words, this is not limited to US Airways or to Airbus.

Adding to stress for the flight crew was an array of alarms and warnings.  The ditching checklist, which they had no time to consult, included steps “to inhibit the ground proximity warning system and terrain alerts.”  In other words, since you know you’re ditching, you can shut these alarms off.

Training

According to the NTSB report, training at US Airways for dual-engine failure involves a full-flight simulator in which the failure occurs at 25,000 feet.  No training scenarios involve “traffic pattern altitudes,” which I take to mean “near airports.”  In addition, “dual-engine failure scenarios were not presented during recurrent training.” A similar approach is true for Airbus’s training.

The outcome

Sullenberger, Skiles, and the cabin crew (Sheila Dail, Donna Dent, and Doreen Walsh, each with at least 26 years’ experience with the airline) worked together to save the lives of 150 passengers.  Media reports tend to concentrate on the pilot’s actions, which were essential, since together with the first officer he was able to ditch the plane in a survivable manner.

The NTSB report notes that the accident “has been portrayed as a ‘successful’ ditching.”  It notes that the success “mostly resulted from a series of fortuitous circumstances” including these:

  • An experienced flight crew
  • Good visibility and calm water
  • Extended-over-water equipment (e.g., rafts) on the plane though not required for this flight
  • Nearness of vessels and responders available to rescue passengers and crew

Complex skills are…complex

I don’t have grand conclusions to put here.  I do think that the Sullenberger interview, and the details in the NTSB report, provide more balance than many mass-media “miracle on the Hudson” reports.  Clearly a success, in that everyone survived.  The causes of that success, and how to increase the likelihood of similar success in the future, are much more complex.

For example: Sullenberger at one time was a glider pilot.  A&S asked how that experience helped him.  ”I get asked that question…a lot,” he said, “But that was so long ago, and those are so different from a modern jet airliner, I think the transfer [of experience] was not large.”

For all of 1549′s crew–in the cockpit and in the cabin–performance resulted from experience, and experience was shaped not only through time in the air, but through regular training intended to focus on critical events, to provide feedback, and to increase the likelihood of success in critical, unpredictable situations.

Consider by way of contrast a large group of untrained people: only 77 passengers (just over half) evacuated with their seat cushions.  This seemingly small element is a performance challenge: most passengers pay little attention to the safety briefing, and almost no one reads the safety card.  The NTBS report suggests that those who took cushions did so because  all preflight briefings point out that the cushion “may be used as a flotation device.”  In other words, some passengers were apparently habituated to that information and able to recall it when needed.

Life vests were not mentioned in the preflight safety briefing because 1549 was not an “extended overwater” flight.  19 passengers attempted to retrieve life vests from under their seats; only 3 “were persistent enough to eventually obtain the life vest.”  30 others tried to put a vest on once outside the plane, but only 4 said they were able to do so properly.

Small, regular deposits

You’d be hard pressed to find a better summation of building your own expertise than the way Sullenberger expressed himself to Katie Couric of NBC News:

One way of looking at this might be that for 42 years, I’ve been making small, regular deposits in this bank of experience, education, and training. And on January 15 the balance was sufficient so that I could make a very large withdrawal.

 

Share
 Posted by at 9:08 am  8 Responses »

Working at learning, or, pluggin’ for results

 Learning, On the job, Tech, Tech tinkering
Jan 042012
 

When I read about the Organize Series plugin for WordPress (a focus of Monday’s post), I thought, “This could do it.”

No I didn’t.  I don’t know about you, but I rarely think to myself in complete sentences.  Phrasing like this is how we capsulize a more complex experience.  What I believe was going on at the time was something like this: I had a situation I wanted to change (the way I used to manage a series of posts here on my blog no longer worked). And the Organize Series plugin at first glance looked like it could accomplish at least two things:

  • Provide automatic navigation between posts in a series (so I wouldn’t have to hard-wire the links).
  • Display a list of all the posts in a given series (for me to use as a summary or as a table of contents for the series).

If I’d thought about it longer, I might have articulated another goal: have some way to list all the different series I have.  But I’m not usually that strategic.  Still, what I came up with (provide navigation, display a list) acted as my critical-to-quality elements.  CTQs were widely used at GE when I worked there; I use that acronym partly tongue-in-cheek and partly to highlight informal criteria.

So, I put Organize Series to work, and within 10 minutes I had automatic next/previous navigation for posts in a series, along with an indication that they were part of a series:

No, this isn't the entire post.

(You can click the image to see the entire post.)

When I was still considering whether to use the plugin, I said to my wife, “Wouldn’t it be great to know how to write a plugin?”  On reflection, I realize this statement was another capsulization–a series of them, nested inside each other.  ”Know how to write a plugin” really means:

  • “Know how to write a plugin” really means “write a plugin that works….”
  • Which in turn means “write one that produces results…”
  • Which means “write one that people use to accomplish things that matter to them.”

To me, this is an important distinction for workplace learning: You can learn on your own for your personal satisfaction, and if you’re satisfied, then that’s a sufficient result.  In the workplace, though, you’re part of a larger group (even if that group is you and one individual client), and so the result has to matter within that context.

What’s this got to do with my plugin tinkering?

Think of it as my own workplace learning.  At this point, I was still some distance from my (loosely articulated) end state.  I hadn’t moved much toward my other CTQ of displaying a list of all the posts in a series. In fact, I didn’t yet grasp all the options in the plugin, let alone know how to make them work in a way useful to me.

I only put this here to scare you a little.

About 5% of the info from the plugin's page of options

But…In my first 15 minutes with the plugin, I’d achieved a result that I found valuable.  That left me more willing to experiment–which, put another way, says I was somewhat more willing to spend time trying to achieve the next valuable result.

To me, this is a core principle for any type of workplace learning: formal or informal, face-to-face or virtual.  I need to be able to accomplish something that looks to me like real work–produce something that I see has having on-the-job value.  And I need to do that sooner rather than later, which is why twenty minutes on introductions, half an hour on expectations for this workshop, and twenty minutes on learning objectives will invariably drive me to teeth-clenching frustration. Or to eating more of those lowest-bid-hotel pastries.

One of the unexpected outcomes of achieving an initial on-the-job goal is that you end up better able to visualize other goals.  In a sense, learning leads to new problems (or opportunites) because you’re better at grasping the current situation and at visualizing different ones.

In the course of my experimenting with the Organize Series plugin, I did find at least one way to display a list of all the posts in a series.  I can make a box like this appear alongside the title for each post:

Example of a 'series post list box' - a box listing posts in a series

The posts in my most complex series

You can click that image if you’d like to see the first post in the series, though I’ve turned this “series post list box” feature off for now, until I learn how to control the way it displays.  Having managed to produce it, though, I’ve picked up several more goals for myself.  I was about to write “learning goals,” but I want to stress that they’re all tied to accomplishment.

  • I want to learn how to use code that’s part of the plugin to, for example, display a list of posts like the last example where and when I want it.
  • I want to find out how to modify the plugin’s template (the tool it uses to display the full text of all the posts in a series).
  • I may even want to learn how to modify the PHP or CSS code to make things happen.

That last is quite a goal for someone who doesn’t really know how to program.  But my various experiments to date, and especially the things I see as successes, have taught me that I can learn to successfully modify small bits of PHP code and achieve relatively high-value results.

So I’m accomplishing what looks like real work to me.

 

Share
 Posted by at 7:43 am  2 Responses »

Training trains, or, en route to better performance

 Learning, On the job
Jun 132011
 

Stakeholders raising a few points.Somewhere, yet another big organization is working on yet another big computer system.  Legions of stakeholders are fussing about what the system needs to have if they’re going to get their real work done.

Few of them, alas, are making the case for a robust, easy, and safe way to practice.  A shame, considering the universal desire to have people learn such systems.

Instead, people are mired in situations like a financial services project I worked on.  Its banking module, used by the people at a branch, enabled them to electronically open accounts for a customer, transfer funds, and handle loan applications.

But there was no way to practice those tasks.  If you wanted to get skilled at, say, processing an auto loan, you had to process an actual one–preferably for yourself, so you wouldn’t need someone else’s Social Security number.  You couldn’t complete the transaction.  Well, you could if you were actually getting a car loan.  Seemed like a mighty rigorous prerequisite.  And training people to do A, B, but not C — quick, hit cancel! — is disconcerting.

Forest, trees... the details are in the project log.A practice system, like its first cousin, a test mode that truly works like the actual system, is a kind of performance-support forest that companies can’t see because all the stakeholders are focused on the system-spec trees.

When I managed online training for Amtrak’s reservation system, we inherited three imaginary trains that agents could access with a training ID. Granted, learners could reserve seats and sleeping compartments, but not much more.  And the practice provided was suboptimal.

Each imaginary train had a consist (a set of cars, with passenger accommodations), but there was no automatic cancellation of the fictional reservations.  In other words, the imaginary trains could sell out.

No way to run a railroad.

As for transferring skills, the trains didn’t follow any actual Amtrak route.  One went from London to Rome; Another, from London to Dublin–by way of Donegal.

More to the point, pretty much all you could do was reserve space.  You couldn’t calculate fares, in part because Amtrak didn’t have fares on the London-Donegal Express, but also because there was no connection between the imaginary trains and other parts of the system. Like fares.

During my time as head of online training , we decided to do better.  Leslie, who’d been a reservations agent, worked with John from the Train Operations group.  I’ll discuss specifics not because you need to know about Amtrak reservations, but to show the kinds of factors to consider when planning a sturdy practice system.

Realism: Leslie and John created training trains based on real ones: they cloned trains 3 and 4 (Chicago – Los Angeles) as 9003 and 9004 (no real-world trains had numbers in the 9000s).  Same cities, same accommodations, same schedule.

Coverage: They identified all the different types of Amtrak accommodations, then created training trains to include them all.  They took in geographic routes, so that while they didn’t duplicate the entire Amtrak system, they had trains in every part of the country.  This country.

Without the chance to practice, results are a toss-up.Integration: the training trains got their city information, schedules, accommodations, and fares from the live system. When the fares changed on the real route, they changed on the training trains as well.  The training ID could access all the information-only parts of the system: fare quotes, current train status, and the like.

Resilience: you could make as many reservations as you liked, for whatever day you liked. At midnight, they’d all get purged, so as not to clog the system with imaginary trains filled with imaginary passengers.  And for entire new services, we could clone another real-world train and launch it in the training environment.

Security: we built in safeguards against error.  If you logged on with the training ID, you couldn’t reserve space or issue tickets on real-life trains.  Your real-system ID would not let you use or even display the training trains.  The burden of requiring  a training ID for practice was low, and the separate systems meant that even if you forgot which mode you were in, you couldn’t do anything harmful to a real reservation.

Continuing the security angle, you could make ticketing entries on the training trains.  That means you could pull up a training-train reservation and tell the system you were issuing tickets.  You couldn’t print the tickets, though, and the financial system ignored “sales” on the training trains.

What did Amtrak get out of this?

  • Any Amtrak ticket clerk or reservation agent (more than 2,000 people at that time) could practice virtually any entry, or combination of entries, via the training trains.
  • The new training trains, based on real-world routes, reinforced the layout of Amtrak’s route structure.  You could work with complex fares and experiment with complicated connections.  You could also build skill with accommodations or trains, like Metroliners, that you might not encounter often.
  • As new features went into the live system, they were available immediately in the training system as well.

Safe practice in many live systems is harder than it should be.  Often “harder” means “not possible.”  Less-safe practice can mean goofy messages going to customers.  Phantom sales inflating revenue.  Accidental cancellations of live orders.  Triple demand for supplies.

No matter how firmly your company insists on formal training, your learners and the entire organization  can benefit from support provided on the job by a realistic, feature-rich way to practice skills.

CC-licensed images: a few stakes by TonZ;
log slices by the queen of subtle;
caber toss by notacrime / Gregor Dodson.
Detailed map of the London-Dublin Express is mine.

Share
 Posted by at 10:17 pm  2 Responses »

Management skills, or, monkeying around at Google

 On the job
Mar 142011
 

An article by Adam Bryant in the New York Times deals with Google’s “quest to build a better boss.”  Bryant looks at an effort by Google to mine its own data and figure out what made people better managers.  The list of behaviors, Bryant says, looks “forehead-slappingly obvious” :

  • Have a clear vision and strategy for the team.
  • Help your employees with career development.
  • Be a good communicator and listen to your team.

(From the Times, a fuller list of eight good behaviors and three pitfalls for Google managers.)

More important is the source of the ideas, and especially their relevance to managing at Google.  The company collected data from a range of observations about its own managers: performance reviews, feedback surveys, and so on.  They coded that data to help uncover patterns.  They conducted interviews with managers to collect more data.

One thing they found that they hadn’t expected: a manager’s technical expertise ranks “dead last” among the eight behaviors they uncovered.

What employees valued most were even-keeled bosses who made time for one-on-one meetings, who helped people puzzle through problems by asking questions, not dictating answers, and who took an interest in employees’ lives and careers.

One drawback to lists of management behaviors like this one is a sort of horoscopic skew: you skim the list and decide that the ones that stand out are the ones that apply to you.  So a person who prides himself on his technical background might believe that as manager of technical people, he or she needs to have high tech skills.

That may be true on a project team, but to the extend you’re really managing, I don’t think so.  Think of the tongue-in-cheek definition of manager as “someone who gets other people to do the work.”  In a sense, that’s true: the manager is a kind of executive producer, helping to create the conditions in which the group can best accomplish its goals.  An often-overlooked aspect of that is acting as a non-judgmental resource to help people figure out how to solve their own dilemmas.

This is one of the main points of a classic article by William Oncken, Jr. and Donald L. Wass, Management Time: Who’s Got the Monkey? (PDF).  They compare business problems to monkeys, and discuss ways in which subordinates try to put the monkey on the back of their manager.  Here’s a manager who’s working at empowering his staff (which is where most of the problem-solving should occur):

“At no time while I am helping you with this or any other problem will your problem become my problem. The instant your problem becomes mine, you no longer have a problem. I cannot help a person who hasn’t got a problem.

“When this meeting is over, the problem will leave this office exactly the way it came in—on your back. You may ask my help at any appointed time, and we will make a joint determination of what the next move will be and which of us will make it.

“In those rare instances where the next move turns out to be mine, you and I will determine it together. I will not make any move alone.”

- Harvard Business Review, Nov.-Dec. 1974

Granted, you need to ignore a certain assumed hierarchical bias in HBR articles.  Even so, I’d argue that this, too, is head-slappingly obvious.  But “obvious” is often an after-the-fact label.  It’s easier, more dramatic, and perhaps more fun to pound the desk, to shout, and to act in general like a BlackBerry-toting gunslinger than to do the persistent work of helping people achieve the best results they can.

Share
 Posted by at 12:58 pm  No Responses »
 Older Entries