On a single day last May, a massive cyber-attack called WannaCry Ransomware blighted over 200,000 Windows computers in some 150 countries. It might have been more had it not been for the quick actions of Marcus Hutchins, a cyber-security expert, who discovered a kill-switch built into the ransomware’s code. Apparently, before infecting a system, locking its files, and demanding a ransom from its owner, the ransomware first checked for the non-existence of a gobbledygook web domain. Hutchins simply registered the domain for $10, brought it into existence by pointing URL requests to his own server, and thereby thwarted the attack. Hutchins became an overnight hero (sadly for him, the new status did not last much longer than overnight). However, you or I could have claimed some credit for halting WannaCry. All we would have needed was Hutchins in our team, and set him to work. Failing that, we would have to have had at least one person in our team capable of coming up with the idea of looking for a kill switch, another able to find it hidden in the code, and another with a credit card to put in a call to GoDaddy.
Can you think of an example of an effective working group? I can: a disaster rescue and recovery team. These are groups of men and women who, in the aftermath of a catastrophe, work to rescue the victims and to prevent subsequent loss of life. They are composed of specialists, like engineers, medics, electricians, and dog handlers. In the case of major disasters, such teams are brought in from several different countries. Some of them might never have worked together before. Yet the operation runs effectively. If teamwork is possible in such a diverse group, under intense time and performance pressure, in inhospitable working conditions, and among people who might not even have met before, why can it sometimes seem so difficult in the typical corporate environment?