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.

Meredith’s excellent post about acquiring staff buy-in caused a commenter to raise a related question: how to get buy-in from the higher rungs of the ladder.

As with anything, there’s no one foolproof way. Evaluate any strategy suggested in light of what you know about your library’s administration. That said, here are a few things that have worked for me and folks I know.

• Show how it saves staff time, effort, and (especially) annoyance. With impressive-sounding numbers, if possible. I’m selling new signage for MPOW on the rationale of “will reduce directional questions.” (Signs are a technology, folks. Not every technology runs on microprocessors.) Solve a problem you know admin has.
• Show that it runs easily on what you’ve already got, for little or no additional budget damage. This is a major selling point for a lot of open-source software.
• Easy sells. Show that it’s easy to work with! This means keeping your testing and installation war stories under wraps, at least temporarily.
• Line up a patron or two who clearly want the new service before you pitch it to admin. Informal surveys, skunkworks test runs, whatever it takes. Do not give a naysayer an opening for “But nobody will use it!”
• Anticipate objections. Don’t write down all your rebuttals in your proposal, or you will sound defensive—but do be ready to answer the likeliest questions. Security, maintenance, cost, customization, training, marketing… be ready.
• Pitch a pilot project instead of a full-blown rollout. This gives admin a handy out; they can blame you if the tech fails. (But it won’t fail, right?) Study other projects (tech and otherwise) that have succeeded in your library, to figure out how other people documented a pilot project’s success. Then do as they did.
• Are other libraries doing it? Have they talked or written about it? Be a librarian—build a bibliography! Library admins fear being left behind. It’s cruel to play on that fear, but it’s also effective.
• If other libraries aren’t doing it, you may be able to sell it as “Our library can be a leader!” This is a risky strategy, especially in libraries with timid or stretched admins, and it should never be tried in isolation; you need other arguments. Still, it can work.
• Do it silently. Sometimes, honestly, it doesn’t pay to ask. If you’ve got a website improvement that is a slam-dunk for everybody, but by the time it’s chewed over by six committees it’ll be useless, take the risk (make no mistake, this is a risk) and just do it.
• Be prepared for your pitch to fail the first time. Or the third. Or the tenth. Sometimes you have to plant an idea and then give it some time to germinate.

And some things that I have seen fail:

• “It’s cool!” If this is your only selling point, go back to the drawing board.
• “Patrons are doing it!” Usually you can’t prove this to admin’s satisfaction. Even if you can, the response is likely to be “Doesn’t mean we have to.” You need to demonstrate a benefit to the library, not just to patrons—I know that sounds cold, but I have found it to be true. Personal value (to library admin) precedes patron value!
• Jargon. Don’t use it. “Baffling ’em” with bovine excrement only makes admin hate you.
• “It makes my life easier!” Sure, but how does that benefit admin? To make this work, you need to do a little horsetrading. Tell admin what you can do for them with the time this technology will save you. Then be honorable and do it.

Meredith’s commenter asked specifically about either-or tech questions, such as “Fedora or DSpace?” I think the answer here is fairly straightforward: figure out what admin cares about and play to it. If admin likes fancy homegrown user interfaces, then it’ll be easy to sell Fedora. If admin likes out-of-the-box functionality, DSpace has it.

If your instinct is to play against admin’s desires—you think, for example, that admin will want DSpace because it’ll be easier short-term, but Fedora is a better long-term choice—then you have to anticipate objections, again. Your big weapon is that you know a lot more about these things than admin does, and knowledge is power. Don’t be overbearing—but do apply a little spin to your presentation.

Also, don’t get caught up in choices that don’t really matter. If you’ll be happy enough with either choice, say so, and decline to take sides. By all means lay out the pros and cons clearly for your colleagues, but save your side-taking energy for the discussions that count for something.

I hope this post will attract some discussion; I don’t doubt I’ve missed some things, and some of what I’ve said may be controversial. Have at it!