Sunday 19 June 2016

Communication Brevity and Context

You might've seen something like this:
"it works != it will work"
"it doesn't work != it won't work"
"The product can work != the product [does|will] work"
Hmm, let's extend them a bit:
"The product doesn't work != the product will never work"
"The product doesn't work != the product won't work for you and how you use it"
"It works != it works forever"
"It works != release it, no worries"
"It works != no more work is needed with this product"
These statements seem to be very context-detached - it's not easy to see who is involved or what is really meant.

With so little context how much meaning can be drawn? Do airlines work like that? Do they say a plane can work or that it can reach the destination but refuse to say that it will reach the destination?

What's happening here? "it works" and "it doesn't work" are conveying headline messages - maybe something I'd think of as feelings about a product. And maybe specific to what someone means - which also means that you can't read more into it if you don't know that person or know what they intend with specific words and phrases.

Can they be interpreted as something else? Yes, of course! But that applies to a majority of statements - there's always a flip side that can be emphasised.

Communication & Brevity
The words we use and with whom will (or should) differ. The interpretation will also differ. They are probably influenced by who we are talking with, shared history, how synchronised we are, dependent on which trading zone we find ourselves in and what level of interactional expertise each party has.

I'd assert brevity of communication works best when the people are "tuned in to each other". I'd also assert that this type of communication is a heuristic summary / short-hand.

Brevity
Brevity of communication may have a place. But it's not a universal place. This doesn't mean it's bad, it means you should not lift it out of context and generalise as something always "good" or always "bad".

It's a form of short-hand communication and typically (to me) an invitation to discussion or dialogue.

Example
When I was working as a system integrator in the "noughties" (2005-9) I would be testing product deliveries or part deliveries together in different combinations for them to progress to a next stage of work. I'd often remark on certain combinations to my project manager as, "good to go", "no, no good". These are quite similar to "this combination works" and "this combination doesn't". In the context of that relationship and product development that was perfectly ok - with that manager and the teams that I knew.


Note:
1. The two "OK"'s sit in different trading zones of language - different contexts and different meanings.
2. "OK" & "Not OK" are headlines - they don't really contain all communication. They would be accompanied by some form of report - whether verbal or not - of what was seen to work, what was not tested and where concerns might lie.
The people I worked with wouldn't be satisfied with "ok" or "not ok" on it's own. And I wouldn't be satisfied with giving such a simple message in total - i.e. it might be ok as a headline but not the whole story. Naturally, a team would want to know why something wasn't "ok" upon hearing "Not OK" and very often a team would want to know if something wasn't "ok" upon hearing "OK".

To me these are characteristics of each party in the communication chain.

This example might not look likes it's really relevant in the "devops" world but wherever there is a producer and receiver of a product (or information) I suspect the model applies. The content ("OK" or "Not OK" or "<something else>") is highly dependent on the context (who is involved, the different trading zones and different levels of interactional expertise).

Lessons:
1. Brevity of communication is very context-specific, and I'd assert has a personal element.
2. Communication content is driven by context - i.e. the vocabulary you use might well be different depending on how well you know someone.
3. Brevity of communication shouldn't be the totality of communication. It should be an intro to a discussion. So it can only ever be a headline.
4. Lifting brevity of communication into a generalised form is - to me - misusing and misapplying the example. I.e. it's incorrect to say if particular words between two parties isn safe or not.
5. Using a concise form of words detached from context as a good/bad usage example is misleading - and one should beware that it might be a a form of straw man argument, or lucid fallacy.
Important: Content over Labels: Context drives Content
So, to me, in communication - the words and phrases used are extremely context-dependent. They depend on the parties communicating. The exchange of ideas and intent should be dictated by the people in the conversation, discussion or dialogue, an appreciation of their respective contexts and level of interactional expertise.

Related Posts
Communication, Paradigms and Interactional Expertise
Lessons in Clarity: "Is this OK with you?"
On Test Results and Decisions about Test Results
Testing Chain of Inference: A Model
There is no test for "it works, every time, always"


Sunday 5 June 2016

Communication, Paradigms and Interactional Expertise

Over several years I have been looking at communication involving testing, here and here are examples from 2010,  and it never ceases to amuse (or concern) me how little we communicate well; then come the knots we tie ourselves up in to cope with this lack of information and content (and indeed communication, discussion and relation to context).

Occasionally the problem is brevity - information (context) is omitted. Other times it is a different paradigm - a different way of thinking about contexts. Sometimes it is a framing problem - not realising the background argument (or concern) someone has.

I have constant contact with senior managers and I know that they are always interested in content and context - what does it (some piece of information) mean in our product's and company's situation? A stakeholder or manager wants to know how the information you have found relates to their business context.

The last thing I want from a manager or stakeholder is an appreciation of "no added value" due to brevity, lack of content or context or because I don't engage their language or understanding of the situation. Something alone the lines of the Billy Madison clip:



I will look at some issues with stripped out information (brevity) in a following post. In this one let's take a look at the differing views and paradigms that can make us stumble or not notice how communication is failing.

