Show or Tell, or Don't just do something, stand there!

 I don't think that you have to tell people everything. First off, of course, you can only tell people anything if they're interested in it (or you can tie it to things that they're interested in). But, even then, "show" is often better than "tell". And, sometimes you don't need to do anything because people will figure it out for themselves: all you could do is muddy the waters.

For instance, in the SOA course one of the important distinctions that needs to be made is between a "service" and an "operation." The course has an activity where participants have to come up with a list of services. I was concerned that, in this activity, participants would include operations among their services. I wanted to forestall that.

My first thought, of course, was to provide a formal definition of "service" and "operation." The problem was that I couldn't come up with any set of words that I thought would actually be helpful to participants when they were trying to make the distinction. So I decided to finish up the definition by providing a set of examples. After reviewing those examples, I would present a set services and operations mixed in together and ask participants to mark which were services and which were operations.

This is all standard instructional design: provide the training, demonstrate the training, let participants exercise the training while providing coaching to fix any misunderstandings that are exposed.

But, quite frankly, I didn't think my "training" was providing any value. This activity occurs very early in the course when participants' understanding of "what a service is" is still pretty hazy. Piling on more definitions of more abstract terms was going to make things muddier rather than clearer.

So I considered just going straight to the second list of examples and asking participants to pick out the services. Participants had seen some examples of services at this point in the course and I thought the success rate would be pretty high. This time, the problem was in my examples: They were all pretty lame. And, quite frankly, understanding the examples to determine which were services and which were operations required some business knowledge. It seemed to me that if I took examples from a part of a business that participants weren't familiar with....well, they'd have a hard time figuring out what I was talking about, let alone deciding if I was talking about a service.

Then it occurred to me that the activity I was obsessing about required participants to list services: The participants would be generating their own examples. I could just circulate among the teams during the activity (there would only be three to five teams) and do some personal coaching to resolve any problems. I could leverage examples that meant something to the participants to make the distinction. This was brilliant!

Except that the problem never came up. In class, for whatever reason (perhaps because of the example services shown earlier in the course), the participants never seem to have the problem that I worried so much about. Asked to generate a list of services (and not operations) the teams almost invariably generated a list of services (and not operations).

So far, there's been exactly one team in exactly one class that inadvertently put an operation on their list. I jumped on that opportunity and just coached the hell out of it. I think the team thought I'd lost my mind.

(the subtitle for this post comes from a wonderful book by the choreographer Doris Humphrey: The Art of Making Dances. She has a list of rules in that book that, while they apply to making dances, also apply to many other things, including technical writing and instructional design)
 
Reading or read

• Doghead: A Novel by Morten Ramshead
• Unto a Good Land by Vilhelm Moberg 
• Wellington's Smallest Victory by Peter Hofshröer