Adding pragmatics to training: Example lesson

It's great that the field of pragmatics is getting so much attention in Business English at the moment.  I see the Chua Suan Chong gave a presentation on the topic at IATEFL Manchester. And over the last several years, I have been talking with Ed Pegg from The London School of English about the issue, especially as it pertains to the soft-skills aspects of his training.  We see it as an important aspect of the training and perhaps something which is either misunderstood or under-represented in training.

In fact, I am not completely clear about how to integrate the 'meaning derived from context' into my training.  I am not educated as a linguist and my knowledge in pragmatics is less than expert to say the least.  Luckily, I have access to the Journal of Pragmatics, but my general thinking comes from Steven Pinker.

But I decided to give it a try with a controlled scenario and topic... namely giving tasks to others and politeness.  This is a good situation because the situation is easily identifiable and there are normally only two people involved.  Second, forms of politeness are probably the simplest form of altering language to fit the relationship and situation; it can done at sentence level.

The lesson

Participants:  2-6
Time:  60 minutes
Level:  B1 and above
Training aids:  whiteboard/flipchart

Training objectives:
- be able to give clear tasks and instructions which include task, method and outcome
- be able to encode the imperative based on the relationship/desired relationship with the audience
- understand how language conveys both content and interpersonal information

Method: presentation with open questions/discussion, modelling and practice

Step 1 - The structure of giving tasks

Note: This structure is based on the military standard of task, condition, standard for giving tasks/orders.

With 60 minute lessons, we don't have a bunch of time for all that schema activation rigmarole so I tell them that we are going to look at the language for giving tasks.

I write the three steps on the board with space in between:
1.  Clear task statement
2.  Method (tools, resources, etch.)
3.  Outcome (expected result, timeline)

We talked about the consequences for productivity if one of these items is missing.  We all shared examples where one element was missing and how it could cause confusion or some mismatch between the expected outcome and the actual result.

My example: I work embedded in a team and we have worked out a standard method for giving component status updates during their weekly engineering steering meeting with the full development team.  One week, a peripheral member of the team was asked to give an update on his component.  It was a very nice presentation but it did not fit the group norm.  The standard is 1-2 slides, both of which have agreed upon templates, content and style.  The update should take 5-7 minutes with questions and discussions taking 5-10 minutes longer.  His presentation was well done but didn't follow the template, went into too much detail and took over 20 minutes.  He not only wasted the time of others but also his own by preparing such a long slide deck.  He had been given the task, but not the method (the template) or the outcome (the group expectation).  This caused a slightly embarrassing moment as the manager had to remind him at the end of the presentation to watch the video I created with guidance and ask the others for advice on how we do things.

This is the communication skills section of the lesson.  But as a BE Trainer, my job is also to take it to the next step and break this down to sentence level.

Step 2 - Task and method verbs

The next step is to fill the steps with language.  I focus on the verbs.  I explain that some verbs make good task statements and others don't.  We should use verbs with a clear outcome like present, report, test, make, create, design, etc.  We should not confuse them with method verbs like consider, talk to, contact, think about, discuss, use, compare, etc. which do not have a clear outcome.

This learning point often generates a little discussion because it is common practice in the company for managers to confuse the two, especially the word discuss.  Then they often wonder why there is no tangible outcome.

To close this section, I write a few example task and method sentences on the board for demonstration (in imperative form).

They practice this by giving me/their partner tasks from their work.

Step 3 - The communication model

With these established, I draw a simple sender-receiver model on the board.  I use light bulbs and binary to represent message and encoding/decoding.  I explain that in the best case the receiver's light bulb is the same size and color as the sender's light bulb.  To do that we encode the message, which we have just done by giving it structure and words.

But then I change marker colors and explain that we also encode messages to deal with the relationship with person.  This can be independent of the content.  I draw a second set of binary (encoding/decoding) to show this second layer of communication.

In some groups the discussion moves into eliciting feedback or getting a backbrief from the receiver to ensure the meaning has been transferred accurately.  This is a common question/problem, but it is only a secondary aim of this training session.

Step 4 - Changing politeness

Using the relationship color, we add phrases and formulations to change the imperative task and method sentences.  I add them on a continuum from most polite to more direct.  The usual suspects arrive on the board like "Would you please..." and "We would like you to...".

The board then looks like this:

This is when things get interesting because as we increase in politeness, the formulations move from command form into either requests or suggestions.  It starts the longest part of the lesson as we discuss and debate situations in which to use these different formulations, how they can change even with the same person, etc.

One issue we discussed at length was whether the receiver would understand the request and suggestion forms as an order, or merely an option.  In other words, would they work?  Of course the answer to that depends on the situation and whether the relationship was dominance, reciprocity or communality.

Another that came up is how relationships can shift and change.  For example, sometimes the participants and I have a reciprocal relationship, but that during this lesson, I was in a position of dominance because I was the content holder.  They were the recipients and even the setup of the room gave me the dominant position (at the board, standing, all eyes on me, note taking).  At that moment, it was perfectly acceptable for me to use the raw imperative to give them instructions.

A third issue was to discuss how the encoding is not just a product of the relationship and context, but also helps define the relationship.  We brought out examples in which the relationship is unclear, such as when they communicate with the engineers in China.  By using the imperative (or even the 'please version') we sending interpersonal information.  It seems to create a subordinate role for the Chinese and what happens when we want to change that role?  More importantly, how do they feel about that role?

One discussion went into learning pragmatic understanding.  We all laughed at how children do not understand the request and suggestion forms as a command.  They view it as license to do what they want.  We talked about how we knowingly teach this to our kids.  I used this as an example that we all have the ability to understand pragmatics from our native language.

Another point we discussed is dealing with low-level speakers.  We agreed that in the case of low-levels, we can use a more direct form to assist comprehension, but that we should also plant these sentences in other words/body language to convey the desired relationship information.

A final topic we discussed was how switching occurs within formalized relationships types.  For example, why do some managers encode orders to their assistance as requests even though both sides are fully aware of the dominant relationship?  This corresponds to whether the request and suggestion forms would be understood as the commands they really are.  A second example is what happens when a team member is promoted from within to lead the team.  In that case, the new leader has to 'work down the ladder' because an immediate use of the straight imperative can cause awkwardness and animosity.

Throughout the lesson, whenever there was uncertainty or a debatable issue, we acted out the situation at hand and gathered group feedback on how it felt and whether it was appropriate.  The task structure is very simple and requires little prep.

So as you can see, there is a lot to discuss here.  I reminded every group that the best communicators are the ones who can adeptly switch encoding depending on the situation and the audience.  Furthermore, learning these concepts helps open the door to future training in more complex situations.  I can now link this with formality, genre and tone.

So far, I have used this lesson five times.  Each one was slightly different, but I am extremely happy with the results.  The participants were fully engaged, they included repetitive practice of the learning points and I believe they now have a basic understanding of how language affects relationships.  Perhaps I have stumbled upon a nice method for bringing pragmatics into the classroom.