 Good afternoon or whatever time you're attending. My name is Ruth Kitchen-Tillman. I'm the Sally W. Kalin Librarian for Technological Innovations at Penn State and lead our projects around discovery and the new catalog. My presentation today builds from my own experience here and as a repository librarian, from research I've conducted, and from the emerging field of maintenance studies. I have also written about these findings for an article to be published in college and research libraries in January 2023, which is currently available as a pre-print in Penn State's institutional repository, Scholarsphere. To begin, what makes maintenance worth researching? If you're seeing reports from your library's digital teams, you already know that they're doing a lot of maintenance. Upgrading servers, patching Drupal, necessary work but not the stuff that's likely to get us excited. I think that there are a lot of reasons to study maintenance and I'm going to list a few key ones here. Maintenance is understudied in comparison to the role it plays in our day-to-day work. When I asked ILS and LSP maintainers to estimate how much of their work week is spent on maintenance related tasks, their numbers ranged from 40 to 60 percent depending on how strictly we were defining maintenance. But our research, surveys, and case studies focus almost exclusively on migration or implementation of new systems or on development projects. While we assume that we know what goes into maintenance, my research suggests that its low visibility negatively impacts both the institutions and the individuals who perform it. Moreover, maintenance is key to getting a return on the significant financial investment we're putting into these systems. In a time of budget rescissions, we're still paying hundreds of thousands of dollars for the systems on which our libraries rely. We're paying far more for collections. If we don't also invest the time in making sure the systems are properly implemented, integrated with other services, and then maintained, it'll put up barriers between our patrons and the use of those collections as well as slow down our colleagues in the efficient completion of their own work. As the pandemic fires and floods that we've been experiencing throughout the last decade or more now are teaching us, libraries need to adapt quickly to support their community bases through a crisis. If our systems aren't well maintained, we'll be on poor footing to respond. Understanding, prioritizing and budgeting appropriate time and money for maintenance work is important to the morale of both the workers doing the maintenance and the workers using the end products. We're good at rewarding innovation and celebrating new implementations, but we're much less likely to recognize the work that goes into keeping that new product running for another five to 20 years. This means that structurally, some colleagues will be recognized over and over again, and others will feel that their work is ignored, even if that work is equally critical to the institution. Lack of maintenance also affects the morale of all workers using a system. It interrupts their flow, it forces them to find work arounds, and it leads to negative interactions with patrons when a system is not behaving as expected. Before sharing my research, I want to spend a little time on how I define maintenance in this context. Given the proliferation of library systems and integrations, I think the Information Maintainers expansion of Russell and Vincil's 2016 definition of maintenance as acts that sustain and repair people and things to include the interfaces we designed to function between and among information systems is particularly appropriate here. I'm going to make it a little more concrete by naming some of these acts, including performing regular system upgrades, updating system settings, addressing bugs and breakdowns, upkeep of integrations with other institutional systems, and the minor tasks to turn on a new feature, improve user experience or support existing functions. The latter type of work spans maintenance and innovation, but when it consists of bringing existing systems into alignment with expectations and work already being performed, it aligns more closely with the other areas of maintenance included here. And while defining maintenance, I think it's important to clarify, maintenance is not inherently good. Sometimes people maintain oppressive systems, harmful technologies or just unused projects, or we commit to maintaining more than we have capacity for, as Brent Davidson and Jason Rinalo discussed in their CNI 2018 presentation on Sunsetting. But it's only once we examine maintenance as a meaningful and valuable part of library work that we can also identify the things that we shouldn't be maintaining. Most of the research that has been done related to library systems maintenance has been survey-based and focused on developing a concrete list of tasks. Generally, these are intended to improve education or hiring practices or on understanding a single aspect of the work. I oriented my research toward identifying shared themes in the experience of performing systems maintenance over years or decades and the implications for practice. I lay out my methods in the paper, which I'll share at the end of my presentation. One area of recruitment, which I will mention here, however, was ensuring that at least two interviewees supported each of Olif, Alma, Sierra, Symphony and Voyager. Several participants who had migrated to Alma in the last few years could also speak to maintaining multiple systems. I iteratively coded the interview transcripts in InVivo and identified five interrelated themes. Unpredictability of the workload, invisibility of time worked, the importance of collaboration and communication, and the affective impact of visibility and capacity. While I spell these out in greater depth in my article, for today's talk I'm going to focus on. Unpredictability of the workload, invisibility of time worked, and the affective impact of visibility and capacity, and then folding elements of the two other themes. Systems maintenance tends to consist of an unpredictable mix of the following elements, planning maintenance, performing plan maintenance, and fixing things when they break down. Well, certain kinds of maintenance such as upgrading a system or implementing a quarterly release can be planned ahead of time that does not inherently make them unpredictable. For example, Alma maintainers knew a quarterly release was coming, but they don't know what's in it, whether it would affect library processes and integrations, whether it requires stakeholders to perform testing or choose how it would be implemented, and the like until they have time to read the release notes. As with planning, the amount of time spent performing plan maintenance varies widely based on the kind of work needed. And as I recently experienced with one of our own integrations, if something isn't documented in the release notes, your expectations may turn out to be completely off base. Moreover, each integration modification or enhancement becomes another area that requires monitoring maintenance and may break without notice. These build up over the lifetime of a system as the library adds new services supports new workflows and the like. And because a maintainers primary job is to keep the system working, malfunctions take priority over the kind of long term enhancements, which provide the most visible evidence of one's productivity. These may range from something as simple as restarting a service, which is just enough interruption to break focused work to dropping everything and spending a week ensuring the high risk headline making log for J vulnerability has been fixed across the library systems. If this unpredictability is not understood and a incorporated into expectations for the position alongside more visible work, providing responsive support to patrons and colleagues or just keeping the system from falling apart will lower a person's perceived productivity. When successful systems maintenance is rarely visible to those outside the library's technical departments. This invisibility can lead to an expectation that those performing it will be available to take on new projects. The participant quoted here notes that the team that they're on spent about 60% of their time maintaining and supporting the many integrations and the ILS itself. Another said that it's hard to convey the amount of work it takes to keep the lights on, which is often made up of a series of tasks that seem insignificant in themselves. If this work is not accounted for when new initiatives arise and require their support, maintainers find themselves choosing between delaying the completion of a new project or leaving users in the lurch. Participants also noted that non technical elements of their work may not be visible in the way that technical work can be. For example, estimates on time spent on communications work range from 10 to 25 percent of a workday work week, including everything from troubleshooting an issue through emails and service tickets to big meetings, planning maintenance or fostering the trust necessary to perform bigger maintenance tasks. One participant explained that they frequently take walks as a way of stepping away from the screen and thinking through a problem that they are trying to solve, but worry that this might not be perceived as doing the work in the same way that sitting in front of a screen might. The invisibility of maintenance work also leads to incidents which are morale. Two respondents mentioned that their institutions recently honored and praised highly visible front end developers for completing projects, even when they had been an equal or primary contributor. As one said, nobody mentioned me. Nobody mentioned the months that I had spent working on this and my direct supervisor still does not recognize that that work had to be done first. No one ever knows that my work comes first and then the guy who worked on the website gets to do the cool thing that everybody can see. This leads to a thread which wove through the interviews, the demoralizing effect of invisibility when things go well, of hypervisibility when things go badly, and of not having capacity to do the job to one's own standards. Half of participants reported that they regularly worked more than 40 hours a week, and all participants said that they are unable to do some maintenance that would make the system function better for others, because it's not actually broken and they don't have time. Well, capacity was partly determined by one's workload. It was also impacted by work being done outside the library. Sometimes university IT, but more often vendors. When the system is not working properly, but not so broken that the vendor responds immediately, it may be three months or more for a fix to be released. But a Scarlett Galvin said in her 2018 Vala keynote, and yet when there's an outage or we can't provide a resource, it's the library's problem, not the vendors. As one participant shared, delays in vendor response really impacts our unit's reputation within the library, but also the library's reputation within the university. While some things like development timelines or another log for J crisis are mostly outside our control, we can develop a strategic approach to maintenance, which provides better service to our communities and mitigate some of the stressors our colleagues experience. First, make the invisible visible. Document what you're actually maintaining, not just the systems, but the interoperability between them and what they've required in the past. Does your Iliad connect to your LSP with custom code? Does your library account management tool use a web service that sometimes times out for no known reason? Which systems or integrations or particular pain points that fail more often or take longer to handle when they do go down? Get the details as well as the big picture. Next, find out what you're not maintaining or more likely not maintaining as well as you could be. What would your systems team do if they had more time or another position? Collect it all from the barely contained disasters to the well, we could really serve X community better if only we had time to fix implement or update why. Then identify what you're going to maintain. Is it a core service? Are you paying NDA sums for the software? But it's only running half as well as it could be because your workers haven't had the capacity to fully implement and maintain it. You're already doing less, but you are not being strategic about it. Include maintenance work in your strategic planning. Be clear which innovative projects are purely experimental and which you're committed to maintain. Make sure you have a plan for their maintenance as well as their development. Commit to the systems and services that you can maintain well, not everything you can do if you burn out all your workers. In his 2021 article in library leadership and management, a good job strategy for libraries, Trevor Owens called for library leaders to reconsider the do more with less approaches that have been burning out workers and take the bold step of consolidating services while not cutting jobs. This is essentially the same recommendation that David's in a renala made in their 2018 CNI talk on sun setting. Both also point to work on the benefits to an institution when workers have slack in their schedules. When every minute is engaged and the backlog is full of smoldering fires, workers have much less capacity to think about how to do the work better or come up with innovations, or even if they can think of it, they don't have the time to follow through. Of course, you don't necessarily have to do less. You just have to commit to funding maintenance work with more slack than your workers probably have at present. That could mean adding positions. Two participants described the process by which their institutions realized that they could get a lot more value out of their Alma implementations if they hired another person to support it. By documenting what was possible but couldn't be done given their current staffing levels, their managers developed job descriptions which they successfully justified to the library's administration. This not only benefited and pleasantly surprised the rest of the library, it benefited the workers doing the maintenance. Not only were they able to focus more on tasks while knowing other work was getting done, the tangible recognition that their work has value to the library lifts the morale of those doing it. And on that note, something that everyone in libraries can do is make sure that maintenance work is rewarded alongside innovative and creative work. When celebrating an achievement, give appropriate credit to those who did the behind the scenes work or maintain the underlying system as well as those who did the most visible parts. Such an acknowledgement is one step toward balancing out the tendency for maintainers to be most visible when something breaks. If you know that you're not entirely familiar with the work of some of your coworkers, this may mean asking a department if you're missing anyone before putting in a kudos or nominating a group for an award. And don't just celebrate the innovative achievements that benefit the patrons. Did someone make it a little easier for another team to do their jobs or fix a broken system that was making your life harder? Thank them and acknowledge it in whatever way is appropriate in your library. When we neglect maintenance work, we risk degrading our core services, our reputations and our institutional morale. What's up to library leaders is to decide whether our libraries will offer more things and do all of them less well or pass on some exciting opportunities, but come in strong behind what we offer. Thank you. I'll be sharing these slides, including my speaking notes and this further reading list through CNI and on my personal website RuthTillman.com. My article, which goes into greater depth on the research, is forthcoming from college and research libraries, but a green OA copy is currently available on Penn State's institutional repository ScholarSphere. The research was conducted with approval of the Penn State IRB. If you have comments or questions, I'd be happy to hear from you at the email address on the slide. You can also find my own work, including some less formal writings, at my personal website RuthTillman.com. And finally, these are the credits for the slide templates and the two images used in the presentation.