Last week wasn’t great. There were a lot of tech issues that required diagnosing and fixing. Sometimes the solution was to put in a ticket with the vendor, other times I read a bunch of documentation about how google scholar indexes to solve an issue with our old repository that should just be thrown into the sun.

In the middle of all this, there’s the other work I do – managing data and metadata that’s collected about research outputs. This is complex work with multiple people and systems involved. There’s also hard deadlines and time constraints, as this work forms a core of the university’s internal and external reporting functions.

Often these parts of my role sit together uneasily. One requires time, deep thinking, and relationship management and the other quick responses and problem solving skills.

I was talking to a friend about how techie librarians need their own special sort of therapy because we have a lot going on. It requires a level of agility to switch from one task to the other quickly and you always have to be “on” because tech problems don’t happen when it’s convenient. It can be draining.

There is apparently a term for this called context switching. All jobs suffer from context switching – you’re focussed on a task and then you get a ping from a chat message and you lose focus on the task and then find hard to get back to it. Being the systems support person means context switching is an everyday occurrence that can’t be avoided but it also means you’re exhausted and feel like you never get anything done.

An added complexity for me is that I’m not an IT professional or as Lissertations wrote in this piece, “[I’m] too library for the tech staff, too techy for the library”. While coming at things from a different perspective is sometimes a big plus, it also means I don’t have the background knowledge on how a system works. This means I need ask a lot of questions, read documentation, make wrong assumptions before I understand or can fix it.

This can be quite daunting in a world of tech bros who can sometimes be, well, rude. I’m fortunate that the people I work closely with are not but in dealings with the wider IT community sometimes their responses clearly scream “female who doesn’t know what she’s doing”. In such an environment it’s hard to not feel intimidated or embarrassed.

My role wasn’t always as tech focussed as it is now. Last year someone who’s role was front and backend systems administration took a VR and as the person who knows more than others I’ve had to pick up a lot of their work. And while it’s been largely rewarding – I mean I learnt how to use an api – it’s also highlighted how little libraries understand the complexities of technology and how much of this work is under resourced and undervalued.

The recent repository replacement project I was involved with had a core team of three. There was only one person with specialised tech skills, who left before the end of the project. It was also sold to us as connect system A to system B. Never mind that crosswalking took four months with multiple rounds of testing and that the test plans were just made up as we went because only when we got into it did we actually understand all the complexities.

Compare this to another tech project I was involved with on a much smaller scale but run outside the library. This project included scrum masters, business analysts, project coordinators, specialised developers and people’s who’s job it was to create and undertake the testing. I mean it was probably way too many people but that was what was considered necessary.

In my 10 years in libraries there’s been a definite move toward vendor supplied solutions for most library systems. And while there’s nothing inherently wrong with that, it’s given libraries the false belief that systems just run themselves. It’s hidden the complexities of technology and the work of keeping them running.

Systems work is the back of house, under the radar, it leads to good user experiences but it’s not glamorous. No funder is going to open their wallet (or not cut a budget) because I fixed a problem or because someone worked out how to use preferred names in the catalogue. User experience is all well and good but it’s not exactly making headlines (unless you are a systems person and honestly what I’d give for a good user experience in a library catalogue).

Under the circumstances, it’s no wonder libraries are addicted to the bright and shiny things that get them good publicity and make them popular with funders. But what is often forgotten is that for libraries to do the showy things they need good systems and librarians who can make that happen.

More often than not, tech focussed librarians are not invited to have input until the decision is already made. This leaves out important voices that have knowledge and experience, and who understand the long term implications of these decisions.

Libraries need to do better than this. Systems drive libraries and they need to be a focus rather than an afterthought. And systems librarians need to be at the heart of the library knowing their contribution is valued and their voices are heard.