Jessamyn West wrote a rather thought provoking post on librarian.net recently entitled on heroism. In essence, she withdrew from a project that she was managing because she was “trying too hard to be the hero.” In the post, she references the essay “Don’t Be a Hero” by Alex Payne. Payne writes that:
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.
It sounds as if West wanted to avoid becoming a human patch and believed the best way to do this was to remove herself as lead on the project.
Ultimately, this post made me think about my own experiences as my library’s technology expert (which is indeed part of my job description). In this position, it is natural for me to often be the lead on those projects that rely heavily upon technological expertise – or even just the lead on specific parts of projects. This means that my job responsibilities often change with each new technological initiative – as I become the owner of some specific task or system. It naturally follows that people continue to look to me to answer questions and/or to fix things.
But where does one draw the line? I definitely struggle with this issue. There is a fine line between becoming the expert (as opposed to the human patch) and creating an atmosphere which does not encourage others to step up and take ownership. For most technologies, I do become the expert and then depending on the situation either become the owner or pass along the reins to another individual designated as the owner. The end result depends heavily on not only the personalities involved, but also upon their workloads.
Letting go of things is not easy. I can admit to being a bit of a control freak – and as such, I have created situations where I am the only person who can deal with certain situations. Maybe it wasn’t apparent who should be co-owner of an application; maybe the people involved were not technical enough to take responsibility; maybe I was too rigid in my expectations. I suspect that the reasons why these things happen aren’t always clear cut or easy to untangle. Either way, it wasn’t healthy for me or for the library as a whole. And, I really can’t pretend that the situation doesn’t still exist.
However, I have made letting go a priority over the past couple of years. Has it helped? Sometimes yes, but very often not. I have felt as if the decision to let something go has come back to haunt me because it has on occasion impacted service to our students, which for me is the worst end result of any decision. This is one of the reasons that I feel as if our systems department needs a bit of an overhaul. It isn’t as simple as taking on all the responsibility or letting it all go. There has to be a middle ground where we are the technology experts, but also help people develop enough confidence and skill to be able to fix their own problems. And I admit that I need to find better ways to help people achieve this level of technical confidence.
As things stand, I am very often a human patch in my day-to-day work life. I’m starting to actually think we should not consider this a bad thing. It is all about balance. And, I have learned that people often feel better just knowing that there is someone in the building that can help if need be. Sometimes, this gives people the confidence to try things themselves. So, my goal is to let go just enough to let people become their own heroes every once in a while, but not let go so much as to frustrate the library staff or our students.