Day in the Life: The Three Most Important Things I Learned in Library School

I am working on a post about Information in Context, and it's taking shape while I slog through a huge database project, but I had to pause to capture this Day in the Life and the laws I cannot break myself against. There are three things I learned in library school that today seem like the three most important things. If every day were like today, then here is your guide to being an embedded librarian.

1. HTML: Thank you, Bill Kules, for making me learn to code in HTML by hand and not use Dreamweaver! I use this skill every day in this job. And the importance of this goes well beyond just being able to help out with web tasks in a small organization. When you know code, you have a better understanding of how to organize information. It expands your imagination on all projects. Our content management system can automate a lot of things, but if you can get in there and mess with the code (or even be able to look at code without recoiling in fear), you can be a resource to your webmaster and everyone else.
   
   
2. Web Accessibility: I cannot tell you how important it is that as a librarian you know a thing or three about how to make your electronic information accessible to people with cognitive, visual, or other disabilities. It is the perfect marriage between the person-centered approach of libraries, and the technical knowledge and skills that are increasingly important to our profession. If you are the only one in your organization singing this song, SING LOUDER.
   
   
3. Copyright: Embrace your duty to educate your staff about their own "copy rights," and speak up if you feel they are infringing on others' rights. Your organization may routinely give its resources away for free and without a vested interest in getting credit. However, you as the librarian, and I as the librarian, and we as librarians, have to work extra hard to communicate that not everyone feels this way about sharing information. When I was in Copyright Camp during library school, the SIIA's message to me was, "Don't copy that floppy!" I feel I am slowly making a mantra out of "Don't post that PDF!" Make your staff aware that you have copyright knowledge, and if you don't have some, make a list of your questions and ask another librarian.
   
   
   
   

Advising Work Teams on Blog Projects

