A few years ago, I began mentioning to colleagues a tension I felt in my work which I described as a tension between projects and services. No-one I brought it up with ever really seemed to understand what I was getting at, and so I tried articulating things differently or expanding on what I meant, but I still never really gained any traction. What I thought the problem was that systems work involves both its own projects (designing and building a website or discovery system, for example) as well as support services (writing code or reports for staff, acquiring, configuring, and maintaining hardware, infrastructure, responding to staff requests, updating hours, etc). The issue, I felt, was that we didn’t really have good processes, procedures, guidelines, or priorities to help with managing these two kinds of work. Projects and support services are very different kinds of work, and without solid guidelines, responding to staff support requests tend to trump project work, which requires dedicated time and energy, but tend to have longer timelines and perhaps less tangible outcomes at certain moments of the project lifespan. Staff support requests tend to be more discrete, urgent, and concrete, in that there is a staff member waiting for the request to be fulfilled. Staff support requests are, compared to project work, low-hanging fruit. My frustration was with not having clear guidelines on how to manage the work (and the expectations) around these two kinds of activity.

But more recently I’ve had a minor epiphany. The reason colleagues didn’t seem to share my concern around what I saw as an unacknowledged tension in the work that we do is, quite simply, because that tension is not present in their work. The vast majority of the work my systems unit does is in support of staff work and initiatives. I may be the only one in the unit whose work includes both direct user-facing projects and staff support requests. There are internal IT projects, of course, but these are always part of the support function, not systems-initiated projects with an unmediated user-focus. Even in website design and implementation, for example, which seems like it would be the equivalent to a user-facing project in other units, staff voices are privileged: they are closer, louder, and have access to privileged channels of communication like an internal help-desk. Our website design and implementation is governed by a staff committee. As much as we try to be user-focused and user-centred, staff concerns and desires drown out student and faculty voices. This is why talking about UX from the perspective of a systems librarian is so different from talking about it from the perspective of someone in, say, a digital scholarship or RDM or scholcomm role.

But what’s the problem? Isn’t this just the nature of library systems? Perhaps it is - perhaps during my ten years as a systems librarian, I’ve been naive. Certainly my library school experience didn’t prepare me at all for what actual library systems work was going to be. But I think until very recently I nurtured an idea that library systems work had a user-focus and an intellectual content akin to other library units: cataloguing and metadata, or public service, or - and this might be the best example - something like GIS librarianship. I envisaged my particular skills - an intersection of librarianship training, technical knowledge, and critical thinking - as positioning me for a particular positive and constructive role in the lives of students, researchers, and faculty. But after ten years I realize that systems work - at least in my experience - really just needs someone with the technical capacity to support the work of other librarians and staff units (or to supervise those who do). This is not to denigrate that kind of systems work, but it’s not what I signed up for. And I have to admit I’m envious of other librarians who are putting their intellectual command of a particular field of librarianship - again, I think of GIS - to work with students, researchers, and faculties as an equal participant, as a teacher, or to do their own research in support of the intellectual goals of their own area of librarianship.

I recently applied for a secondment to be a branch head in our library system. When the AUL in charge let me know that I had not been successful, she admitted surprise that I had the experience and skills to branch out from systems work. Perhaps this is another area of frustration borne out of the position of library systems as (primarily) a staff support service: being seen as a technician or IT-geek, rather than as a librarian, with the same concerns, perspectives, and experience as other librarians.