You may be familiar with the scenario: the faculty member groaning (often justifiably) that it’s taken so long to get one simple project off the ground that she’s given up on trying to work with librarians. Or the administrator who wonders why librarians aren’t trying harder to learn new skills.
Having actually done some digital humanities in the library, this attitude frustrates me, though I understand where it comes from. In my experience, many of the barriers to completing digital humanities projects in the library arise not from librarians themselves, but from a set of institutional and administrative factors that will be familiar to most people in Libraryland.
This is not to say that DH isn’t done in the library. It is, and well (though, as my colleagues and I found, it’s often being done in a pretty piecemeal fashion that relies more on individual librarians’ persistence than on institutional support). And it’s important to note that DH was being done in the library (and in the archive) well before it made its way into academic departments.
But I’m thinking of the libraries where DH hasn’t really found a foothold, where a faculty member or administrator is starting to wonder what’s wrong with their librarians that they can’t seem to marshall the resources and expertise to collaborate on DH projects.
I’m writing an article for the Journal of Library Administration on some of the barriers to getting DH done in the library, and I could use your help making my list. I think that these challenges all have solutions, and that there are really excellent reasons to persist in doing DH in the library. But as Bethany Nowviskie has said, librarians’ vaunted service ethic sometimes prevents them from being candid with faculty and administrators about the challenges they face and the resources they need. I promise to offer solutions, too, but I think it’s important for us all to be on the same page about what we need in order to do DH well.
I have a number of ideas, based on experience, discussions, and research, but I would really appreciate your additions and corrections to my list in the comments. Or perhaps you’d prefer to email me at email@example.com.
Insufficient training opportunities
This challenge comes up quickly in any discussion of DH with librarians. Funding for training opportunities is often scarce, and it can be very hard to justify to supervisors why one needs to take a class in, say, Python, when one’s job responsibilities don’t currently include Python. Moreover, it’s not always clear where to go for training. Computer science classes are often too, well, computer-sciencey, and it’s very hard to know which language or skill one needs to start with.
Lack of support for librarian-conceived initiatives
In a library, responsibilities and opportunities are apportioned in ways that faculty sometimes have trouble relating to. Libraries are very concerned with metrics, with assigning roles efficiently, and with meeting patrons’ demonstrated needs. Projects often get assigned from the top down, and it’s not unusual for a project sponsor to be asked to prepare a business case to show that an initiative will meet a need and benefit the library. Many DH projects don’t meet any particular demonstrated need — they’re done to find an interesting answer to an interesting question. This can be very difficult to explain to one’s supervisors in the library.
Brian Mathews has urged libraries to “think like a startup“: to “face the future boldly” and “implement new ideas.” But libraries can’t do this unless librarians can do this, and right now, many of them aren’t being permitted to implement the bold new ideas Mathews and others would like to see. (To see what happens when librarians are encouraged to conceive new initiatives, check out the Harvard Library Lab.)
Too many tasks, too little time
With all the hand-wringing about whether the library has a future, it can be easy to overlook the fact that many librarians actually feel overburdened. Most subject librarians cover multiple disciplines, and with purchasing, instruction, outreach, professional development — well, it all adds up. Time for a DH project has to come from somewhere else, and many librarians don’t feel they can keep doing their existing jobs well if they add in something else.
Lack of authority to marshall the appropriate resources
In my mind, this is one of the biggies. When I worked in the library, I’d sometimes fight the urge to hide when I saw a faculty member coming at me with a project idea — even if it was a great idea, even if I really wanted to do it. I’d start tabulating the resources it would take to get this thing done: time from a developer, time from a designer, time from a metadata specialist, time from a sys admin, project management expertise, server space, a commitment to host the project in the long term … I just didn’t have the authority to make all these pieces fall into place, and neither do most individual librarians. In fact, very few individuals within a library have the ability to bring all these parts together. If a librarian has assembled these resources for you, he or she has probably (unbeknownst to you) gone from desk to desk, pleading for time from each of the people involved. That’s also probably why it’s taken so long to get your project off the ground. You can imagine why most librarians aren’t eager to do this over and over again.
Lack of incentive
It may not be all it should be, but for scholars, there’s some professional payoff to accomplishing a DH project: some name recognition, something to take on the conference circuit. It’s less clear what the payoff is for the librarian who has helped to shepherd the project through its development cycle. Too often, the “completion” of a DH project means more headaches down the road (about upgrades and server space and support) for the librarian, while it’s the faculty member’s name that’s associated with the project. If the librarian’s institution isn’t providing support and recognition for librarians involved with DH, it’s hard to see what would motivate someone to subject herself to such hard work.
The complexity of collaborating with faculty
If a DH project involves collaboration between faculty and librarians, it’s important to be attuned to the peculiar dynamics of this kind of relationship. Frequently, faculty approach librarians as service providers (and too often, librarians approach faculty that way, too). The flaw in this relationship becomes clear a few weeks into the collaboration, when the librarian really needs that dataset, decision, or brainstorming time in order to make progress on the project, but doesn’t feel entitled to make demands from an unresponsive professor. There’s no one to appeal to and no one who can help, and so the request languishes. The project will suffer if the relationship isn’t truly equitable.
You’re a faculty member who wants to write a book. Whose permission do you need? No one’s. The book may fail, but it may wildly succeed, and that’s a risk you can take on yourself. If, on the other hand, you’re a librarian who wants to work on a DH project, you’ll probably need to check with your supervisor, maybe the legal department, whoever’s in charge of the technical team, maybe the people in branding. And frankly, for most of these decisionmakers, the safest answer is “no.” When so many stakeholders are involved, the incentives for risktaking become so diffuse as to be almost imperceptible.
Lack of a real institutional commitment
When libraries do DH well, they’re in it for the long term. That means permanent staff, hard funding, real space to work, and an understanding that some projects will succeed and some will fail. But what we often see now is libraries hedging their bets: willing to wager a postdoc or two, but not more. Alas, this strategy often leads to more frustration than cool DH projects. DH takes time, and an investment in relationships across the campus. When that commitment isn’t there, librarians know it, and so do faculty and students.
32 Replies to “What are some challenges to doing DH in the library?”
I would agree that “lack of authority” is one of the major challenges. What we both probably recognize is that if the faculty member had to go around to various departments seeking resources to do the same project, they would find it even more challenging to pull it all together because they would be crossing all sorts of significant organizational boundaries: central IT, other departments, HR, etc.
Many libraries, as you likely know, persist with very vertical hierarchies. Nothing can happen until “checking with my supervisor” or “running it by the leadership council” or “writing up a proposal [that we will then kill with our inaction]” has transpired. Some accountability makes sense, sure; we don’t want every person in the organization creating their own reality or we could never offer reliable and consistent services. On the other hand, we (those of us in leadership positions) need to loosen the reins and accept the fact that there will be work happening in our sphere of influence about which we don’t necessarily know everything nor have any control over, except in the abstract sense. To me that sounds like a dream state, but for many admins, it’s a worst-case scenario. The core issue here is trust, which is so often lacking.
One of the compounding issues revolves around lingering class issues. Librarians (often) are relatively free agents within their organizations, able to set their own priorities and manage their own time. Not so with the bulk of the employees in the typical library, which means that the IT staff, in particular, is likely saddled with a lot of very rigid strictures which will make them less excited about open-ended requests, however interesting and engaging they may find the work. This is another issue we need to solve as the work libraries perform evolves.
Certainly authority and institutional structure have a lot to do with it. It’s hard to think “like a start up” when you can’t “act like a start up.” It seems to me that compounding the issues around time, incentive, etc are issues with learning curves. It takes a fair amount of time to tinker around with new tools and approaches. I’m not sure how much time is built into any of our jobs for this kind of “noodling.” It’s the kind of thing that a faculty member tackles on sabbatical , if at all, and perhaps there’s a training session that library staff can go to, but that isn’t the same really dedicating time to playing around enough to be able to master and manipulate a tool.
Our library uses a “skill share” model, which is conceptually fine, but describing the tools and their uses during a brown bag just ins’t the same as having the time to work with them. We all know that DH practices are so diverse that they demand a wide range of skills and/or the time to develop new skills. It’s really hard to imagine how you set up library staff to be ready to respond to a faculty member when they arrive given the breadth in the field. Given that, one would need a system with built in time sufficient to learn new tools on demand.
I wonder if this is where a collaborative or cooperative of DHers in a region might not be really helpful. Your librarian doesn’t know Voyant? That’s fine, the one down the road does and we have the structures in place to allow you to work together. Why try to get the limited and overtaxed staff at one institution to try to master everything, when you can leverage existing skills in the area?
Dale makes a good point. Further, where there’s a tendency toward regimented roles and territorial issues within the library, it’s hard to be flexible and take risks.
Libraries are extremely risk averse and DH projects definitely carry the risk of failure. Or, the risk of being a poor return on the investment of time and money.
For a library to successfully pursue DH projects, the library leadership needs to make a commitment and involve those who are interested.
Nice post, Miriam. I think you and the responders nailed the issues. The “too many tasks, too little time” point definitely resonates, especially with budget cuts and increased user expectation for online collection gratification and access. As a side note I would add that, from my perspective, librarians and archivists are doing DH in the libraries. They may not always be splashy and steeped in pomo, but they are what I would consider to be core DH: metadata development, digital preservation/access, finding aid construction, digital capacity building in the community. I know that DH is an amorphous term, but maybe not amorphous enough to include these kinds of activities? That said, I think academic libraries do need ramp up efforts to get on board with faculty+librarian driven DH projects of all kinds, if they want to be relevant down the road.
John asks a good question, namely, is the term DH inclusive enough that some of the work happening in libraries can fall under its umbrella, e.g.- digital preservation, finding aids, etc. I’m not sure it is. Those activities are important, but for me they remain essential library work, and can’t be rebranded as DH to ally them with the broader field. That said, they exist very close to DH, and create many of the necessary preconditions that DH needs, but what I don’t see with the library work is the creative or exploratory elements.
This question strays a bit from Miriam’s original intent with this post, but to bring them back into harmony, I might suggest that one of the challenges to doing DH in the library is simply defining the scope and purpose of DH.
Definitely food for thought, there are several very accurate statements in my opinion, but also several flaws in logic. I looked at your CV and wanted to ask when and where were you a librarian? For instance, many librarians (perhaps not at your institutions) are tenure-track faculty, therefore the “lack of incentive” statement does not ring true to me.
Thanks, Elizabeth! You’re right, of course, some librarians are tenured. But many (more and more!) aren’t. I think the problem I really meant to point to here is that it’s so hard to divide up credit for a digital project in a fair and useful way. Too often, it’s the scholar’s name that’s associated with a project and no one else’s.
The other issue you’ve raised is that I’m a non-librarian writing about library stuff, which is a criticism I definitely understand. Librarianship seems to be one of those professions, like teaching, that inexperienced people think they understand better than those who’ve actually done it. Still, while I do not now and have never held the title “librarian,” I’ve done digital humanities in a library, with other library people, as an employee of a library. As you of course know, libraries employ many different kinds of professionals, not just librarians — developers, administrators, publishing professionals, technologists, and people like me, who fall into the category “whatever.” I have all these people in mind as much as officially designated librarians — so perhaps where I write “librarian” above I should write “library professional.”
One of the reasons I felt comfortable agreeing to write this article (despite my non-librarian status) was that I knew I’d post drafts on my blog and solicit corrections from my friends in the library community. You’ve offered me a suggestion that will improve my piece, and I thank you for it!
Please forgive me. I completely thought your blog stated in it somewhere that you had been a librarian. By no means was a making a smart-ass comment. Honestly. I’m sorry you felt the need to defend yourself. Totally my bad (and I hate that expression). I’d be happy to discuss this with you further, if you’d care to. Again, many apologies. I was totally a mistake on my part. I truly look forward to your research as I am a strong advocate of digital humanities in academic libraries.
Dale and John — thanks so much for these helpful comments. You’re so right, librarians already do a bunch of stuff that could very well be considered DH. It strikes me that one difference between doing a scholarly DH project and doing what libraries are used to doing is that there’s no clear reason to do an officially designated DH project, administratively speaking. Metadata construction, digitization, writing finding aids, all that stuff requires scholarship and has scholarly value, but it also serves the efficient operation of the library. DH stuff … not so much. It can even hinder it! So, to me, this is the distinction that makes it hard for libraries to get behind a lot of “scholarly” DH projects.
Does that rambling reply make sense? Do you agree? Thanks, this is really helpful for me.
Oh, my goodness, Elizabeth, no reason to apologize at all! I appreciated the chance to respond to something I thought might come up. And as the daughter of a public schoolteacher, I am extremely sympathetic to that feeling of people purporting to know your job better than you do.
I’ve written some extended comments here:
When I first saw this post, I was really relieved that someone (not me!) was saying that librarians are overworked, overcautious and perhaps also held back.
But then I emailed retired Wisconsin Historical Society librarian Jim Danky to ask for his thoughts, and he replied: “If my quick reading is correct, the author is writing a serious library article about why people can’t make things happen. Really? No. Make ’em stop you and that won’t happen very often because of entropy which affects all known administrators and many others.”
And I think Jim is right–we’ve got to fight to make change, and all librarians need to hold themselves responsible for doing that, regardless of the circumstances.
But I also think that what Miriam is doing here is pointing out that academic librarians–even those who are members of their faculty–don’t have full parity with their colleagues in many cases. And I think that is important to say.
I assume that a post like this could be written about how difficult it can be to create change and allow new initiatives is a difficult process in many academic departments. But I think it is worth recognizing that those who are doing DH in libraries–and it is happening–may have had to fight a bit harder for the opportunity to do these projects and to collaborate effectively with (other) faculty, and to breach certain library/rest of the academy divide.
Thanks for your wonderful post, Miriam. It distills these issues so many of us are dealing with down very clearly.
I see “lack of authority to marshall the appropriate resources” as perhaps the easiest to tackle of this list of problems. This isn’t a problem limited to DH – at many libraries if a department wants to use tech to improve operations they’ll frequently have the same issue. My library has made some significant steps in this area, involving putting a technology resource request procedure in place. It’s work. It’s a process. You have to go through all the steps, and plan, and justify. These can be hard things to do, and they can feel like too much overhead when you JUST WANT TO DO SOMETHING RIGHT NOW. We’re seeking the right balance between process and getting things done, but what we’ve put in place so far I think has been a tremendous help. You have an idea and want resources? Here’s how you get them.
I’d also cast “lack of support for librarian conceived initiatives” a bit more broadly as well. “Supporting research” doesn’t meet a library business need – it doesn’t help our operations, but it is one of our core services for our patrons. It meets their “do my research” need. And our operations ultimately exist to be able to provide these core services. BUT… where many institutions run into trouble there is something Mike addressed in his response–we can’t do everything. We can’t buy every book/recording/map/score/journal/dataset any faculty member or student might want. We can’t do every librarian conceived initiative. We recently had a discussion at my library about subject liaisons doing full lit reviews for faculty – is this a service we want to provide? (It’s looking like the answer to this should be no, but it depends.) If we do provide it, can we sustain it? Does sustainability mean it has to be set up so that we could handle it if everyone on campus used the service? Surely not. But what *does* it mean? So I’d characterize this issue more as a frequent lack of a shared understanding about how research support services are set up in general in the library, rather than it being about having to make a business case for how a specific initiative benefits the library or a group of users.
I have one other thing that I really struggle with in that area, and it’s related to the upgrades and overcautiousness you mention. It’s how to handle the next phase beyond this one. Hopefully everything goes really swimmingly and there’s library DH support, and a librarian and a faculty member work great together and plan something out and get some funding and some library resource and produce something amazing. But then the faculty member’s research will evolve and whatever is built will need to evolve too. As a library we can’t commit to all future unknown phases now, but the conversation about this is a very very very very very hard one to have, even for the most skilled. If a phase down the road isn’t right for the library to partner on, it still is likely to feel for the faculty member like a let-down, a backing off on a commitment, no mater how good the relationship is or how clear the expectations and commitments were in the first phase. As you say, simple avoidance of the problem by not getting involved with the first phase is a common solution, though clearly not a very helpful one. Who’s doing this well out there? Who’s managing expectations in a positive way effectively?
I’d also second a theme arising in the comments that asks how libraries define DH. The field looks big and scary and it’s natural for a library to say we can’t do all of THAT! I know the DH field resists definitions, and tends towards the broad when it does try to define. But I think the most tractable strategy for libraries will be to be proactive, to say these are the DH support services we can provide now (however narrow [eg putting collections online] or broad [providing software developers for a faculty project]), and we know it’s not everything anybody wants, but here’s what we’re committing to doing and keeping going. Then add in a little experimentation wiggle room that will hopefully refine the services offered in the future. DH support in the library can’t just be “hey, here’s a cool idea and let’s figure out how to do it from scratch” in every case.
The interesting thing is that, by definition of DH, there should be no trouble doing DH in Libraries, because DH IS library work. Brett Bobley, Director of the Office of Digital Humanities, practically describes modern librarianship when he discusses his definition of the term “digital humanities.” Additionally, his terms are reflected in the American Library Association’s Core Competencies for Librarianship (I wrote about that at my DH project’s website: http://kpopkollective.com/2012/07/10/digi-who-digi-what/). While my library’s administration has accepted my role in a DH project at another campus, it will be quite a while, if ever, that we will see a dedicated space/staff/etc on my campus proper.
In my experience, my work with DH has made me more likely to look for professional development opportunities in the DH field, encouraged me to strengthen my relationships with faculty in a more organic way, and the way my DH project is set up, the incentives are both personally satisfying and professionally bolstering. I also realize that at a rural library, there is a difference in the owning of one’s time. So, being at a rural library has both positives and negatives in this arena. One of the drawbacks/challenges to DH I can mention is that often rural and small libraries are often overlooked for a myriad of reasons when it comes to movements like these. I’m working to encourage as many academic librarians as possible, especially those in smaller library environments, to locate external projects so they can bring that knowledge and leadership back to their campuses, and when the time is right, they can begin/head/lead/collaborate/create DH projects at their home institutions.
Reading through the comments, it occurs to me that there’s one challenge not on your original list, Miriam. This is going out on a limb a bit, and I beg forgiveness in advance from those who read this comment as a zero-sum statement from a library administrator where some are “in” and others are “out.”
That missing major challenge would be the lack of technical expertise in the librarian pool. There’s a major schism currently in librarianship. On the one hand, there are the proponents of what the dean of the iSchool at the U of Toronto refers to as librarians as scholar practitioners, i.e.- quasi-faculty who engage in original research and publish accordingly. I say quasi-faculty because, of course, they are part of libraries, not academic departments, and therefore their work is evaluated accordingly, with research/publication being a perhaps 20-30% factor in their evaluation and success, as opposed to being the factor for faculty.
On the other hand, there is the work that happens in libraries, which is (and this applies strongly to DH) becoming increasingly technical in nature. Alas, as this shift from an emphasis on analogue collections and services to digital services moves forward, the skillset being taught in library programs lags behind. What one typically sees now is an academic library where the librarians sit on one side of an imaginary divide, and the people they routinely refer to as “techies” and “technologists” sit on the other. The divide is harmful and should have gone away years ago.
For those who flinch at this description, I will point out that I have worked as a scholar practitioner at stages in my career, until it became clear to me that that line was a dead end, ultimately, since the growth in libraries will occur in technically-driven areas.
What happens now is that while librarians can work with faculty on DH projects, it is often as a facilitator rather than as a true collaborator because they lack the technical expertise to complement the domain knowledge that the faculty member possesses. There are of course exceptions to this statement, myriad exceptions, and the dichotomy I’ve set up here should be understood as fluid and shot through with “wait, but …” exceptions. But the overall rule holds that when it gets down to the nitty-gritty of many DH projects–coding, complex data manipulation, server infrastructure, configuration/administration of applications–too often librarians just back away and hand it over the the IT staff. Faculty figure this out, and just come directly to the IT staff because the librarian may struggle to add substantive value.
Going back to the U of Toronto iSchool dean, I was dismayed when I heard him talk about his notion of the scholar practitioner, because I was sitting next to two students in the program. Naive as I am, I sort of assumed that an iSchool would be producing the kind of graduates we desperately need in libraries. Alas, his students told me that when they enter the program, they choose between the “librarian” track and the “technologist” track (I may have the name wrong, but that’s the gist). All I could do was sigh. This is the problem.
I agree that not enough professional development opportunities are being offered to enhance the digital humanities…having worked in libraries, I have seen staff training programs on computers, customer service, presentation skills, and reader’s advisory, but not on more intellectual skills like the digital humanities. This may be why not that many people know about it.
I do believe that the lack of time thing can be changed, though. I am a library science student who would like to be a subject librarian in both psychology and music, but I also want to do digital humanities projects. I think that if it is absolutely needed, librarians can take their digital humanities projects home with them…after all, we live in a networked world of “weisure” where many people work remotely and overtime. Otherwise, digital humanities projects can just get done in the little free time librarians have.
However, you make a good point about authority and support from one’s institution. One has to know what one is doing and have the right support, or else projects are never going to get off the ground.