Lessons from Disaster Response

An Episcopal priest on a podcast is talking about families and growing up.  She notes the inevitable frictions that occur.  These frictions, or things going wrong, is an opportunity to grow.  In fact she says that if there were no friction, there would be no growth, because we would just stay the same.[1]

For the past twenty years I have been immersed in technology and organizations that use it to provide disaster relief.  Disaster planning is something that every IT leader needs to worry about.   This is more and more true as our dependence on our systems to get things done grows.  But I’m not talking about this kind of disaster planning, which has a natural parallel to preparing for crises in the disaster prone parts of the world.  

I’m interested in what we can learn from large-scale disaster response that we may apply to the running of IT itself.  What are the IT leadership lessons we can glean from disasters.  What is the growth we can experience from rubbing up against these frictions?

The obvious place to start is to recognize that disasters are inevitable. The planning in relief organizations is not about if a disaster occurs, it’s about when.  The question we are asked in disasters is: are we good enough to respond fast enough to save lives and help people bounce-back.

The first lesson is about speed.  In a disaster, the number one priority is speed.  Having a well-designed process that takes a week to deploy won’t cut it. People are hurting now.  Response  needs to be in hours, not weeks or months.  And relief organizations, both in government and non-government forms, need to get faster each time; if they are to grow in impact, they must learn from the frictions.

 When I first joined the International Red Cross/Red Crescent in Geneva as the Head of IT, I first developed some goals and a strategy for change.  It’s one of the top reasons a new CIO is hired, to make change happen.  I drew the analogy to the Queen Mary ocean liner, this large ship designed to move a large group of people and process as surely and safely as possible. But now we needed to work together to turn it around in the Rhône River because the river around us is moving in a new direction. And we need to catch up. That means acting more like speedboats than ocean liners.  

The second lesson is about good enough. Doing things right is another top concern of relief organizations.  But the speed demanded of us counts more than the quality.  A colleague commented during the Indonesia Tsunami response that we didn’t have time for all the meetings and discussions involved in good business as usual in an NGO.  We needed to make decisions on the spot.  And, she noted, nothing fell apart.  The good enough way worked.

We often design systems to handle each and every contingency we can think of.  That’s the way of deep knowledge organizations.  It’s also the way of organizations who are accustomed to doing things a certain way. As a result, we customize vendor systems to handle the exceptions without first criticizing the current processes.  We fall victim to what Michael Hammer called “paving the cow path.”  Most commercial off-the-shelf systems are good enough.

The third lesson is to build bounce-back.  Resiliency in communities is the ability to bounce-back after a disaster.  Working with vulnerable communities we are constantly reminded of the resiliency in the human spirit.  A positive outlook can go a long way.  But so can systems that can bend and change under stress.  The reeds bends more than the oaks in a storm.  This also applies to projects.  A resilient project is one that adapts to discovery along the way.  Agile approaches get at this.  So does chunking things down to small components.  If you want to bounce back from a project failure, have smaller project phases that are cheaper to throw-away and begin anew.  

A question I often ask my students is, "Does your system fail gracefully?"  The implication is that it will fail. Forty years of IT experience has taught me that IT failures are not a matter of "if", but rather "when".  How will your app behave when it fails?  Will it help the user recover with a meaningful error message that goes the extra yard of what action the user may want to take next?  That's a resilient system.

We can also apply this to a relatively new area of IT, autonomous vehicles or self-driving cars.  The question is not about how well the systems perform and learn to perform better in avoiding accidents.  It’s about planning for the inevitable failure of the software and hardware from time to time.  That takes imagination and humility.  How do you design for that?  Expect the storm, and adjust with grace, hope and a human touch.

[1] Barbara Crafton, “Sunday Sermon,” June 22, 2014, Trinity Church Boston, https://youtu.be/Zg9h2nuizwA.  She says “The way we grow primarily is by friction; you don't really grow much in the sunny meadows of sweet harmony; they mostly help you stay the same.  Where you grow is by bumping up against each other.  Where you grow is by rubbing up against each other in an uncomfortable way.”  [7:24 - 7:47]

"The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated."