Communication it is not just what you say. It is about who is the receiver, what is their relationship with you, what is the context.
Let's see some examples!
When the authority gets in the way of collaboration
On December 28, 1978 the United Airlines Flight 173 crashed in Portland, killing 10 people on board. The cause of the crash was that the airplane ran out of fuel, while the crew was trying to diagnose an issue on the landing gear. The transcripts of the cockpit recording shows that the crew had some level of concern on the fuel state but they failed to successfully communicate their concern to the captain.
The authority of the Captain and the way he communicated were recognised as one of the causes of the catastrophe.
Following the incident, the National Transportation Safety Board recommended training all airplane crew members in a communication framework, the CRM (crew resource management), to improve communication and decision making.
A boss that barks orders does not invite collaboration. Using the right approach helps to get the facts on the table before taking decisions.
If as a manager you frame decisions as taken and lead the team without giving them space to give their output, they will be hesitant to share and collaborate with you.
If instead your language will invite them to give their contribution, they will open up and help.
For example:
Instead of:
I've decided we're going to use this new process from Monday. Everyone needs to follow it.
Try:
You work with customers every day, so you probably see things I don't. What would you change about the current process? Let's work out the solution together.
The power of framing
When you are describing something, you are connecting certain words with the experiences of the listener.
Let's use the expression "technical debt" for example.
It is a beautiful expression, because it implies that we borrowed something that we have to return, and we pay interests on top of it. Most of the people know what a debt is!
At the same time, it can lead to misunderstanding when you are talking with stakeholders. They will wonder about the reason why you took a debt. Or for example, what is the currency we are talking about (hint: it is time!).
The communication can become even more confusing when we call tech debt what they are instead simply "defects".
I led a 2 year long project that was called (not by me!) refactoring. It was not only a technical refactoring, it was an entire redesign of the user interface. Everyone was confused on the reason why it took so much time, and they could not understand why the users had to validate every single change!
The culture gap
The listener upbringing and culture have a big influence on how a message is received. Some culture is very indirect (British for example), some other the opposite (Dutch).
A Dutch speaker can result obnoxious to an British listener. And a British speaker can result super confusing to Dutch listener.
I remember having to deal with a new CTO, which lived in the USA for a long time. One day he was asking me about a new application and I said that "it was OK". He asked me what kind of "OK" it was. From his experience US folks abuse of superlatives. "OK" can mean, quite bad for them. One thing must be at least "awesome" to match an European "OK"
Closing and bibliography
The Manifesto of Agile Software Development recognised the importance of ”individuals and interactions over processes and tools”. But for this to be effective, you have to adjust the language to the situation and the listener.
Some useful insights are in the books:
- “Leadership Is Language: The Hidden Power of What You Say and What You Don't” (L. David Marquet)
- "The All New Don't Think of an Elephant!" (George Lakoff)
- "The Culture Map" (Erin Meyer)