Easier to ask forgiveness ...
Did you ever hear the story about the brisket? No? Here's how it goes:
A young girl is watching her mother prepare a brisket for the very first time. Before putting it in the pan, mom chops off both ends of the meat and tosses them out. The girl asks, "Mom, why do you cut off the ends of the brisket before you cook it?". Mom looks puzzled and says, "I don't really know – that's how your grandma always did it". So, the next time they visit grandma, the girl asks, "Grandma, why do you cut off the ends of the brisket before you cook it?". Grandma thinks back, wrinkles her brow, and says, "Well, I don't really know – that's how your great-grandmother always did it". The girl just can't let this go, so the next time they visit great-grandma in the nursing home, she asks, "Nana, why do you cut the ends off the brisket before you cook it?". Great-grandma can't help laughing, as she answers: "Honey, the thing is – we used to have a really small pan".
The tale of the brisket plays out every day in libraries, where we easily get bogged down in "this is how we've always done it", until someone with a fresh perspective comes in and can't stop asking: "but, why?".
But, why?
It seems silly, but when we start applying the "but, why?" question to our procedures and practices, we often find places where we've been doing things for reasons that are no longer valid in 2010. As in our brisket story, sometimes we have to keep asking until we either dig down to the original reason – or find that there really is no reason to continue doing things the way we've always done them.
Black ops ninja style projects
At the Computers in Libraries Conference in April 2010, I attended a session on "Black ops ninja style technology projects" – mostly because of the title. (Wouldn't you have sat in on that session?) The panelists emphasized the importance of being subversive, being sneaky, and finding your way around "no", and had real-world examples of smaller tech projects they'd implemented quietly. It's easier to ask forgiveness than permission, and once something's been working seamlessly for a while it's easier to say, "Well, it's been that way for a couple of months now and our users really like it".
Again, this all boils down to the willingness to question and to try things outside our everyday roles and our library's everyday expectations. Think: what are you chopping off in order to fit into your assigned role in your institution? Are you refraining from making suggestions, making plans, or expanding your role because you're used to confining yourself to a specific set of responsibilities? Well ... get a bigger pan!
You hear the constant refrain: go where the users are; embed yourself within your organization. We can't do this effectively until we take a good hard look at what we're losing by staying within what we've always done.
No means: "try back later"
In libraries, "no" doesn't always mean no. No can mean: come back in six months, come back when we have funding, come back with a different approach, come back when we're done with a current project, come back when you're able to show you're willing to take ownership of this project yourself, come back when you can show how other libraries have successfully done something similar ...
When we're newer to libraries or to an institution, we tend to take that initial no for an answer without asking that ever important: but, why? Not that you should respond in just those words, but be sure to delve a little deeper. Is it no because you didn't present your case well, or no because it seems scary and new, or no because the proposal needs some tweaking, or no because it's unclear how it fits into the library's mission, or no because it sounds expensive? Get to the root of no, and you can find ways to either work around no – or get to yes.
Once you ferret out the reasons for no, then think of how you can present your ideas in a different way. If the answer is no because your supervisor is too busy to deal with anything else right now, make it clear you intend to take ownership of the project and have concrete ideas on how you personally can run with it. If it's no because it's unclear how your proposed project fits into the library's mission, make it clear – know your library's mission and goals backwards and forwards, and show how this helps move the library towards those goals. If it's no because it seems too new and scary, research how similar projects have worked in other institutions and present that evidence.
Those ninja-style tech projects panelists have another word of advice here: once you start sneaking info about a project in front of people, it's no longer a new and scary idea. Want your library to have a twitter presence? Start sending out e-mails about cool things other libraries are doing with it, introduce some statistics, and when you later suggest the idea it will be a familiar notion rather than a completely foreign prospect. Take some time to start slowly expanding that pan.
The perfect is the enemy of the good
This is hard for us as librarians to swallow. What do we like to do? Research. We like to find out information about any proposed project – the more, the better. Then we like to discuss that information, which of course means that we go back and find more information to fill in the holes. We like our committees and our meetings.
But, when we put things off until we can do them "right", sometimes the outcome is that we never do those things at all. We can embrace the idea of "beta" projects from the tech industry: sometimes, you just try it. If it doesn't work, tweak it; if it's not the right fit, drop it, and see what lessons you can learn for the next time.
From "but, why?" we can move on to – "why not?". Why not give it a try, why not propose a project, why not move outside your comfortable, assigned role to try something different? Why not?
Rachel Singer Gordon is webmaster, LISjobs.com, author of What's the Alternative? Career Options for Librarians and Info Pros, and blogs at The Liminal Librarian (www.lisjobs.com/blog/).