Thinking about technologies as tools
It's very easy to get caught up in the hype of whatever new technology is receiving mainstream press and funding. Often adopting a technology at this point is a good idea, but other times it's not. So how do you know what the right thing to do is?
An effective strategy can be remaining focused on the big picture. What are you trying to accomplish for your users? Use the expertise in your organization to compare the goal against what the actual technology (not the hype) is offering. You'll find many good matches to throw your support behind. You'll also find plenty of poorer matches as well. You're not being left behind if you make an informed decision that a particular technology isn't right for your organization at a particular time; you've just been a good manager.
It's certainly a delicate balance, and seeing a particular technology for what it truly offers works both ways...it's just as unfortunate to reject a technology because of the hype as it is to accept it just to be "trendy" or to think you're "missing out" on something.
Fair or not, in the broader technological community libraries still appear to be catching up to 2001. Case in point: a recent topic for a library-related presentation/workshop/seminar: Blogs and RSS: An Emerging Technology.
Emerging? Perhaps in 2002-2003. The world now yawns at blogging and RSS...it's as startlingly new as the mobile phone.
The problem is that libraries as a group have tended to shy away from anything that doesn't involve Dreamweaver, FrontPage, or WordPress, or prohibitively expensive commercial systems, many of which sport application architectures that seem to reflect best practices from 1997. I won't name names, but they know who they are :-)
Add into the equation that many of the decision-makers are librarians who don't have a hands-on knowledge of the technology to begin with, and who, in many cases, often distrust it (c.f. many librarians' reaction to Google's latest efforts), that the hype in the library community tends to edge toward the Luddites as opposed to the early adopters.
The effect of all this is serious, however. Libraries once cornered the market on being the most relevant repositiories of information and culture. But technology has not only democratized publishing...its democratized (to a degree) the classification, storage, and delivery of information.
Indeed, hopping on every new technological bandwagon that comes along is not the answer; neither is rejecting it out of hand. But by defaulting to baby-steps where technology is concerned, many libraries may find themselves riding the tech equivalent of the horse and buggy while the rest of the world has moved on. I hope that doesn't happen just as I hope we don't surrender our sense of history to the latest whiz-bang on the market.
The library as we know it is a long way from being superseded, but that, I think, is the (very real) robotic elephant in the room, and the library needs more people who can dissect that elephant, and learn from it.
A good way to model one's thinking about tech solutions is to use "top-down" programming models.
These are service models structured as flowcharts. At the top (the CEO position) is your desired outcome (unfettered access to the catalogue? community engagement? better awareness of services?).
In the "assistant/deputy" section are you success measures (increased visits to the website? higher circ? positive comments? quicker access by users in beta tests?).
At the VP level are the IT outputs that lead directly to the desired outcome. And for each output there are further actions that would lead to that output occuring and so on until you cannot get any more detailed.
Having these details ironed out will help your IT people better understand what it is that you want to happen. And if you have more "dreamers" than coders or Systems people, you may even want to go as far as to attempt some Pseudocode to further outline how you want the technology to work.
Starting with the outcome (what will make the world better for library users)? and drawing outputs that lead directly to that outcome is a good way to keep focussed on what could be a very complicated project. It also helps communication. (You can show Directors only outcomes and outputs; your techies in turn may want to focus more on the actions).