Lately I’ve been reading a lot about the frustration a lot of you expressed after returning from exciting tech conferences when you struggle to translate that new stuff you’ve learned into something you can apply where you work. You’re not alone; it *is* frustrating.
It’s hard to learn to account for the differences between a conference setting where you learn about the potential of some shiny new thing and doing something real and useful with it. What you get at a conference isn’t reality - it’s a notion of what’s possible utterly divorced from what’s real.
As someone who’s lived through enough of that frustration to have left jobs over my inability to prove anything more than that I sometimes will have something useful for other people to look at, I’ve picked up on a few non-obvious things about how to weigh what you learn with what you know about yourself, your shiny new tech, and your work environment. Maybe some of these suggestions will be helpful for you.
1. This is not about you
You are not the technology, and it is not you. Even if you *invented* it, if people reject it, they’re not rejecting you. When you’re hearing exciting things about some new thingy at a conference, you’re hearing about it in a vacuum of slideshows and articulate presenters with some measure of showmanship. But technology that really works for people doesn’t exist in a vacuum — it gets used by real people in a real context to solve real problems — or it disappears. For something new to catch on, it has to work for a good number of people and fit their diverse mental approaches to fulfilling tasks and problem solving usefully, in a way that works in specific places using specific equipment. And these new people coming to it for the first time are not coming to it with the same skills, experience, insight, and enthusiasms you have. So when people see the new thingy you show them and they then reject it — and they usually will, just get used to it — it’s probably because some of these elements are out of place for them in that setting, and not because there’s something fundamentally wrong with you. Even when you gain more experience about how to be that articulate salesperson yourself, it’s still just a technology. Once you see yourself and the role you play as a librarianly meta-tool who is bigger and better than any particular technology, it can be easier to see how to make real tools work for real people in real places near you. So don’t focus on rejection of your cool idea as a rejection of you or your ideas. Just focus on the details of why it didn’t work, and Abort, Retry, or Fail the technology or the particular context of use and users from there. Because it’s so important to understand this context of use and its users, though, the next tip is to...
2. Know Your Environment
You can be the hottest hotshot there is, hired into some exciting new place based on what you knew and did before with Fancy Tool Q, but when you start that new job, the context in which you had so much success with Q at your old job just might be completely irrelevant at your new gig. You might not be the only expert at the new place, or maybe people there once took a good, long, healthy look at Q there and found legitimate reasons not to use it. Those valid reasons might just not have existed at your old place. You have to come to know the new environment, the mission of your work there, and the nature of interactions between the services you provide and the community of people counting on those services. You can’t get that all on your first day, month, or even year at a new job. It’s very easy to run into walls when the assumptions you make about How Things Should Work smack head-first into The Way Things Have Come To Work, For Whatever Reasons, whether you think they’re right or not. It’s on your head to figure out your way around. Which leads to...
3. Know Your History
There’s a reason the place you work is the way it is now, there’s a reason your boss is in the position they’re in now, and there’s a reason your organization delivers its services the way it does according to the policies it’s set. All of this might look to a new employee or in the face of some new technology as utterly ridiculous, but there are usually good reasons that you should understand for how things came to be the way they are. None of this means that services and policies and technologies shouldn’t change — far from it. But if you can’t frame what’s exciting and useful about the new thingy you want to sell people on in the terms of what they already know about the context of services and policies present in your environment, then you’ll always be speaking a foreign language to them.
There are probably people around who remember installing the first fax machine (“but the quality is so *bad*!”), or trying UPS for the first time (“are you *sure* we can trust them to deliver this package?”), and can tell you what it took to convince people back then that those were good things to use. If you’re in a place with a rich history of its own, go learn something about that history. Understand how your institution was birthed, and by whom, and how traditions around you have changed over the years. All of this will tell you a lot about the scale of impact your new thingy can have, and the possibility of its success, and whether it even fits. Find that co-worker who really knows this stuff and buy ‘em coffee until they lead you to some of these stories. And while we’re on the topic of people...
4. Find a colleague who knows “how to do stuff here”
There’s probably somebody you’ve already met who’s maybe a bit older than you and whom you’ve grown to admire because they clearly know how to get stuff done around the institution. It really doesn’t matter who they are or what they do — they don’t even have to work in a tech-related position. What matters is that you’ve noticed that this is somebody who knows how to take on a substantial task, to frame its goals and objectives in a way that allows steady progress, to coordinate cooperation, and to hit their milestones on a solid timeline. People like this are the most important people you will ever interact with at your institution when it comes to getting a new idea pushed forward. These are the people who will know when there’s a project you might not know about yet but which might be a good target for your new thingy. They’re going to know who’s leading the project, why your thingy’s a good fit, who the first person for you to get in touch with should be, and how to demonstrate and sell your idea in a way that’s compelling to those other folks. There are effective people like this everywhere, and though you might not think at first to ask for this kind of advice from someone who doesn’t dig the shiny tech stuff you care about, none of that matters. This is not about you, remember, and it’s not about any particular tech, either. It’s about how you’re going to get something new done where you are, so find people who already know how to do it and cleave unto them, because they have a lot to teach you. But all of this is fruitless if you don’t...
5. Know Your Stuff
That moment at a conference when you get excited about the possibility of adopting that sexy new thing somebody else had great success with at their place is fleeting. When the rush wears off, it’s on your head to really understand why it succeeded at the other place, learn the thingy yourself, and to make sure you’re prepared to evaluate it objectively for yourself. Understand what it is and how it works, of course, but also learn how it compares to other options. There are *always* other options. Very few of the new exciting things you can do over the network these days is really an entirely new thing in a library. Sure, they might seem overwhelmingly quicker, faster, more efficient or more dynamic than what your user community is used to, but they’re still not really New — and when you know your environment and its history, you’ll see that more clearly. Ask yourself: how does this save time, or save money, and how does it reach more people in a way that works for them than we could before? You’re only able to answer these questions fully when you know the full context of how and why people have been able to make do with that crazy old thing they’re doing now. (Yea, for that crazy old thing was itself once a strange new thing etc. etc.)
A good step is to use it yourself on some real project that matters to you. Don’t just get an account, tweak your profile, slide some widgets from one side to another, and decide that it’s the bee’s knees. Find some low-risk opportunity to apply it to some task you control and see whether it’s really worth the time and energy to use it. You might find out that it’s not going to do quite what you thought it would — or maybe that it’s even better than you expected — but you sure don’t want to learn that it’s going to fail right at the moment when you’re trying to sell somebody else on it. The people you try to convince to use it are going to have a lot of questions about it, and they’re going to look to you for answers, so be ready with those answers. Be ready, too, to recognize that some of your colleagues and users have pretty well-nourished mental toolkits of their own for evaluating new tools, too, and they might see something that you missed, based on experience you don’t have yet. If this happens, it’s no calamity. If you’re well-prepared, and listen closely, you’ll be able to work together to think through the issues objectively and critically. You both walk away knowing more, and will be even better prepared the next time some shiny new thingy catches your fancy. Which leads us, finally, to...
6. Diversify
No one technology is going to lead you (or at least most of you) through your whole career. Honestly, I don’t know anybody who’s spent their whole careers fiddling with just one thing. So even when that great conference talk fires you up about trying out Foo, you can’t afford to stop at wanting Foo. It’s true for any application, or markup language, or programming language, or standard, or web service — at some point, it won’t be the best fit for what you need to do, and you’re going to want to know about other options. The kind of scenario that has played out the most in my experience has been the one where, after developing that relationship with the local Gets Things Done guru, and learning my way around a place a bit, and getting psyched about some new thing and talking through it with the guru, they then say “yknow, that’s close, but it’s not quite right. If only it also did Bar, or could talk to the FooBar Server, etc., etc., you might be on to something.” At that moment, if you only really know Foo, and not about Bar and FooBar, you can’t respond to that suggestion. At all. And you might — right there in that moment — have just missed your opportunity to change the world — or at least the small corner of the world you’re paid to serve — with Foo. The goal isn't to be the articulate salesperson at next year's conference saying "we did Foo too!" They already heard about Foo, too, remember? Position yourself to serve your community with Foo, or Bar, or FooBar, or whatever it might take, and then you'll have something to sell to everybody else.
-=-=-
I hope some of this is useful to you. If there’s one key thing I want you impress upon you, it’s that even though somebody else’s rejection of your cool idea isn’t about you, it’s still all on you to prepare yourself to succeed the next time, and to be ready to handle many more similar failures gracefully. Don’t just point your finger at your boss, or your coworkers, or those stupid users, or those administrators-who-can’t-possibly retire-soon-enough, or that association, or the profession as a whole, or Society Today, and stop there. Maybe you’ve struck out a few times, but if you’re learning each step of the way, making progress on all the fronts above, you’ll find yourself with a hit someday.
But then again, even when you have a hit on your hands, don’t stop there, either. Someday, some young punk’s going to come around telling you how lame your old thingy is and why it’s stupid that you’re not doing everything his way. Trust me, it’ll happen to you, too.