on heroism

People who follow my other online adventures may already know that I quit my library job, the automation project that I was so proud of. I didn’t really quit, I’ll still be helping, but I took myself off the project as “the person in charge of the project.”

It’s a not-entirely-long story but the upshot was that once we finished the obvious To Do list [getting books scanned and item and patron records into the catalog] the remainder of the work was muddy. The librarian and I had different opinions on what needed to happen next [in my mind: flip the switch and work out the bugs; in her mind: get the data clean and do staff training and write documentation and then flip the switch]. I realized that the quick and dirty automation project which I’d been doing for low pay, about 2-4 hours per week, that I was hoping to be finished with by early this year, was likely to go on sort of forever. I didn’t want a forever-job and couldn’t see a way to wrap it up with only my own toolkit.

I’m not entirely comfortable with the way everything worked out, unclearly and with an uncertain “what next” point. I’ve suggested someone who I think can pick up where I left off, but he’s not me and the library really seemed to like me. That said, after a lot of thinking on this, I realized that I was trying too hard to be the hero, the librarian that sweeps in and takes the tiny rural library and automates it in something akin to the rural electrification project. Cracking the whip, keeping the momentum up all the way to the end.

I really wanted to do this job, without thinking hard enough about whether the non-me aspects of this project were amenable to the task. As Alex Payne says in his “Don’t be a Hero” essay (about programming but it applies everywhere)

Heroes are damaging to a team because they become a crutch. As soon as you have someone who’s always willing to work at all hours, the motivation from the rest of the team to produce reliable, trouble-free software drops. The hero is a human patch. Sure, you might sit around talking about how reliability is a priority, but in the back of your mind you know that the hero will be there to fix what doesn’t work.

For whatever reason, I didn’t get the feeling that the library was learning to use the tools themselves, I got the feeling that they were getting used to me being available to solve problems and answer questions. I’m certain this problem is as much my responsibility, if not more, than theirs, but I’d gotten to a point where I literally could not see a way out of it. And I dreaded going to work. And I couldn’t see a solution.

The Koha consortium project in the state is doing well and I have no doubt the library will automate. The librarian wants it to happen, though her timeline is unclear. I vacillate back and forth between thinking that the work I did was uniquely valuable and integral to the library being able to automate at all, ever, and feeling like a bit of a quitter, leaving the project when it started to bog down and get tough. I’m lucky in that I have a lot of real-life and online friends who have been supportive of my decision, but it’s still one of the tougher ones I’ve made in the last few months. [rc3]

Who Has What – Vermont libraries’ automation systems

Vermont has a new State Librarian and I’ve been diving into more of the reports from the state Department of Libraries lately. Their most recent newsletter mentioned the Who Has What page which is a list of which vendors all the automated lirbaries in Vermont are using for their catalogs. What isn’t mentioned is that Vermont has about 192 public and community libraries. The DoL list has 86 libraries listed in the public section. You’re getting that little unstated statistic, right?