The first session of Monday presented a bit of a problem for me. There were two sessions that I wanted to attend so I had to decide. It was between a session about improving the library’s web site or tips for fast tech implementation. I chose the fast tech implementation because the description mentioned ninjas and I’m a sucker for ninjas. I’m glad I did.
This was an informative and entertaining session. It was a panel of three accomplished tech librarians: John Blyberg, Sarah Houghton-Jan, and Amanda Etches-Johnson. They offered some of their tips for getting tech projects done as quickly as possible without creating a lot of friction in the library.
JB – People are key. Every library has lead users who take the initiative to learn and implement new things. Those people should be embedded in the library to act as change agents and provide feedback from the rest of the staff.
AEJ – A small group with a lot of autonomy works better than a committee.
All – Know your library’s strategic plan (we have one right?) and how your tech ideas fit into it. Don’t implement new tech for it’s own sake. It should fit into your library’s goals.
SHJ – Blend in and sneak up. Make changes without asking…sometimes. Her example was of a link she added to her library’s contact page that no one noticed until a few months after it had been there. If she had asked for permission it would have taken months to get the link there.
SHJ – Plant seeds. Covertly send out ideas via email/mentions at meetings about things you are interested in implementing. Kinda like “Hey look at this neat thing x Library is doing” and leave it at that for a while. Educate without asking to be allowed to implement first
JB – Get past the FUD (Fear Uncertainty and Doubt) by providing a counter vision that you and others can attach to and be passionate about. Don’t get bogged down with people who don’t know what they are talking about. But don’t dismiss them.
AEJ – Follow evidence based practice. Encourage due diligence. Look for other similar experiences in other libraries/organizations. If no one has done it before do it anyway and document what you encounter.
SHJ – Avoid collateral damage. Try not to step on any toes. Talk to the right people in the right departments and locations. Find and involve key stakeholders early. Who will your project involve and impact? Have them help you with designing the scope and goals of the project. You will need these people later. If the people you are working with have unrealistic expectations you can over ride their decisions but do it with tact.
JB – Was asked the question. “What if you are wrong? What if your idea doesn’t work?” his respsonse was interesting. He said you should deploy your project like a fire jumper. Meaning that you establish a foothold, stay as long ad possible and give your project everything you’ve got. All the time and resources you can throw at it. If you fail, own it and learn from it. Was the idea bad? Was it fundamentaly flawed? Did it nothave enough resources? Don’t be discouraged. Sometimes an idea may be too soon. Maybe it could work in a few months.
AEJ – Committees = bad
Not the people but the structure of a committee.
Project Teams = Good
Project teams are for a limited time and have a specific goal. Need buy in from the team.
The example she gave was how she disbanded her library’s web committee in favor of a project team when it came time for a site redesign. She kept some of the people and the team worked well.
All – Drink heavily
SHJ – When to ask for input versus justmoving forward?
It’s judgement call. Know your staff and stake holders. What is the likely repercussion if you move forward without asking and it goes wrong? But sometimes it is better to ask forgiveness than permission. Trust your instincts! If you’ve done your research and know your stuff trust yourself. You know what you’re doing.
JB – Know when to quit. It’s not about what you put in but what you get out.
JB – Win hearts and minds. One way to do that is to shore up the infrastructure. If the servers are always crashing then people are going to be less likely to want to try a new tech tool. People want stability. Stop having to react to (structural) problems. Work with IT to fix those problems.
The question was asked “How do you say no to a bad idea?” I don’t remember who said what but their answers were good. One was to check your library’s goals to see if the idea matched up with them. Another was to do your research before you answer. Involve other people or committees maybe they will say no for you (the ‘punt’ method)
Great session. Definitely some things I can take back to work.
Here are Sarah Houghton-Jan’s notes. Way better than mine. That’s why she’s a presenter and I’m a listener.