TechEssence.info

The current discussion over technology not working as hoped during ALA's Library 2.0 BootCamp gives me to ponder over how best to react when a technology fails or underperforms. Certainly, all due diligence should be performed so that technologies don't fail—but look, sometimes they will; they're created by humans, and humans are imperfect.

How does a library best recover from a technology failure?

I'm going to assume the following goals:

• Finding a way to offer the desired service. (What? There was no service in view? Then why was the tech adopted in the first place?)
• Damage control among patrons. No library wants to look bad!
• Assuaging fear of technology, and ameliorating hatred of technology, caused among staff and patrons by the failure.
• Guarding against future failures of this type.

The first, cardinal, never-to-be-broken rule: Acknowledge the failure, accept responsibility for it, and apologize—and do all these things promptly and humbly. Computer users are accustomed to computer problems. Virii, web-page 404s, crashes, slowness, even lost data—these are inextricably part of being digital. Computer users are astonishingly forgiving of all this.

What do they not forgive? Being left in the dark. Defensiveness. Stonewalling. Accusations of user incompetence (even when such accusations are justified!). It is deathly hard not to be defensive. Even so, don't. An immediate "Oops, I'm sorry" repairs amazing amounts of damage.

It's okay to say "wow, I completely didn't expect it to die like that!" They'll understand. It's okay to admit your feet are clay, that sometimes even you, tech deity that you are, can't even program your own VCR. These admissions create sympathy and fellow-feeling.

Listen to what the tech's users have to say about their experience with it. This is hard, because some of the users will be very angry, and some of what they have to say will be completely irrelevant. Listen anyway. There's a nonzero chance you will hear something that will help you fix the problem. There's also a nonzero chance you'll hear something that sparks a new or better idea.

Make things right with the service's users, if you can. However you can. This usually takes work, and pretty thankless work at that, but it's worth the effort. When you do this, do it with a smile, and accept that you will probably not receive much gratitude for it. Remember, it's your tech that complicated the user's life; they're entitled to be cranky about it.

Now you have a decision to make: fix, start over, or jettison the service altogether? I don't have any magic guidelines for making this decision, as it's almost wholly situation-dependent. How badly is it broken? Were people burned so badly that they won't try the fixed version? How heavily was the service marketed? Is it honestly meeting a need? Is it meeting the need we wanted it to? (Maybe an unforeseen use makes the tech worth keeping around! But don't keep an unused or unusable technology just because you sank some costs into it. That's called "throwing good money after bad.") Is there a better alternative?

When the shouting dies down, and any necessary fixing and damage control has been handled, it's time for the post-mortem. This is hard. A lot of people won't do it. Among those who do, it has been known to turn into a fruitless blame game. Prevent that by focusing on the goal: not making the same mistake again.

Where was the failure, really? Did the planning process identify the right needs? Did the design really address the needs? Was something wrong with the setup? Should user testing have changed? Should the service have been rolled out as a pilot instead of all at once? Should training have been different? Were the problems completely unforeseen, and if so, what does the library need to learn or do in order to guard against similar problems in future?

The final step is forgiveness. Like everything else I've mentioned, this is hard. But do make an effort to let everybody know that it's all right, failures happen, and there will be no grudges held over this one.

I've had my share and more of tech-related mess-ups. I admit I haven't always practiced what I just preached. I do try, though, and I absolutely see a more positive response when I do.