Paradigms & Different Views
Paradigms - these are where different people hold different world views of something, for example what testing is, it's place in product development and what it can, can't and should do. We have probably met people with very different views and appreciation of the work we each do and where it fits into the bigger scheme of things.

There are a few ways to approach this problem. One is to educate people into your way of thinking. This might be the optimal goal, but it isn't always realistic - especially with senior managers. It's not always possible if someone doesn't understand that there might be a different way to look at the topic.

Another approach is to find common ground - a trading zone for language.

Consider the case with three actors: How do three people communicate, one with an ISTQB-view of "words", another with a non-ISTQB view of "words" and a stakeholder (business leader) with his own understanding / view of words? Do you convert everyone to one view, or do you look for an alternative?

To talk to a business manager about testing do you insist he must know all the terminology you wish to use, or do you look for an alternative?

In 2007 Collins, Evans & Gorman [1] explored the idea of trading zones and interactional expertise. On trading zones:
"Peter Galison introduced the term `trading zone’ to the social studies of science. His purpose was to resolve the problem of incommensurability between Kuhnian paradigms: How do scientists communicate if paradigms are incommensurable?"
I.e. how do the three actors communicate with each other in a reasonable way when they each operate in different views of the world (paradigms)? Hence the concept of a trading zone for language.
"Two groups can agree on rules of exchange even if they ascribe utterly different signifcance to the objects being exchanged; they may even disagree on the meaning of the exchange process itself. Nonetheless, the trading partners can hammer out a local coordination, despite vast global differences."
And one important form of these trading zones is interactional expertise.
"Interactional expertise is the product of a successful linguistic socialization. Although expressed as language alone, it cannot be too heavily stressed, interactional expertise is tacit knowledge-laden and context specific. "
Interactional Expertise
Applying Collins’ view [2] of interactional expertise from the sociologist-scientist relation to a tester/developer-stakeholder relation [italics and strikethrough are my application]
“… where interactional expertise is being acquired, there will be a progression from “interview” to “discussion” to “conversation” as more and more of the science [business/stakeholder context] is understood.” 
“ Above all, with interactional expertise, conversation about technical matters has a normal lively tone and neither party is bored. As things develop the day may arrive when, in response to a technical query, a respondent [stakeholder] will reply “I had not thought about that,” and pause before providing an answer to the sociologist’s [developer/tester’s] technical question. When this stage is reached, respondents will start to be happy to talk about the practice of their science [business context] and even give studied consideration to critical comments. Eventually respondents [stakeholders] will become interested in what the analyst [developer/tester] knows about the field because he or she will be able to convey the scientific [business context] thoughts and activities of others in a useful way. ”
“Where there is no developing interactional expertise […] the conversations never become interesting to either party, the analyst [developer/tester] can never transmit information, take a devil’s advocate position or, crucially, distinguish between “pat” answers and real conversational interchange, nor between jokes and irony on the one hand and serious responses on the other. Worse still, though a field might be riven with controversy […] the analyst cannot understand what the protagonists are disagreeing about, nor how deep the disagreements run, nor, with any certainty, who disagrees with whom! ”
Note, this relationship goes both ways - stakeholder <-> developer/tester. Over time the stakeholders / business leaders worth their salt will develop their interactional expertise to talk with the product developers / testers.



Importance of these concepts in your daily work
Some important points to highlight:
  • Acknowledging (or being aware) that language trading zones exist between different people or stakeholders then a natural way to cope with this is to advocate a greater need for interactional expertise.
  • Plainly: Testers need greater interactional expertise in dealing with stakeholders and business leaders. This means understanding their concerns, how they think about problems, listening for signals in which pieces of information they react to (and don't) - why are some pieces interesting. To a certain extent it means translating information into their language. What do the risks in your testing mean to them and the customers? How might they word or translate it?
  • What type of information do they need to translate and why. It's not usually just about - can a product version release in the next quarter, sometimes it's also about understanding their risk picture - and what other contingencies they might need to prepare for.
  • In fact, if you can talk with and listen to your business leaders more and more - understand how they think and talk and what their concerns are - you will get familiar with the trading zone language. For example, why do they emphasise certain ideas and concepts - and how does my work relate to that?
  • Tip: Ask your stakeholders or business leaders if they are using language or concepts you don't understand.
  • Corollary#1: Business leaders naturally need to listen to their product development organisation - for information about how they talk, which information they emphasise. In general, business leaders are more adept (used to) doing this - as they need to communicate cross-business.
  • Corollary#2: There is no one right way to talk about a subject if two people are located in different paradigms (or even namespaces) - without acknowledging the need of language trading zones and even understanding which context the other person is grounded.




Potentially Related Posts
Communication Patterns
The Conway Heuristic

References
[1] Collins, Harry, Evans, Robert and Gorman, Michael. 2007; Studies in History and Philosophy of Science Part A -- Trading Zones and Interactional Expertise
[2] Collins. 2007. Rethinking Expertise (Chap 1, “Origins of Interactional Expertise”)