Why IT people should be more like librarians

As a former IT person and a current librarian, I've got to say that this article,Want Good IT Customer Service? Visit Your Library, has a lot of truth in it -- I definitely see the differences between my former profession and my current one. And as the article points out, many of those differences are on the plus side for librarians. Not all, of course, but that's a different post.

Let's take a look:

I believe IT professionals truly want to help others. However, we tend to focus on the technology, not the client. We believe our job is to fix problems, and we expend considerable time and effort doing so. Unfortunately, IT professionals often spend little time communicating with clients (and sometimes even with their CIO) during a problem resolution process. As a result, your clients incorrectly assume that nothing is being done and they become frustrated. Once they start complaining to peers, the organization's perception of IT takes a hit.

*snip*

Let's consider the librarians' approach. Reference librarians focus their work around the library's users, rather than around the information materials they provide. Instead of solving the information questions of users, librarians try to teach patrons how to do their own research and assist them in using library technology. A key component in this work is communication, both face-to-face and through the marketing of library services.

*snip*

Outstanding customer service involves a lot more than sending your people to customer service training. It requires a mind-shift for most IT professionals and also for the organizations they serve. Good planning, excellent communication, ongoing practice and encouragement will change the performance of your IT team, and improve the rest of the organization's perceptions of IT along the way.

The author, Dawn Thistle, is the former library director and current CIO at Assumption College, so she has a good sense of things from both sides of the table, at least in academia.

One of the things she suggests importing into the IT world from the library is the concept of a "reference interview" or, a "technology interview" in the IT context. It's a great idea, I think, taking that traditional librarian concept outside the library into the wider world.

Like I mentioned above, there could definitely be a companion article on Why Librarians Should Be More LIke IT People. But librarians' intense focus on patron needs and trying to uncover their true information needs rather than focusing on technological solutions something we really bring to the table.

And to all the IT people out there who are reading this, let's start building up that alternative article in the comments!

(via)

More like this

My Stealth Librarianship Manifesto post from last month continues to gather comments and page views, albeit at a slower rate than before. Of course, that's very gratifiying to see. If you haven't checked in on the post in a while, there are probably a couple of new comments with librarians'…
(My apologies; this post inadvertently went up prematurely. If you were wondering where I was going with it, please read on!) I met Steve Koch at Science Online 2010, where he wowed me showing off his students' open-notebook-science work. I love, just love, teachers who do that. I wish the sort of…
Stealth librarianship is a way of being. This particular edition of the manifesto applies to academic libraries. The principles of stealth librarianship apply to all branches of the profession, each in particular ways. Other manifestos could exist for, say, public or corporate librarians.…
If you've read my blog at all, you probably know I'm a Taylor (1962, 1968) href="http://ejournals.library.ualberta.ca/index.php/EBLIP/article/view/650">groupie. In fact, in a recent  href="http://scienceblogs.com/christinaslisrant/2009/06/librarian_basics_the_reference.php">post I talked…

There is a hell of a lot more to IT than desktop support.

In fact, people who do desktop support are rarely actually IT people - usually they have very little specialised IT knowledge.
They're more like shop assistants - anybody can turn their hand to it, but many are crap. I remember a desktop support team a few years ago where one of our best workers was a secretary who decided she was bored of typing and wanted to try something different. She was great.

By Vince Whirlwind (not verified) on 15 Sep 2011 #permalink

Well, VW, I'm not sure the article is really about tech support. It seems to me that it's about the systems analysis and design aspects of IT.

I work in the IT support field, and I agree completely with the author. Far too many IT people assume that first, their customers/clients have a level of technical competence which does not exist, and secondly, that customers/clients want to have this level of expertise.

In reality, the vast majority of users want their computer to be like a Japanese car; Turn the key and it works. They are not interested in the technical minutiae

"Instead of solving the information questions of users, librarians try to teach patrons how to do their own research and assist them in using library technology."

In IT jargon that is known as RTFM. As comment #1 pointed out; there is a lot more to IT than the front line help desk.

A first level help desk is a kind of human firewall, it's main function is to filter out users who can't or won't RTFM, but that's where the fragile analogy with a librarian stops.

