During my work at multiple organizations, client offices and multiple cities around the world, I’ve seen individuals get nervous while talking to their CEO’s and Managers. Individuals fumble, sugar-coat discussions and avoid arguing with their clients. Some of them merely hint towards what they believe is correct and then decide to keep their mouths sealed. With time, they turn either disconnected or completely nervous and reluctant to give their ideas.
At the first glance you would classify them as spineless individuals lacking conviction but monitor them closely and you’ll figure out that these guys are indeed capable of fighting harder battles and taking up bigger challenges than their sophisticated counterparts who just happen to be a little more articulate with words.
I could go on and on about my stories on how people not ‘speaking up’ at the right time can lead to project failures and colossal-screw-ups. Here’s one:
|
Fred was asked by Multiplitaxion Inc, to come up with a data access framework that would assist them build multiple other applications on. Fred had done a couple of consultancy projects before but this was his first time at framework development and he struggled for over a couple of years with a decently big team of programmers. Time flew as Fred struggled. Two years later, Fred had failed; and that, those who understand software, will tell you is not such a bad thing after all. Two years later the stars aligned and a proposal showed up requiring the exact same features Fred and his team had been assigned to build. Fred was asked if the framework would ‘fit’ and if they could roll out the framework and build other enterprise applications using the framework. Fred hesitantly and reluctantly told the management that they 'could indeed build other applications on top of the framework but they would have to do ‘some refactoring’ and tweaking before the application became fully scalable; or something to that effect. Reality of it was that data access framework had broken windows all over the place and was snowballing into one large crappy piece of application right in front of the entire team. The team was clearly not as optimistic as Fed or the management and yet the members barely expressed their concerns in statements like - ‘maybe we ought to change the database server’, ‘maybe we ought to bump up the code quality’ and the like; and then they continued working. When the people who sign the paychecks looked at the framework they weren’t really impressed; but they had already been told that the application required ‘some refactoring’ before it would become fully scalable. It crashed here and there a couple of times and then individuals from the management level wrote back to the team appreciating the team’s effort and mentioning in the passing that the application needed to get better and they were sure it would get better with time. The application rolled out to the client, in semi-broken, fragile state where shaking it up really hard would start breaking things all over the place; this is how far things went and in all this time no-one ever mentioned that the emperor was in fact naked. |
If you were reading that real life story that I was a personal witness to from the outside you would think that everyone in the whole episode was either spineless, lacking conviction or both; yet clearly that is not the case.
Malcolm Gladwell feels that this communication issue is in fact the reason for most airplane crashes happening around the world. The linguists he interviews for his latest book Outliers, gives this phenomenon a name:
|
“Mitigated Speech”, which refers to downplay or sugarcoat the meaning of what is being said. We mitigate when we’re being polite, or when we are ashamed or embarrassed, or when we are being differential to authority. If you want your boss to do you a favor, you don’t say, “I’ll need this by Monday.” You mitigate. You say, “Don’t bother, if it’s too much trouble, but if you have a chance to look at this over the weekend, that would be wonderful.” In a situation like that, mitigation is entirely appropriate. In other situations, however – like a cockpit on a stormy night – it’s a problem. |
Outliers provides chilling transcripts from the black boxes of crashed airplanes which clearly show how the plane crews were busy indulging in mitigated speech and worrying about what the captain or their air traffic controllers would think even when their plane was rapidly approaching a disastrous crash.
Outliers also does an amazing job at doing is describing the importance Power Distance Index (PDI) and cross culture mitigations in airplane crashes. The book describes how the country in which you were brought up and your culture will eventually have an influence how you deal with crisis situations. In Outliers, Malcolm uses the example of Columbian pilots landing an airplane which is low on fuel to illustrate how people from different countries and cultures deal with authority and superiors, even when involved in crisis situations. A lot of it also ends up being very relevant even in the software development world:
|
There was something more profound – more structural going on in the cockpit. What if there was something about the pilots’ being Columbian that led to the crash? “Look, no American pilot would have put up with that. That’s the thing, Ratwatte said. “They would say, ‘Listen, buddy, I have to land.’”. |
Ever wondered why a huge number of Indian programmers fail miserably at communicating the accurate health of their project to their counterparts around the world and why some of them fumble all over the place in conference calls with their clients? Read Outliers and you might just stumble across that answer and many more.
The book provides stories of how the Korean airline turned from the worst airline with the highest number of air-crashes to an airline which was highly reputed and very safe simply by overcoming mitigation resulting out of their fundamental underlying cultural background. According To Malcolm mitigation has been the primary reason for most air-crashes in the history of the aviation industry. He explains:
|
Combating Mitigation has become one of the great crusades in commercial aviation in the past fifteen years. Every major airline now has what is called “Crew Resource Management” training, which is designed to teach junior crew members how to communicate clearly and assertively. For example, many airlines teach a standardized procedure for copilots to challenge the pilot if he or she thinks something has gone terribly awry (“Captain, I’m concerned about…”, Then, “Captain, I’m uncomfortable with…”, And then if the captain still doesn’t respond, “Captain, I believe the situation is unsafe.” And if that fails, the first officer is required to take over the airplane.) Aviation experts will tell you that it is the success of this war on mitigation as much as anything else that accounts for extraordinary decline in airplane incidents in recent years. |
After years of airplane-crashes the aviation industry may have learnt the lesson; but after iterating in the infinite loop of failure for years neither software-developers nor software development shops seem to be putting in any conscious effort to battle mitigation.
Do you have a problem of mitigation in your team? Do you yourself indulge in mitigated speech at work when dealing with your seniors or while making your juniors feel good, even when things are badly messed up?
If you answered yes to any of the above questions go walk up to your manager and express your opinions bluntly and openly or pass on some honestly blunt constructive criticism to your juniors. I dare you.
On a serious note, Don’t underestimate the perils of mitigation in software development. Create an open culture where mitigated speech is discouraged and ideas are thrown out in the open, freely. Rage your battle against the problem of mitigated speech before it leads your future projects to disastrous crashes. I wish you good luck.
Comments are closed.