Communication?…Of course we know how to communicate. What a stupid question!
The IT director of an organization wanted to play the Apollo 13 simulation with his team. ‘Although I am interested in the ITIL or Process side of things, I mainly want to focus on people and the way they communicate. We have a lot of young technical people who dive straight into solutions, they don’t really listen to each other or give each other room to express their opinions’. The game needed to focus on these issues as well as structuring the flow of communication in processes, and embedding communication in technology.
At the start of the session, in my role as Mission Director for Apollo 13, I asked the team, ‘What is effective communication? What will I see’? Some of the answers were:
- Feedback to customers on status
- Ask the goals and expectations of the customer
- Tell each other about the agreement with the customer
- Make agreements with each other
- Listen
- Confront each other on agreements
We wrote these on a flip-over and hung them up for all to see throughout the day. ‘Is this what you ALL want? Is this what you will show me today’? All nodded.
It was the first time the team had ever asked themselves this question – ‘what is effective communication’?
Surely part of effective team working is to understand what is effective communication in the team, between teams and with the customer?
Often these themes such as ‘Effective communication’ are thought up by the ‘Directors’ and made visible on posters, sometimes described as core values or cultural values such as ‘We will be open and transparent’, with too little thought of ‘What behavior will we see that represents this?’ or with too little engagement with the workforce to shape this behavior.
We hang up posters of new corporate values and miraculously expect people to start behaving differently.
Testing behavior in the Apollo 13 simulation
We gave the team 30 minutes to design their processes for supporting the customer (astronauts) once the rocket had been launched. A beautiful process flow was made, and a paper based tool for recording the calls. The IT manager and game facilitator watched and observed how the team applied their OWN list of ‘Effective communication’.
‘You would think that we would all know what ‘listen’ means’, whispered the IT director to me. Too many IT people seem to listen by hearing a stream of words and every so often nodding as a signal for the other person to continue talking.
As was demonstrated in Apollo…..
‘We will prioritize incidents according to ‘life threatening’ or ‘mission goals in danger’ explained the Incident manager. There was silent nodding by the specialists.
‘The Crew will be notified of the status of incidents’…more silent nodding.
‘This is the process flow, the incident …blah…blah….’? Silent nodding, or blank stares, or clear confusion on the face of some.
‘Specialists will make detailed reports about the capacity used’….imperceptible nods by the specialists.
‘If specialists can’t solve it, it will go to the supplier’? …the supplier manager didn’t hear this as he was clearly busy reading something at the time.
‘OK’ said the Incident manager to the Flight Director (team leader) ‘Everybody now knows what to do’.
‘OK’ said the Flight director to the Mission Director (Game facilitator) proudly. ‘We are all ready to launch everybody knows their roles and is ready to go’!
We then played the first round of the simulation. The Apollo 13 rocket launched and the first calls were reported by the astronauts (game facilitator). My role as facilitator was to now test and challenge their process and their agreements. The first round was a disaster:- ‘angry customers as critical incidents were open too long’, ‘lost incidents’, ‘capacity failures in certain systems’, ‘no status information’, ‘specialists moaning ‘nobody told me when it needed to be done by!!’’ – and equally specialitst not asking ‘what did you agree with the customer’?
What did this have to do with effective communication and listening?
Let’s look again at the 30 minutes design:
‘We will notify the crew’….nobody explored ‘who is ‘we’’? ‘Where will we get status information from’? ‘How often’? Status information for ALL incidents…or just the priority incidents?’ it was unclear what was meant. Everybody heard the words but did not translate it into ‘What does this mean for me’?
‘We will prioritize incidents according to life threatening and mission goals in danger’…..none of the specialists asked ‘What does that mean for me? How long do I have before it must be solved’? ‘What do I do if I can’t meet that deadline, or if I don’t know how to’, ‘where do I go, who do I need to escalate to’?
‘Specialists will make detailed reports about capacity used’…..nobody asked ‘what reports? For who? When do they need to be made? What is the purpose of the reports? Who will use them and how’?
When the process manager was explaining the process there were some clear looks of confusion or doubt…….the specialist did not say ‘wait a minute, I don’t understand’…or ‘I don’t agree’ and the process manager did not explore that what he said was fully understood, and accepted. Some people clearly were not listening, but the process manager did not check – e.g ‘Supplier manager can you confirm what we just agreed’?
The difference between listening and ENGAGED listening is mutual understanding
The team discovered that listening means understanding, exploring, confirming what was said, understanding the intentions of the messenger, what did the messenger want you to do with the information? Was it clear to YOU what you were expected to do with the information, summarizing that what you thought you heard was what was intended, confirming what you just told somebody was understood and agreed to’?
We were all making assumptions about understanding rather than confirming”.
The team admitted that part of the reason for not exploring was time pressure, but none of them escalated and said ’if we don’t have time to discuss and agree this it will fail and we could create an unacceptable risk for the business’, nobody said ‘wait a minute, this point is critical, we see this day in and day out lets finally decide and agree on this’?
They allowed time pressure to create a situation they KNEW would cause failure”!
This was an eye opener for the IT manager who recognized an internal push on deadlines and speed of deployment without explicitly exploring risks and concerns.
Continual Service Improvement is EVERYBODY’s responsibility”
The team played 3 rounds of the game, at the end of each round they applied pragmatic CSI. After each iteration THEY got together 1st, 2nd and 3rd level (end to end delivery chain) to improve THEIR OWN behavior (PEOPLE); activities and the way the work flows or gets escalated (PROCESS) and the need to capture and make reuse of the information and knowledge (TECHNOLOGY). In each iteration they practiced and improved ‘Effective Communication’.
By the end of the game the teams were confronting each other on understanding. An Incident would be given to a specialist and the specialist would ask ‘When does it need to be solved? What did you promise the user? When do you want a status update’ – they were asking questions to clarify what were implicit SMART objectives. ‘Is it specific enough what I need to do, is it measurable –when and how long do I have? Is it achievable and if not what escalation options do I have? Is it realistic? Do I have the skills and capabilities and the time, and do we both agree the timelines for either solving it, or escalating it’?
If an incident was handed to a specialist the person doing the hand-off would confirm ‘Do you understand? Confirm with me what you will now do and when you will report back or escalate’? Both giver and receiver were taking the responsibility to ensure not just that the words were heard, but understood and translated into behavior.
At the end of the game
It is hard changing behavior’ was one of the feedback comments at the end of day reflection, ‘..even in one day we forgot and fell back into old familiar ways’, ‘it takes practice and time to change behavior’.
The team agreed that the first step was the will to change (attitude), the next step was to agree what that behavior needed to look like’ (behavior), they made a list and agreed to hang it in all meeting rooms, they agreed in all meetings they would practice and give feedback, they would experiment (and slowly embed it into the organizational routine and habit (culture), they all wanted it to become ‘the way WE do things here”.
What made the difference? ‘The simulation allowed us to get together, the complete delivery chain and see, feel and experience the impact of ineffective communications and the benefits when we do it well, that is personal , individual benefits and the impact it has on the customer…..after all it is all about keeping the customer satisfied, if we don’t , in our business the customer can easily go somewhere else for their services’.
Sadly and surprisingly this isn’t just specific to one or two organizations…
We have played with literally hundreds of organizations world-wide. This is typical of MANY of the simulations we play. The majority of teams struggle with communication. We have played games with both business & IT teams. Although it isn’t specific just to IT, experience reveals that IT teams tend to struggle more with effective communication.