IT problems that cannot be resolved at the first human firewall are elevated to a second human firewall with expertise in the specific software/hardware, they have the skills and knowledge to answer esoteric questions and the authority to involve the developers (authors) of the software if they suspect a bug. - Not an option for a library user (other than typo's and errata sheets, books don't have anything analogous to a software bug).

Notice how each level increases in expertise and thus cost. Therefore if a user has enough money he can negotiate a support contract that will allow him to bypass the first or even the second firewall. - Not an option for a library user.

Disclaimer - No I'm not, and never have been, a librarian. I am a computer scientist with 20yrs commercial experience developing, maintaining, and managing large software projects.

Hi Alan,

Thanks for your comment. If you had bothered to RTFP, you would have noticed that I'm an IT person too, before I was a librarian. I am a computer scientist with over 10 years each of commercial software development experience and librarianship.

The wonderfully logical and graduated and precise process you have described is something that your clients and customers refer to as hell. They hate it and despise it and sense in their very bones the arrogance, condescension and self-importance of the "masters of the universe" who so smugly create the software support nightmares we all are forced to negotiate.

Librarians aren't perfect, but we are intensely patron focused. One of the most frustrating aspects of our jobs is helping our patrons figure out the byzantine search interfaces we are forced to torture them with by our vendors. Oh, I wonder who created those nasty interfaces? Gee, I guess it must have been software developers.

So yes, I do know that there's more to IT that help desk. Yes, I was a programmer, I was an analyst and project manager. Read my post again. Read the original post I refer to again. They do both refer to more than just the help desk experience.

I'd also suggest you maybe learn a little more about libraries and librarians. And then perhaps you would understand the commonalities in what our two professions do and where we can perhaps learn from each other.

Yeah right, I can tell how nice you are to your clients by your smug, arrogant, condescending, self-important, response.

Noted.

But I think the big difference between the two of us is that I'm coming from a place where I know I can improve, where I can acknowledge that both me individually and my profession as a whole have a lot to learn.

Actually where you see a big difference I see complete agreement.

Like everyone else in the modern world, I too have to contend with hell desks, buggy software, broken interfaces, and documentation that reads like it was written on used toilet paper.

Having said that, I put it to you that you're reading things between the lines of my original post that simply are not there.

You think you are detecting arrogance in me and maybe there is something to that, or maybe it's because you have the arrogance to assume you know what I think without actually COMMUNICATING with me to find out first hand.

Now the arrogant "master of the universe" in me is absolutely 100% certain it's the later, but the courageous self-skeptic in me is willing to look at evidence of the former.

The article is definitely talking about the IT helpdesk.

Yes, customer service is important to anybody providing a service.

The thing is, the geek who gets sent to fix your PC is an "IT professional" in the same way your restaurant waiter is a "hospitality professional".

In both cases, this "professional" gets crapped on every day of the week by the people he works for as well as by the people to whom he is providing the service.

So, a failure on the part of the PC user to undergo any kind of preliminary training becomes the Geek's fault when he demonstrates he lacks the skill, knowledge, and/or inclination to adequately explain how Microsoft Excel works in 5 minutes.
A failure of the PC user to understand what a "hard drive" or "USB Port" is, becomes the geek's fault for using "jargon".

The article is correct, but misses the mark: communication between service provider and client is a management issue, not a technnical one, and the geek fixing your mouse is purely technical.

By Vince Whirlwind (not verified) on 27 Sep 2011 #permalink

"Far too many IT people assume that first, their customers/clients have a level of technical competence which does not exist, and secondly, that customers/clients want to have this level of expertise."

This is rather like people who want a high performance attack helicopter but don't want to learn about helicopter avionics.

Many times, the problem you're experiencing is due to one of three things:

1) Bug or hardware error.
2) False expectation of user.
3) Incorrect operation by user.

In option 1, the IT guy will fix it or have absolutely no way of fixing it. In the latter case, he usually gets blamed.

In options 2 and three, you're going to have to take on some education. Or be like Homer Simpson, complaining that the microwave takes too long.

Because they're errors not in the IT but in you and the only way to fix it is to educate the user.