I noticed that I have been advising teams on blogging a lot lately, and in listening to myself talk, I decided that I know, or think I know, something about this, so here goes... If you are asked to weigh in (or, perhaps, even if you're not), here are some talking points to guide a content team toward better blog decision-making.

To blog or not to blog? Do not be afraid to ask someone to take a step back and more thoughtfully consider the decision to start a blog. You may find that people assume they should have one for their project or other misguided assumptions along the lines of "everybody's doing it." Have the conversation; the team may gain a lot just from being led through a thoughtful discussion about their current information outputs.

What will be this blog's focus? If there is not a topical focus, personal narrative structure, or unique point of view in the blog, the team may wish to redouble its efforts with current communications platforms rather than adding a blog. If the blog is meant to replace some other current output, such as a newsletter, have a conversation about whether the exact same content will be shared via a blog. This is a good opportunity to talk about blogging as both/either a genre or a technology. The team may be considering blogging just because the mechanics are easier than something they are currently using, or they may be looking to personalize their content a bit more--both good reasons for choosing to blog, but the team may not have given this any thought and may be headed down a path of repeating much of what is available on your website.

How will we build an audience for this blog? The team has probably done some work to promote (and get readers used to) other forms of communication. Do not let them assume that those constituents will just slide right over to their blog. This point is larger than just the learning curve that may be an obstacle for some members of your audience; it also has to do with building interest in the new focus of the blog, if it has one, as well as getting readers used to using comments features. (In fact, you may be dealing with a project that wants to start a blog but never even considered the comments feature...which is a whole discussion in itself.)

How will we sustain an audience for this blog? You may fulfill the important role of 'cautionary tale,' or helping people put the breaks on if they haven't fully thought this through. There will be a lot of genuine enthusiasm among some people about starting a blog, but they should resist the initial excitement and channel it into a solid long-term plan for evaluation and follow-up after a test phase. They should also think about posting to the blog for a while as practice, and slowly releasing the content to larger and larger circles, starting with internal staff (although they may heartily resist staying in any sort of "Beta" phase).

*Who will do it? This is not as simple as it sounds. It may be a team effort of people contributing posts and/or content for sidebars, even if the blog appears to be coming from a director or project leader. Everyone can help, but have a clear division of labor chart that indicates who is doing what, by when, and who the back-up person is for each task. If there are going to be multiple authors, or guest bloggers, hammer out the details of how this will work.

How often? A team may think they have to blog every day to be effective. It all depends on the focus and scope. A monthly entry may be appropriate depending on the project. Posting at regular intervals is more important than posting often. In fact, advise teams to have a white board (electronic or otherwise) to help continually plan the next series of posts, which helps people resist the urge to post something as soon as they think of it.

How will the blog integrate with our current web presence? If you have a website, or a portion of one, for this project, and you are adding in a blog, be careful. If the sites co-refer, do this strategically. If one of the goals of the blog is to get people back to your website, then do that, and do not re-post on your blog everything that is available on your website. Think about what the process will look like when new content arises and everyone is sitting in a meeting trying to decide if it should be posted on the website, the blog, both or neither.

How will we integrate the blog into our overall information/communications strategy? This is the part where you inventory all the current outputs and make sure any overlap is strategic. If you Tweet, will you Tweet the new blog posts? Is the blog replacing another current task or are additional staff and resources required? Will you use the blog to draw attention to new publications and then link back to your website? Will you discuss publications on the blog and is the blog one of your publications? What policies, such as web accessibility or company approval, that govern other communications need to be applied to the blog? If your stakeholders will think you are pushing out too much information, are the tools you're using customizable so people can select how much they want to get?

Should we use a stand-alone blogging platform? Platforms like Blogger are great, and easy to use, but there may be a clear advantage to using your own system if it keeps people on your website (or it may be a policy not to use an outside platform for official communication). Your content management system may also have built-in tools for blogging, but these may or may not make subscriptions easy for readers to unify with the other blogs they read. There are probably advantages and disadvantages either way--explore them.

What will be the role of the librarian? This is a great time for you to step up the kind of services you offer any team you're embedded with. If you are involved from the beginning with any sort of blog project, you can think about things like archiving the posts on your own server (if there is a concern about that), cataloging the entries (if applicable), and helping with tech support and troubleshooting if you know the selected software.

If you engage people on these points and they say something like, "Let's not overthink this; it's only a blog," be ready to point out (very diplomatically) the flaw in this approach. You need only point to a few abandoned and/or inactive blogs to show what can happen if people do not undertake blogging decisions with the same rigor they would a print publication. A colleague of mine once said, "There is no exact recipe for success, but there are known ways to fail." Be a resource to all the potential bloggers on your staff so their work, with your help, will be successful.

Help Yourself

I usually write about my successes. I need to learn to write more about my challenges, but without complaining.

I am a terrible cataloger. I avoid it at all costs, and when I do finally manage to do some, I cringe to look at the Date Modified on my catalog, which is just an Excel spreadsheet. I have piles on my desk, and in the library, of items to catalog. All this from someone who was lucky enough to have an actual set of the LCSH 'red books' in her office on Day 1. (Not that they are current, but still, pretty cool for a no-budget choose-your-own-adventure library job, right?)

Note: Early on in my tenure here, I was told not to catalog. And after I came to, I asked why. Basically, this is not really that kind of library. If I get something in print (or electronically, for that matter), they would rather have me share it right away with the appropriate staff member rather than take the time to catalog it. They are ultra kind people, but that doesn't mean they understand the importance of cataloging. And yes, it's partly incumbent on me to communicate that. A few months after the 'don't catalog' conversation, when I had gathered ample confidence and the right talking points, I approached my supervisor about this. We had a nice conversation about being user-driven versus being library-driven and it was very useful. As an embedded librarian, I have one foot in the content world of my staff and one foot in the library. It's a balancing act. I explained that if I am expected to find something later, then I should catalog it sooner. My memory is good, but not that good.

This is never the kind of job where there is 'no time' for something, so it's not as if taking the time to catalog would be at the expense of some other urgent activity. My supervisor and I were able to clarify that it's not a priority for anyone but me, but I am more than welcome to spend my time doing it as long as I am also delivering the deliverables, which are more reflective of the embedded nature of the position.

Now I am at the point where I definitely feel I should be doing better on cataloging but it's entirely on me -- both the desire and the responsibility -- unlike all my other work which is either a deliverable or a team-oriented task. I know I can do it, but I just don't. Despite the fancy label maker I have in my desk drawer.

So, I've decided to help myself. I have added in all kinds of things to my work routine that no one is making me do. I'm a librarian; why can't I catalog? I make myself read an entire GAO report each month, in addition to all kinds of other non-required activities. I know how easy it will be to find something once it's cataloged. I love playing around in Excel. I can do this.

I cataloged one item yesterday and one today. Each day from now on, until I have cataloged at least one item, I will keep my label maker right in front of my keyboard, which is terribly inconvenient, to remind me that this is really not that hard unless I continue to overthink it. Wish me luck.

To Do, Ta-Da, and Everything In Between

One of the quotes in my Embedded Wisdom list (see sidebar) is, "You cannot break the law; you can only break yourself against the law," and if you follow me in any way shape or form, you hear this over and over again. You hear me stumble through how it relates to my new tattoo design, why it's the middle epigraph in my novel, and why I insist on bringing it up over and over. I have not yet found a way to articulate it for best effect, but I've transcended ever questioning whether it is the most important bit of wisdom I have ever heard or read. In a nutshell, some ideas keep falling into your path or getting in your way over and over again until you recognize them.

Here is one for you: Make a To-Do List. When I try to come up with something for the Task Mastery 101 sidebar, it usually ends up being about To-Do Lists. Sometimes I hesitate to post those tips because, really, what could be more of a snooze than having someone recommend that you make a list of the things that you'd like to accomplish? But over and over again I find that it often is just that simple. Here are a few reasons I decided this was post-worthy:

1. The act of making the list organizes my random thoughts into discrete tasks;
2. The act of making the list facilitates prioritization and decision-making; and
3. The act of making the list moves me from inaction to action.

If that is not enough, consider this: Keep your lists. See what you checked off and what you didn't. Build evidence of what you are actually spending your time on, and what things you did not get to because you were fixing the printer or making name tents. Write in what you actually did instead of something on your list. If someone asks you what you've been working on or what you have accomplished today/this week/this year, consult your lists. Use them to revise your job description when it's time, or to draft a work plan for your library.

Last year on the Solos list-serve someone posted a great document of what she does daily/weekly/monthly/annually in her library and it was quite detailed. Parts of that could become an intern's project description, or the scope of work for a contractor, or a part of your professional portfolio. It becomes the documentation for you and everyone else of how you spent your time, and how much time things take.

In the spirit of "something for everyone," here is a new take on an old idea, that of the "To Not Do" List, which will surely be referenced when I post my magnum opus (portions in Latin) on Selectivity. Stay tuned.

C.U.R.T.?

Can yoU Read This? Or is it "brief and incomplete to the point of discourtesy" if I initialize it instead of spelling out what I am really asking? That is the definition of curt I found in the mammoth 1940 Universal Dictionary of the English Language that I keep in my office. Granted, in a previous post I explained that my background in linguistics makes me much less of a prescriptivist than you'd expect, especially when it comes to dictionaries, but I think the general concept of curtness is an apt metaphor for what happens when we do not control one ubiquitous and possibly confounding aspect of our work: Acronyms.

I had a great teacher in library school who encouraged his students to approach Wikipedia as a "fact of life" and not an inherently bad thing, just one that librarians should use with more thoughtfulness and caution than the average user might. I feel the same way about acronyms: they are there for a reason and they can make our life easier. Nevertheless, acronyms pose obvious problems to new staff at an organization, visitors to your meetings and conferences, and even you if you don't know what they mean.

The first rule of acronyms: Ask. If you hear one in a meeting, write it in the margin of your notes and ask what it means at the first appropriate opportunity, which may be right away if it's crucial to your understanding of a task. It may be the case that you figure it out from context and double-check it after a meeting, or follow up with the person who used it.

The second rule of acronyms: Keep a list. The librarian is a key person to document miscellaneous knowledge in an organization, and making an acronyms list is a great way to start. This list will have 101 uses. Make it available via your intranet (or via a public web page if appropriate) and have a way for people to suggest or add changes. Offer it to conference organizers to include in the program if guests from outside your knowledge speciality are attending. Include it, or a relevant portion of it, in your organization's standard publications.

Think about how you feel when you get a very short email from someone without a lot of context or elaboration (especially in customer service situations) as opposed to a thorough explanation. The longer explanation usually adds to your understanding, makes you feel valued, and shows that the person on the other end gave some thought to your point of view. The same is true for acronyms. Avoid seeming curt or exclusive by giving everyone who interacts with your organization an opportunity to be "in the know" and figure out what people are saying.