“What we’ve got here is… failure to communicate”
“What we’ve got here… is failure to communicate” — a great line taken from the film ‘Cool Hand Luke’ in which Luke, played by Paul Newman, is part of a chain gang in a US prison. Unbendable to the will of the warden, he hears the famous quote regularly before being punished. Ironically in this case the communication is crystal clear however, the protagonist chooses not to accept it.
Unlike the warden in Cool Hand Luke, communication at work is often lacking. How many times have we heard “We should have communicated better” after something has gone wrong? Sprint retros regularly have communication as a discussion item; be it a badly written user story or a dev decision to implement differently that wasn’t shared with a Product Owner.
The great thing about communication is that we are already experts at doing it: we talk to our friends, colleagues, people in shops all the time. So why is it we commonly fall down when important information isn’t shared?
WHY COMMUNICATION FALLS DOWN
Below I’ve listed 4 of the most common failures I see commonly happening in workplaces and easy solutions to prevent them happening in the future.
PEOPLE ASSUME OTHERS ALREADY KNOW
I think possibly the biggest issue — the person who knows about the problem believes that everyone else will also know. Two examples: one extreme and the second more commonplace. In 1986 the Space Shuttle Challenger blew up during launch. This cost the lives of the 7 crew on board and needless to say was incredibly sad. Later investigation identified that the fault was a simple o-ring which was known by the engineers to have issues. This had been communicated to management. However, the engineers had communicated by putting the issue as just 1 part of a 200-page powerpoint presentation. Not surprising that it wasn’t ever picked up by the management teams*.
Fortunately most mistakes aren’t so devastating. Most of us don’t work in environments where lives depend on our decisions. A more mundane example of communication falling down could be that a replacement product has a different permission structure to the existing one. The engineers know, the Product Manager knows, but the Product Manager only communicated with Customer Success and Support teams via documentation. On release, chaos ensues because users aren’t correctly set up.
SOLUTIONS
The Agile manifesto says it really “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Replace the development team with people and it feels like a pretty solid argument to me.
SCARED OF CONFLICT
No one wants to be that person. You know the person who is just about to tell the CEO the product doesn’t work, or there is a major flaw, or it’s going to overrun by 4 months. By being that person you instantly become responsible, therefore the person to blame.
SOLUTION
Sometimes bad stuff just emerges at the end and if that’s the case your choices are limited, don’t hide it away, address it, address it now. This is the time to own it, if you’ve not read the book Extreme Ownership I would recommend you do (see References).
In this situation take full ownership, avoid blame and avoid ego. Arm yourself with all the facts, if you have solutions great but if not, at least outline what you will do to get to a solution. Your CEO will respect you more if you say “The new mapping feature I’ve been responsible for is flawed. I missed the fact the our users will need to geotag so they can find their customers and geotagging isn’t currently supported. If we go live now, we will totally miss the mark and this will be very hard to recover from as customers will rightly lose faith. I propose a two-month delay, this will allow time to rectify the fault and give us a great opportunity for maximum uptake”.
Your CEO is still likely to be annoyed however, she will be grateful that you identified an issue before it was too late.
Note that the person used ‘I’ instead of ‘we’. It’s human to subconsciously share the blame, however it’s important to take full responsibility, even when mistakes have been made collaboratively. Basically that is a difference between being a Leader and a Manager.
WE WILL SOLVE BEFORE ANYONE NOTICES
Even worse than being scared of conflict is trying to fix something without telling anyone and hope they never find out, or as I like to think of it, the ‘Nick Leeson Effect’. Nick Leeson was a successful trader in the ’90s. However, things went south and Nick made several losses. Rather than ‘owning it’ he hid it away in a separate account and made bigger and bigger trades to try and cover the losses so he wouldn’t be found out. Like a gambler on a losing streak his losses mounted until eventually he fled the country. It is estimated that the total loses plus the damage to his employer, Barings Bank, totalled over $1bn and eventually let to the collapse of the bank and prison for Nick.
Most issues are not as big as Nick Leeson’s. Features being released with known caveats, that are known to the Agile team just not anyone else is a more familiar scenario.
SOLUTION
Firstly, issues are never hidden, they will always emerge and the later it is left the worse it will be.
Share issues at the earliest opportunity and ensure they have been understood. This may be during the early discovery phase where a known behaviour will change. Don’t leave this until release: connect with the people it will affect, share including the implications. Depending on how political your organisation is this may need to be backed up by audited communication (email, slack etc). Being transparent will buy you relationship credit with your colleagues and within your organisation. This is important stock to have in the bank, as you never know when you will need to spend some ;0)
I DID TELL YOU….ON SLACK
PM “What do you mean we failed sprint, I’ve checked every day in standup and everyone said it was good”
DEV “It is good, but you know like I told you this story is more complicated so we are good, but not for this sprint”
PM “ I don’t remember you telling me”
DEV “ Dude I slacked you on Thursday in the ‘whatever’ channel”
Communication tools are brilliant for many, many reasons. As with all good things there are downsides. We have so many different ways to communicate plus high frequency of interaction, it is hard to keep track of what’s important.
Digital communication is Snapchat. By that I mean, in the moment, quick to send, quicker to forget, basically transient. With this in mind, anything with a degree of importance needs to be at the very least acknowledged and preferable face to face. I know many teams have great use of tools like Slack, and they are brilliant most of the time. The danger is important information gets lost, tools like Slack encourage a fire and forget mentality. Unless acknowledged, the information hasn’t been successfully shared.
SOLUTION
If it is not urgent and not important your preferred way of internal comms is fine. E.g. “Do you want anything from the shop?” then Slack is fine. If it has a further impact then it needs to be direct 1–2–1 verbal communication, ideally face to face. If that is not possible a telephone call or an online meeting like a hangout.
CONCLUSION
As humans, we are a social species. Higher communication is a major differentiator we have from other mammals, so use it. Make sure that important information is communicated, as early as possible, as detailed as needed and with the right people. When in doubt, over communicate.
REFERENCE
‘What we’ve got here is failure to communicate’ — Cool Hand Luke (1967)
Extreme Ownership — by Jocko Willink & Leif Babin
Nick Leeson — https://www.investopedia.com/ask/answers/08/nick-leeson-barings-bank.asp
Challenger Disaster — https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disaster
*Should be noted it has been documented that NASA had a very ‘control and command management structure in the 80’s. Engineers felt that they weren’t listened to so therefore could only highlight problems and issues indirectly.
