Switch - Chip Heath [81]
With post-event interventions, we acknowledge both that crashes will occur and that people will be injured. The goal of post-event interventions is to minimize the severity of the injuries and optimize the health outcomes. A speedy, effective emergency medical team will be important.
The Haddon Matrix is also useful for thinking about matters that aren’t so life-and-death. Let’s say you are the IT person in a small business and one of your many duties is to prevent the loss of important data that occurs frequently when computers crash. Some IT support people in this situation embrace not the Haddon Matrix but the “Hectoring Manifesto” and berate their colleagues for not backing up their work (all the while committing the Fundamental Attribution Error: My colleagues are reckless and lazy people!). But if you think in Haddon Matrix terms, you begin to see a more holistic picture.
Think about pre-event interventions: If computers don’t crash, then you can’t lose data. So maybe you schedule monthly computer check-ups, buy extra-padded laptop bags for everyone, and budget for complete replacements every three years.
Event interventions would call for ways of preventing a crash from leading to data loss. For instance, some computers have an extra hard drive where all data are mirrored in real time. A crash would be less likely to take out both drives.
Post-event interventions would accept the reality of data loss but focus on ways to minimize the damage. The most obvious strategy here would be to create an automated nightly network backup, so that if a crash happens and data are lost, you can restore the previous night’s data. Another post-event strategy would be to find ways to prevent mission-critical data from ever ending up on a laptop. For instance, you might use an online application such as SalesForce.com to host customer contact information, so that precious data would never depend on the health of a local hard drive.
Note that we’ve managed to create a robust plan against data loss without worrying about what our employees were thinking or feeling. We didn’t mention their Elephants or their Riders. We simply tweaked the environment to make bad behavior impossible.
9.
In 1999, some bad behavior was abruptly made impossible at a company called Rackspace. At one particular moment, company employees stopped doing one thing and starting doing another thing, and that behavior shift became the most important inflection point in the company’s history. But before we get to that moment, a bit of backstory is necessary.
Rackspace is a company that hosts internet sites for other companies. It prides itself on customer service, as suggested by its slogan, “Fanatical Support.” The firm’s focus on customer service has paid off. Over the years, Rackspace has won an armload of trade awards for its service, and its “Net Promoter” score—a commonly used benchmark of customer word-of-mouth—has consistently been the envy of the industry.
But Rackspace wasn’t always so customer-friendly. In 1999, Rackspace didn’t think much about customer service. Company founder Graham Weston said that in the early days, Rackspace had a “denial of service” business model. Customer-service interactions were viewed as costs to be minimized—the more roadblocks that could be erected to keep the phone from ringing, the better the profits would be. (Notice the uncomfortable echoes of the Haddon Matrix: If you view customer calls as bad behavior to be prevented, you will do all you can to deter them. Recall that for many years, Amazon.com’s policy was not to publish a customer-service phone number.)
Then in the fall of 1999, Rackspace received The Call. It started normally enough. A customer tried to call for support. He pressed 5 to get help, but instead he got voice mail, which in effect said, “Feel free to leave a voice mail here, but we don’t check it very often, so you’re better-off sending us an e-mail.” The customer grudgingly sent an e-mail message to the suggested address. And the team at