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.

Life inside a virtual team: Communication, language and culture

I have had the opportunity to work in or observe countless virtual teams over the past 15 years. From the military, an online degree program and my in-company work, it is clear that virtual team communication is a critical component of success in international organizations.

Over the past two years, I have largely specialized my training to deal with the unique challenges virtual teams face.

So let's look at a few of the key factors which support or hinder communication in virtual teams.

1.  Technical Skills

The members of a virtual team must master a range of technical applications to communicate effectively. Often this is taken for granted and the team members have only a superficial knowledge of communication tools.  Additionally, team members tend to rely on communication methods they use to enhance face-to-face communication in the local workplace (dear email, I am talking about you).

Here are some examples of technical skills which can support better virtual communication. But of course, this is not all.

• Use all the tools in virtual meeting software (and no, companies do not use Skype).
• Create PowerPoint slides which are designed to be read and not presented. This includes things like inserting documents and objects into slides, drastically changing formatting, etc.
• Create and manage an organized document library, including naming standards, types, searchability, etc.
• Use graphics tools like MS Visio to create diagrams (preferably those linked to data).
• Troubleshoot and diagnose technical issues like bandwidth limitations, audio and video problems, etc.
• Create and maintain a team website/portal in applications like SharePoint or SalesForce
• Use the complete functionality of Outlook

2.  Communication Channels

Understanding communication channels within organizations has always been an important part of collaboration and communication in teams, but it is especially important in virtual groups. I notice that virtual team members and managers do not completely understand the communication channels within their organization or how to change them.

Employees talk about long (or non-existent) feedback loops quite often without understanding the communication exact 'workflow'. Virtual team members typically complain about lack of information without seeing the number of stops between the origin of the information and their location in the social network.

A lack of understanding of how information flows through the team leads to unnecessary and unproductive meetings, massive communication overhead among network nodes, and a lack of information transparency among the team. The result is often redundant work and even unproductive affective conflicts between team members.

3.  Stages of Team Development and Team Dynamics

Many managers these days are trained in team building and educated in how teams change over time.  But in reality I see a couple of things happening. First, virtual groups evolve into teams and aren't expressly formed. For example, a team in India begins as an 'internal supplier' for a team in the US. The Americans send clearly defined workpackages to the Indians, which are then completed and sent back as deliverables. But over time, the two groups start working more closely together and eventually collaborate on a new product innovation jointly. The result is a team. The manager and the team members likely didn't even feel the change because it happened gradually and we cannot point to specific formation.

Second, managers attempt to copy team development strategies from their co-located teams in the past. They organize kick-offs and team building activities. They create team rituals and talk a lot about values and mindset. This is valuable of course, but virtual team development faces some unique challenges the managers and members are unprepared for. Especially in building trust, the written word of email leaves a lot of space for misinterpretation and I see that virtual teams move a slower through Tuckman's stages than co-located colleagues.

4.  Culture

Everybody likes talking about culture these days and I can see why. After all, you can explain nearly any misunderstanding or awkward moment simply by saying, "It must be the culture." But let's take a step back here for a moment and look at this sentence for the cop out it really is. From my observation, nearly all misunderstanding and awkward moments are caused by something other than culture.

• Okay, so he didn't respond to you email. - Not culture, he's busy and you're not a priority.
• She always goes off on a tangent. - Guess what... she does that with everyone.  Not culture.
• They are always very direct. - Well, they are working in a second language and the meeting is only 30 minutes long. They are trying to avoid a misunderstanding and get things done. Not culture (well, okay some might say there is some culture here).

Now, I am not saying that culture does not play a role in virtual teams. I am sure it does, but let's not place the culture label on everything. One problem with culture is the national culture idea. Research like Hofstede and Trompenaars is based on huge sample sizes to draw conclusions about values, tendencies and behaviors. But in virtual teams we are talking about individuals with distinct backgrounds, goals and personalities.

My clients don't need to know how to convince 'Germans', they need to know how to convince Anja, Thomas and Hans. I'm not advocating the abolition of country-specific culture training, but it should certainly include a large warning label, "Some or all of this may not apply to the person you are talking to. If in doubt, get to know the person." Character assumptions are the fastest way to make someone not like you.

There is another aspect of culture which plays a role: company culture. Employees are sick of hearing about it because I think every company in the world is trying to refine it, change it or implement it. They are largely numb to the whole topic, but there is a certain 'way of doing things' in companies and departments. Organizations have values, methods and rituals. If you want to improve communication in a virtual team, it might be helpful to look at how it works in the local offices, not a generalization about the whole country. (I have been guilty of this in the past... lesson learned.)

5.  Communication Norms

Building on points 2, 3 and 4, we come to communication norms.  Communication norms consist of agreements on channels, methods and formats. At the lowest level we are talking about terminology. At an organizational level we are talking about the project communication plan. Somewhere in between we look at things like slide templates, forms, collaborative document set up, standards for correspondence, meeting agendas, etc.

The local team members come into a virtual team with certain communication norms like how they report information, what meetings look like, etc.. Often, these norms are incompatible and virtual teams need to compromise their norms. At a low level, we may agree (explicitly or implicitly) on certain vocabulary and terms. At a larger level, the group may agree on norms for meeting presentations (e.g. no more than 10 minutes).

The point is that norms will emerge. The key is making sure they are appropriate for the group. One type of meeting agenda may work great in a face-to-face setting, but fall flat when we have a large virtual meeting.  That report structure may be perfect for stimulating discussion at the home office, but might not include enough information to be shared to a distributed team.

I see that managers and employees take norms for granted and several things happen.

• The team does not discuss the norms, which results in ambiguity (no meta-communication)
• The team adopts norms from one location which are ineffective (e.g. bad meeting styles are copied into the virtual team)
• The team adopts norms which do not fit the communication tools and methods
• Team members and managers do not hold others accountable when they violate the norms (e.g. no one says anything when the presenter takes too long)

6.  Language

This is typically the default diagnosis (along with culture) for why many virtual teams are underperforming. And managers and team members are not completely wrong. Communication in a second language takes more time and effort than in a first language. Meetings are longer or cover less content. Proper understanding often takes more repetition (either synchronously or via follow up correspondence). Writing takes longer, including emails, reports, documentation, etc. But where there is the will and need to communicate an idea, there is a way. Teams make it work, but it is frustrating and puts pressure on their already busy schedule. After all, project schedules and team goals are set on the assumption that worker efficiency is constant.

The magic level seems to be around B1-B2. Team members who are lower than B1 cost the team efficiency and time. Due to poor comprehension, meetings have to be slower and the communication overhead is higher for repetition and follow up. On the other side, the team suffers from their inability to contribute effectively - costing time and energy. Notice, I am talking about the communication workload on the whole team, not just the low-level speaker.

At B1 or B2, the team is generally able to coordinate action effectively if the right norms, channels and strategies are used to accommodate the distributed team set up and language burden. Groups of workers at this level are able to achieve L1-like efficiency under the right conditions. Team members in the B2-C1 levels are instrumental in helping to set up these norms. These are the team members who are best suited for moderating discussions and chairing meetings.

If there are team members above C1 or native speakers in the group, the challenge changes. As many have mentioned, the ability of high-level/native speakers to adapt to ELF is crucial. In my experience, learners come with ELF and it is not something I train. Their English has been formed by their exposure prior to the training. My job then is so simply formalize ELF as a standard and get everyone speaking the same 'English'. If left 'untuned' to ELF, high-level speakers cause higher communication overhead and actually hurt the team's efficiency. With the natural belief among language learners that greater proficiency means greater communicative skill, the realization that they are actually causing problems can be a real eye-opener.

Conclusion

I have highlighted six aspects to communication in the virtual team environment. Many Business English Trainers will be focused on the language aspect because they either do not have access to the inner workings of the organization or their mandate does not include broader communication issues. But I suspect that many trainers are willing to expand their 'English teacher' role if they see the opportunity to deliver added value or help solve the real communication barriers of the company.

My advice is that training experts enhance their skill set to stay one step ahead of clients in virtual team communication. This includes obtaining the technical know-how, matching reality with organizational theory, revisiting the field of communications and expanding their approach to language in the workplace. Clients will be extremely grateful for you ability to deliver greater efficiency and project success.