The Interdependent Library System: Revisiting Human Aspects of Library Automation

If you will be participating in one of my research interviews: please consider not reading this until our interview has completed. If you then notice things you wish you’d said, feel free to contact me to follow up!

Good afternoon, everyone. My name is Ruth Kitchin Tillman and I’m delighted to be speaking here today. I’ve been going to libraries since a few weeks after I was born and worked in them since I was 16. For the last 7 years, I’ve been the Cataloging Systems and Linked Data Strategist at Penn State Libraries.

I’m part of what I call our “systems octopus,” the many people who make Sirsi Symphony and adjacent systems work well for our patrons and our coworkers. My primary responsibilities are managing our Blacklight catalog and our Summon discovery service, but I also do batch record updating and some system configuration nuts and bolts or troubleshooting, particularly for Tech Services, where I’m located.

Continuing the animal metaphors, you can find me on mastodon as platypus@glammr.us. I picked the handle to reflect how my career looks a bit stitched together, but I’m quite real, not fictional like a unicorn. I did not anticipate ever having to say it in front of an Australian audience.

I’m also a quilter, a ham radio operator, a mastodon instance moderator, the partner of a high school teacher, the daughter of a linguist and a programmer, and the caretaker of a small pollinator garden and a small pitbull who’s got big anxiety.

I want to acknowledge today that we are on the unceded lands of the Wurundjeri people of the Kulin nation. I would also like to acknowledge where I live and work. I work at the Penn State Libraries, one library geographically dispersed across the US state of Pennsylvania, which is a little over half the size of Victoria. Our university is located on the traditional lands of the Erie, Haudenosaunee, Monongahela, Shawnee, Susquehannock, Wahzhazhe, and Lenape Nations. I grew up on Lenape land within that little dip just below the lower right side of the state’s borders.

Penn State is a land grant institution, funded through the Morrill Act of 1862. This means that our endowment was created through the sale of three quarters of a million acres of the lands of more than 100 other nations, tribes, and bands to our west. These ancestral lands are all outside of Pennsylvania, stretching from the Missouri River to the Pacific Ocean. I would like to pay my respects to the elders of these many peoples, past, present, and emerging.

The Interdependent Library System

My talk today concerns a system that most of us have encountered at some point in our careers. Whether we call it an Integrated Library System or a Library Management System or a Library Services Platform, it’s the system through which workers perform many of the recurring processes and functions necessary to run a library day-to-day. It was one of the initial concerns of this organization, which formed in part to support the implementation of these systems in libraries–known as “library automation.”

I’m currently in the middle of a research project listening to people from institutions across the US and a few outside it talk about the short and long-term impacts of library systems migration on their work and their morale. I’ve been reading through more than 350 responses from a spring survey and am conducting follow-up interviews with those who wanted to talk at greater length about it. By hearing from those who work across functions, systems, and libraries, I hope to learn the shared characteristics of common challenges and how we might mitigate them, as well as what it looks like when things go well and how much of any that is under our control. 

Today, I’m going to bring some of the things I’ve learned in my last 5 years of reading the early literature of automation and the broader literature of technology, conducting interviews with system developers, system maintainers, and the staff who use these systems, including very preliminary findings from my current project.

I’ll be drawing in particular on the work of Ursula Franklin, Sara Fine, and Marianne Bellotti. So let me take a moment to introduce them.

Ursula Franklin taught at the University of Toronto for more than 4 decades. She was a metallurgist, a Quaker “peace activist,” a “first woman” in many parts of her university–so many things that it’s difficult to describe her briefly. What’s particularly influenced me today and for the last seven years since I first listened to them is her 1989 Massey lecture series, “The Real World of Technology” (Internet Archive copy, CBC copy).

Fine was a psychologist, librarian, and library school educator who wrote from the late 1970s to mid-1990s about the psychological impacts of automation in libraries. She challenged simplistic narratives about resistance to change in the workplace and wrote empathetically about the workers impacted by these seismic shifts.

And finally, Bellotti’s 2021 book Kill It With Fire focuses on the maintenance of legacy systems and the challenges of modernization. Although the systems she describes are primarily homegrown, not proprietary, her work includes solid assessments of the mistaken assumptions technologists often make about our users as well as our technologies when we modernize or replace a product.

I’ll also address the plethora of acronyms from which one can choose when talking about this kind of system. As a rule, the older ones are called Integrated Library Systems, the ILS, whereas systems that incorporate things like e-resource management tend to call themselves Library Services Platforms (LSPs). You may have also heard Library Management System (LMS). That was pretty big until recently but caused acronym collisions at places which also had a “Learning Management System,” things like Moodle, Canvas, or Blackboard.

I understand the desire for disambiguation, but they’ve really just integrated in more things. In the interest of simplicity and because we use Sirsi Symphony at Penn State, I’ll be calling it an ILS unless I want to disambiguate generationally, in which case I’ll reference LSPs.

While the direct relevance of my talk to your work may vary depending on where you engage with technology in libraries—I hope that by the time I’ve finished you’ll have encountered a few ideas, mine or others’, which will be useful or meaningful.

Human Aspects of Library Automation

Library systems are made of people

The ILS may now be the LSP, and the thirty-plus that were on the market in 1985¹ may be less than a dozen now, but what’s stayed the same from the earliest days of library automation to the present is that the work has never been automated-away, even as it’s been computerized and brought online. It is still all managed, maintained, and performed by people. 

I became interested in talking to people about their own experiences working in the ILS, particularly around migration, while researching the history of Penn State’s LIAS project. LIAS, the Library Information Access System, was our homegrown ILS, database server, and even email platform. We started building it in the 1970s, attempted to sell through the mid-80s, then maintained and continued to update it for another decade. We migrated off it around 1999, 25 years ago. So when I arrived in late 2017, we’d been off LIAS for 18 years.

Yet when I met with colleagues across the Libraries to discuss their needs for the new public Catalog we were developing with Blacklight, I was surprised by how much LIAS came up. I’d become aware of it by then, both as a point of local pride and a system whose eccentricities were still inscribed on our catalog data. My colleagues’ memories spurred me to start an oral history project, collecting stories from the people who built LIAS or who worked with it in its earlier days. As someone who had experienced the ups and downs of maintaining open source software and homegrown systems, I was interested in what that work looked like forty years before, the similarities and differences of the challenges. And I just love to hear people talk about how they made something work.

I complemented this with archival research and by reading the literature of the time, including conference publications from VALA! What struck me about papers from the era of automation was that they included a focus on affective impacts of the initial adoption of library systems along with other “human aspects of library automation.”

In fact, “human aspects of library automation” was such a big topic that there were two completely different books with that title. The first is a collection of papers from the 22nd Clinic on Library Applications of Data Processing, held in 1985 at the University of Illinois at Urbana-Champaign with the subtitle “helping staff and patrons cope” and the second is more of a manual, first edition published in 1990, covering subjects from ergonomics to environmental and cognitive or emotional stress.

Some of it is kind of a trip to the modern reader:

From which I couldn’t help but think:

But, jokes aside, my own two-monitor setup, sit-stand desk, and reasonably comfortable office chair owe a lot to this concern for physical ergonomics during the period of workplace automation. I also saw a level of concern for the feelings of people working in these systems that surprised me. There was plenty written in the dismissive tone that I expected, putting down those for whom change is a struggle–whether because of their age, their predisposition to thrive on structure, or other factors. But I also found empathy. I found concern.  At this point, I’d already started conducting research into systems beyond my oral history. In 2020, I interviewed library system maintainers at a small group of US universities, people who managed a fairly representative sample of systems in use at the time. Migration and change management came up along with broader topics, such as morale, visibility, and collaboration. For my sabbatical, I decided to try asking and answering: what do 21st century ILS migrations look like across the field? How do they impact people in the short and long-term?

The project’s evolved along the way, to include survey and interview components. I’ve been reading through more than 350 responses from a spring survey. I’ve conducted 19 interviews so far, some preliminaries in the fall and others as follow-ups with survey respondents who wanted to talk at greater length about what they’d said. By listening to people who work across functions, systems, and libraries, I hope to identify the most frequent roadblocks to adaptation and how we might mitigate them, practices that help worker morale bounce back faster, and how much of any that is under our control.

I’ve been very pleased that despite self-selecting into these surveys and interviews, I’m hearing from people with a wide variety of morale impacts. For example, ⅔ of survey respondents who answered the question about how their morale compared to pre-migration answered that either it was better for reasons relating to the migration, it was about the same, or that it was worse for reasons other than that of the migration. I won’t have percentages on the research interviews until I’ve completed them, but folks I’ve talked to have been all over the board–some delighted by their new workflows from day one, or at least day 90, others having a rough start but balancing out, and some very demoralized.

I’m going to start by pulling back from the ILS to talk about the broader technology we work within, the Technology of Library.

The Technology of “Library”

Technologies, as Ursula Franklin use the word in her lectures, are more than computer systems or mechanized tools such as cars or sewing machines. They are practices, mindsets, ways of shaping life and work. I want to think a little about the Library as a kind of technology. I am so glad that I am following Tui and Hero. Since I wrote this before their talk was announced, I didn’t realize that they’d be covering some of this as well. They went into far more depth than I will and I hope you’ll get more out of what I’m saying for having heard them this morning.²

Not all technologies of practice are the same. Franklin disambiguates between:

• holistic technologies,
• prescriptive technologies,
• and technologies of control,

although the latter two are often intertwined and she sees them in opposition to the first.

One classic example of holistic technology is individual garment work. When I make a jumpsuit, like the green one I was wearing yesterday, it takes me a few days to cut out the fabric correctly, sew all the pieces together, finish the seams, etc. I use both a sewing machine and a serger, I stop and press pieces, and when I’m done I have a finished garment.

What I’m wearing today was created in a prescriptive environment. Industrial garment construction is broken down into steps and each step completed by a different person, mostly women, until a finished garment is produced. When you are only sewing one seam, over and over, you can do it much faster than if you have to consult instructions, ensure the piece isn’t going upside down or backward, switch machines, etc. We think of this as a product of modern industrialization, but Franklin studied ancient metallurgy techniques and assures us there’s nothing particularly new about this arrangement.

It was also certainly created under structures of control meant to extract the most monetary value from the underpayment of workers and the costs of equipment.

There are also technologies of community and practice. Initial technologies of quiltmaking, for example, tended to involve one person piecing the quilt top and an entire group assembling or the quilting. As someone who hand-quilts alone, I can see the advantage in getting the work done in one big day. It’s also social, a chance to catch up with your neighbors or family.

With the introduction of long-arm machines, which are very large and expensive, a variety of new approaches have emerged. Some people or independent stores rent time on their longarmers as a way to recoup costs. Others pay for their machine by starting a side business quilting tops. This creates new relationships between piecer and longarmer and between longarmer and vendor. It also changes expectations in some communities about how the work is done and how many quilts a person might produce in a time period. There not organized by a professional practice or controlling entity, and yet they repeat across the US and in Australia, where I know there’s a thriving quilting community.

Libraries are generally structured as technologies of control. We have standardized methods for describing and organizing our materials, we have methods for determining who is and isn’t allowed to borrow materials, we all have due dates and often fines, we even use terms like “authority control.” When you move between libraries, you’ll have to learn local implementation specifics, but once you understand the technology of “Library,” it’s a bit like moving between Microsoft Word, Libre Office, and Google Docs. You’ve got the overall concept and you’ve moved on to learning all the little ways they’re different.

The ILS exists within these technologies of structure and control. It is a kind of prescriptive technology. Its reflection of the Technology of Library means it can be used at multiple institutions and even across different sectors. For example, I’ve used Sirsi Symphony at NASA and at Penn State; it’s also what my hometown library migrated to after I left. The choice of ILS can have a significant influence on the library’s structure. But then there’s always been a relationship between how we implement the Technology of Library and the smaller technologies we use to do so.

Back in the day, catalog cards were written in a thing called Library hand, both the cards and the handwriting a kind of technology.

When libraries moved to using typewriters, many workplaces structured their departments so that catalogers created the intellectual data and skilled typists turned it into cards. When our library implemented its first ILS, our cataloging department was made up of catalogers and typists.

The catalogers had to learn how to use shared terminals and type their own records, even if they still wrote them by hand. And the typists had to find new work, whether elsewhere in the library or outside of it. The systems we choose can also shape how we structure a library. If our new system is SaaS, a sysadmin’s relationship to both the vendor and library may change. We may restructure technical services so our work flows better in the new system. Or one director, after implementing Worldshare Metadata Services, decided to disperse the cataloging department into other roles in the library.

Recognizing that Library is a kind of technology, that it’s designed and structured, reminds us that it can be restructured. We have critical cataloging or alternative classification systems or we eliminate fines and expand access. But, as Tui and Hero also acknowledged, even as we’re thinking about what we can be, we’re also very much operating in the here and now, managing or acquiring material and making sure it gets into patrons’ hands, and we are doing so through, in large part, the ILS.

So now that we understand the ILS as a prescriptive technology, one that’s thoroughly intertwined with how we implement Library at any given institution, I want to talk about migration.

Migrations: Smooth to Scarring

Most libraries switch ILSes rarely, on the scale of decades or even generations. At Penn State, we’ve only had two ILSes in the forty-five years since we automated. We spent twenty on our homegrown system and twenty-five on Sirsi Unicorn, now Symphony. We’ve changed a lot of ways in those decades. We’ve expanded access from card catalogs on site to terminals on site to computers in your home or office to computers in your pocket. We’ve built annexes, shifted our collections policy to focus on more licensed electronic materials, stitched together a lot of systems to make things work, and tried to streamline the patrons’ experience where possible. 

Change happens all the time in a workplace, plenty of which is self-initiated and self-organized by the workers. Coworkers come and go, requiring re-evaluations of process and training. New people ask new questions or develop new workflows. Folks move between positions and use knowledge of their previous role to streamline a process. Those who are more outward-facing encounter ideas on listservs or social media or at conferences like this which they bring home to adopt and adapt. We face challenges and come up with solutions together.

But a change on the level of a system migration is different. Sometimes it’s initiated by a new director who’s certainly found a way to leave their mark on the library. Sometimes it’s forced on you by the age of the system or the vendor’s willingness to support it. For example, Voyager’s about thirty years old and, according to Marshall Breeding’s excellent librarytechnology.org database, it’s down to fewer than 150 installations. After Clarivate/Ex Libris bought III, they indicated that they didn’t plan to support Sierra forever and started trying to shepherd people to Alma. I’m actually impressed by how poorly they managed that one, quite a few have jumped ship to FOLIO instead. 

A change doesn’t have to be self-initiated to have appealing qualities–such as going from needing an ILS client installed on your computer to being able to work in the browser. Or perhaps a new system allows you to flow between modules, so you no longer have to open a bunch of different wizards to do different things to the same Thing, then remember to close them all before exiting or get that little popup…

…you Symphony/Workflows folks know what I mean.

Sometimes, the nature of integration has changed. For example, at Penn State, we handle electronic holdings management and interlibrary loan in separate systems from the rest of the ILS. We handle physical course reserves in Symphony and e-reserves through SpringShare. It mostly works, except the reserves part, but if we moved to Alma tomorrow, we could have all of that in one place, more or less integrated.

ILS migrations are shifts between prescriptive systems

But even when elements of a change are positive, ILS migrations are always shifts between the prescriptive expectations of each system and their capabilities, all of which are a little different. They are not self-motivated or optional. You cannot keep working in Sierra when the rest of your institution migrates to Alma or FOLIO. 

The change will fundamentally disrupt people’s practices, at least in the short-term, temporarily increase the friction of simple tasks, and lead some to question whether the trade-offs were worthwhile or protest that they have lost the ability to perform certain tasks, or perform them as easily. Negative experiences are byproducts of design choices, some poorly-made and some necessary, and the failures of care in their implementation in a workplace.

In describing expectations around upgrading wildly-outdated systems, Bellotti writes:

We assume [people] will all magically reconfigure themselves around the right technical answer because it’s the right technical answer. We are horrified to discover that most people do not actually care how healthy a piece of technology is as long as it performs the function they need it to with a reasonable degree of accuracy in a timeframe that doesn’t exhaust their patience. In technology ‘good enough’ reigns supreme. - Kill It With Fire xvii-xviii

In my hat as a technologist who works with both vended and open source systems, I can understand the frustration when this happens. I know the feeling of letdown when people dislike a thing you made, despite your best intentions to make it work for them. I also know what it’s like when you have no more say in implementing a change than do the people who are complaining to you. It can be very easy to point to the ways the system is better or more flexible or how it adheres to modern standards based on decades of research and doesn’t look like it was made in the early 90s. We may point to the British Library and explain that it’s critical we update for our security.

Those of us in libraries know to expect this resistance. But I also see a tendency for these people and their complaints to be written off, particularly if they are staff, older librarians, or librarians in technical services areas. This is even more the case when it’s still possible to perform most or all of the work they’re concerned about, just using a different process. This is how the new system works! You can still do it! Just learn to do it the new way! People who don’t embrace it are treated as unreasonable or incompetent. Yet in Bellotti’s assessment “People are often too quick to equate morale issues with character flaws.” There can also be stressors like cognitive overload, which is not the same as an inability to learn, as Hannah Armitage noted in her talk yesterday.

While we tend to acknowledge that they’re massive disruptions to workplaces, often causing drops in morale and a wave or two of retirements, modern articles on the subject of migration rarely take on the ways they impact people working in the system. Most are technical case studies or how-we-dunnits limited to one institution or consortium and specific to the time around migration. Human aspects generally show up in the background. I was particularly struck when reading Nicholson and Tokoro’s “Cloud Hopping: One Library’s Experience Migrating from One LSP to Another,” (DOI: 10.1080/07317131.2021.1973796) about their Millennium/WMS/Alma migration that they use emotionally-laden words such as “bewildering” and “arduous.” They write in their closing paragraph: “Migrations, even when they go smoothly, inevitably leave scars, sometimes permanent ones, on organizations and their data.” But who’s talking about those scars?

Understanding the Impacts of Migration

To set the stakes for the stresses caused by a migration, let’s take a detour into the headspace (and the bodyspace) of working regularly within the ILS. My first full-time library job was as a serials technician at the George Washington University Law Library. In those days, it meant regularly digging your way out from under piles of journal issues, court reporters, legal updates, and everything else that documents the ever-evolving nature of law. I worked in Millennium and then Sierra, which were pretty popular in law libraries because they support serials well.

For five and a half years, I would search in the serials module by title, find the virtual “card” for the expected item, check it in and create an item record, print out the basic call number, move the item record to the appropriate place in the item list if needed, and then check on the card for the next expected issue, ensuring it had the appropriate numbering and date so that we could run a claim if it didn’t show up. I then physically processed some of the items and gave others to the student workers whom I supervised. And I did this all day, every day.

There is a rather famous quote from the writer Annie Dillard:

“How we spend our days is, of course, how we spend our lives.”

It’s been interpreted in a number of ways, emphasizing that one must choose intrinsically meaningful work or, perhaps truer to Dillard’s original intention, that one cannot live entirely for productivity. I think there’s also something deeper in that how. 

If how a person spends their day is acquisitions work, they spend their day purchasing books, paying bills, and importing records and they spend their day doing so within systems. That means typing, scrolling, clicking, navigating… 

This is how your coworkers will spend a significant portion of their lives. If the series of steps needed to accomplish a task becomes more complicated or a function degrades, that change impacts the person every single time they repeat the task.

Ergonomic: Small Changes, Large Ripples

Sometimes, these impacts are ergonomic. A thing that jumped out of me from the interviews I’ve conducted to-date was the word “clicky.” I was hearing it from people using both Alma and FOLIO at different institutions in different parts of the United States. Most interviewees who used it were classed in staff roles, so not likely to be encountering each other or developing this word together. Some felt very good about the system or migration overall, but still noted the number of clicks they needed to do for any task as something which slowed them down or caused them some stress. For others, the increased time it took to do anything or the physical impact was a major stressor.

When user-testing things like a minimum viable product, we often ask questions like whether it’s possible to do something and whether it can be done without too much difficulty by the person performing the action. Does it make enough sense? But I have never heard someone say that they tested the impacts of performing a task in a system as often as the person would normally perform it, for several days in a row. Or that they’ve compared the number of steps to the steps needed to perform the task in existing systems. Sure, vendors threaten to sue the books off your shelves if you so much as let a competitor look over your shoulder while you’re using their product, but if they cared, Clarivate could certainly pull it off across their empire.

If a new system doubles the number of mouse movements and clicks required to complete a task, what’s the ergonomic impact on that person’s hands and wrists over time? If they have to wait for a page to load between each step of the task, how does that affect the amount of work they can get done or preclude a flow state? We might do well to think about our libraries a bit more like factories–not to follow people around with stopwatches like 21st century Taylorists, but to recognize that small changes can have larger impacts when scaled up to production.

Affective: “It Used to Just Work”

Another place where I hear frustration with workers who, in turn, are frustrated about new systems is when the complaints center on how something used to work. While (most days) I don’t want to revert us back to terminal-based ILSes, I will say that even as I’ve seen some things become better supported, I’ve also seen some real losses. These can be hard to see when you’re not the one doing the work itself, but sometimes systems work brings you into that headspace, if you let it.

Earlier this year, our Title/Begins With index in Workflows, essentially Title Browse, stopped updating properly after someone changed a flag in a cron job. I did troubleshooting on behalf of Acquisitions, for whom it was causing the most immediate problems. Talking with Acquisitions folks brought home to me the importance of that kind of search during the pre-order searching process. The Title/General index in Workflows just… isn’t good. That’s why we have Title/Begins With. If an acquisitions worker can’t be sure of a clear yes/no, they may spend extra time searching for an item we don’t have, just to be sure that they don’t order a duplicate. They also can’t experience the same confidence when determining that we don’t have something. At what point do you decide we don’t have it? It’s hard to prove a negative under these conditions.

About a month later, I interviewed an early Alma implementer whose morale has recovered overall from the initial disruption. She offered further insight on why longer-term staff still carried frustration about searching in Alma’s back-end. Newer staff expected a known-item search to require additional filters or some scrolling. Staff who’d been there longer remember that in their previous system they had the default title browse. They could type the first few words of a title and immediately got to the record. It’s not that people like her can’t use Alma’s search, she explained, it’s that they remember it used to just… work.

It’s not that people like her can’t use Alma’s search, she explained, it’s that they remember it used to just… work.

In addition to extra time spent or clicks required, we are reminded of the problem every time it becomes visible, such as when common words in the title force someone to scroll longer than normal even on the new system. And we know it’s possible to design a system that doesn’t work like this, because we have used one. 

For some, those reminders take an affective toll, particularly when they stack up or are frequently noticeable.

Technical Trade-Offs

Before moving on to things we can do in our workplaces and in the systems for which we’re responsible, I’d like to share an example of the technical trade-offs we experience during migrations. It’s a bit of a digression, but I think it illustrates the complexity of factors at play and why there’s no clear-cut good/bad in some of these situations.

The current legacy generation of ILSes, ones that have been around for quite some time, are all accessed via desktop clients. The LSP generation, on the other hand, use browser-based interfaces. There’s a lot of advantages to working in your browser–my library even has a few licenses of Sirsi’s Workflows emulation in the browser so that people can access it on the go if it’s really necessary.

When reviewing similarities in peoples’ descriptions of negative changes to their workflows, I realized that maybe half of them were caused by the inherent qualities of webapps. There’s a lot of delay caused by reloading and some of the clickiness is caused by navigating through a browser-appropriate layout vs. a desktop client. It’s a good example of the trade-offs in major system change because many of the same people appreciated being able to work in a browser. Some also loved being able to flow through the interface and not need to open separate wizards for each kind of task. So I don’t think that means we should move back to client-based ILSes or, god forbid, engineer some kind of modern webapp monstrosity. 

So if we have limited capacity to change these systems, how then to pivot to the desired outcome in one of these talks, something inspiring or useful, something that’s not going to leave you feeling depressed by our options or defensive over whether the impacts are really that bad? If, as one systems librarian said to me,

“we’re responsible for it, but we don’t have any control over it,” what are we supposed to do?

First, I want to address the “we.” There’s also the many different “we” who are here today. Some folks are systems librarians, some are technology directors, some are software vendors, but others are liaison librarians or technicians, less directly connected to how these systems are set up. Just by being here at VALA, you’re likely either comfortable with technology or curious and willing to explore it. Your proximity and power in systems will be relative, but please write yourself into the “we” of the part that follows, whatever it means for you.

Moreover, even if we were to burn down the current generation of library systems and start over from scratch and with the best of intentions, listening closely to the people who will be doing the work, some trade-offs, like the unintended consequences of the shift from apps to browsers, can’t be avoided. FOLIO’s design process has involved significantly more collaboration than Alma’s and yet both cause significant workplace stresses.

We cannot technology our way out of human complexity.

Building a Culture of Reciprocity

One of the most startling things that’s happened in interviews and in survey results is the experience of listening to a person recount technical challenges and struggles that remain unresolved to this day but then assess their morale as good or at least decent, considering.

After trying for a while to name this thing I was hearing in their descriptions of their workplaces, I realized that it could be described as a culture of reciprocity. They were actors in their department, library, or field, not simply acted-upon. I found the word “reciprocity” in Franklin’s Real World of Technology lectures, where she describes it as:

situationally based. It’s a response to a given situation. It is neither designed into the system nor is it predictable. Reciprocal responses may indeed alter initial assumptions. They can lead to negotiations, to give and take, to adjustment, and they may result in new and unforeseen developments

Even in 1989, she had identified the trend of soliciting feedback as a limited substitute for reciprocity, one which maintains distances between the people giving and receiving it. “Feedback,” she writes, “is a particular technique of systems adjustment. It is designed to improve performance … its purpose is to make the thing work.” It’s not bad, but without reciprocity, it’s also not enough.

She adds: “where there is no reciprocity, there is no need for listening.” Feedback is something we can take or leave. How many of us have felt dismissed by “thank you for your feedback”? Tell your university’s president that you’re deeply concerned by the lack of care with which budget cuts are being handled? Thank you for your feedback. Tell a politician that you desperately want your taxes to go to libraries, or anything but more weapons? Thank you for your feedback.

Whether you believe that you’ll be heard depends largely on what you know of the person and system and what reciprocity and responsiveness you’ve witnessed in the past. Building reciprocity requires us to acknowledge relative power when we have it. Some days I don’t feel like I’ve got much power. But my relative power in the workplace is enormous in comparison with that I had when I was a serials technician. So, when we are lacking a culture of reciprocity, if we have the power to change dynamics it is on us to do the necessary work of starting it.

For example, the first challenge a technical person may face when doing this work is establishing enough trust to even hear someone’s feedback. One of my systems maintenance interviewees described entering a new workplace and realizing that her coworkers had become so demoralized about the systems now she managed that they wouldn’t even bring her their problems to fix. She had to slowly establish that she actually wanted to know the people and what they were running into, and that she would fix it if she could.

Although she didn’t use the word reciprocity, what she described was the slow cultivation of reciprocal relationships. She couldn’t actually fix everything, but she demonstrated that respected her coworkers enough to either try or to explain what was and wasn’t possible under the circumstances. She treated their problems as real and they recognized and respected her limitations in the system. This is the true reciprocity. It is not one-sided attentiveness to our coworkers. It benefits us and it makes us more than the faces of these systems that we can only make work so well.

I’ve identified three things in my research so far that support a culture of reciprocity in a workplace. These are:

• Respect,
• Empowerment, and
• Collaboration

These are basic, maybe trite, but powerful. They may be fostered by technologists, managers, or others who have institutional power or greater comfort in a situation. It also feels presumptuous to take anything Franklin wrote and write bullet points after it, so I want to reinforce that I don’t want to limit or reduce her idea of reciprocity, though I hope she’d approve of these as characteristics of a culture of reciprocity.

Respect

People want their reports of their own experiences to be respected. I think this is one reason I went into so much detail about my serials technician work. I want respect for that work and for the people who remain in those positions, not just the ones like me who go on to become librarians and get invited to speak at conferences half a world away. 

I was struck by an experiment that Sara Fine conducted as she was trying to build greater communication between people with widely different attitudes toward technology in organizations undergoing automation. In her research, she observed that simply advocating for technology was insufficient to change “resistant” people’s minds or cause them to rethink their experiences. Arguing was similarly unproductive.

Instead, she developed workshops where people could “express both positive and negative [responses] to the changes … taking place in the organization.” These were not attempts to convince one side or the other. They also weren’t just gripe-fests. Participants were encouraged to share things they liked about the changes and to reflect on aspects of their work lives that they could and couldn’t control. One of the outcomes for everyone was to identify what they were going to do in the places they had control.

One primarily goal she set was “to teach the advocates of technology to listen to the [resistors] without trying to minimize their concerns, without making them defensive of their position, and without causing them to retreat into silence.” In her assessment, the advocates’ “increased ability to listen to resisters without feeling the need to debate them generally resulted in a more positive state of communication in the organization and more effective negotiation of different points of view.”

I see her project as one attempting to build a culture of reciprocity by laying the groundwork of respect. Sometimes, respect is as far as you’ll get in reciprocity. During that initial period of migration, everyone may be spending too much cognitive energy adapting to the new system, reconceptualizing their workflows, or putting out the fires to exercise creativity or solve problems. And some are spending all their creativity and capacity outside of work, whether because their lives require it or because they’ve decided that they’re not paid enough to bring it here. (As someone who’s been underpaid staff at the bottom of an org chart: fair.)

But once you’ve got respect, the door is open for further empowerment and collaboration.

Empowerment

intentional actions which support a person in using the system to do their job better

Empowerment feels to me like a good word that’s become a fraught word. Too often in workplaces, it translates into offloading responsibility onto individuals without setting them up to succeed. When I think about empowerment, I think about the joy of watching people light up as they describe how they made something work or were set up to be better at their jobs. I also think of its opposite, disempowerment, and the stark difference in people’s faces and bodies as they tell those stories.

In the context of systems migrations, I’m going to define empowerment as “intentional actions which support a person in using the system to do their job better.”

Sometimes, empowerment means extending a person’s permissions in the system. One interviewee shared that they’d recently been granted privileges to create record sets and run normalization rules in Alma. They described the care they exercised in making sure that these new privileges didn’t screw something up and their pleasure at running updates and seeing results. Back when their library used Voyager, they’d had to request updates from one of the few people who could use its global data change. While they still found parts of Alma frustrating, this extension of their capacity in the system had improved their overall morale.

I’ve also seen the flipside here – thinking in my head “but, Alma Analytics can totally do that!” as a different interviewee described no longer being able to get certain kinds of information after the migration. When I asked if they had access to Analytics, they said that no, it had only been given to a couple people whose jobs were around assessment. Further discussion revealed that leadership at their library and those implementing the system had generally left subject librarians out of the process and, importantly, did not give them the same reporting-type powers that they had in the previous system.

In a conversation with a subject librarian at yet another institution, I learned that this person did have access to Alma Analytics, but any time they asked for support in learning to use it, the person who could train them just ran the report instead because it was faster. Although the choice was surely about convenience and not respect, this led to the person feeling shut out. While collaborative work can be great for morale, having to go through someone to do things is incredibly disempowering. (And as the person on the other side of this situation, I understand the desire to do a task in 5 minutes instead of spending an hour training someone and then answering follow-up questions. It’s something I work to balance.)

Sometimes, empowerment means giving people enough time and direction to figure out how to improve a situation themselves, whether by finding a better way to do it in the system or creating a workaround.

I spoke with someone whose position involved making frequent batch edits to MARC records. In Sierra, Global Update made this fairly easy to do. Batch Edit in FOLIO, however, is… a work in progress and nothing for MARC was in production when we spoke. The next logical choice would be to export records, run changes in MarcEdit, and reimport, something they also knew how to do, but FOLIO has been working through challenges with that kind of ETL cycle for larger batches of records. So, along with other coworkers who’d needed to do it, they’d identified the simplest method of editing records one-by-one. This was one of the interviews where “clicky” showed up.

But then, once everyone was a little more comfortable in the system, this interviewee’s supervisor approached them with an idea. Might they look into macro-type tools which might automate the process? Since it’s a browser application, what about browser extensions? Could they experiment and report back? After some experimentation, the interviewee found a Chrome extension which could record and repeat a series of clicks. Their whole unit finds this useful for handling the “clickiest” tasks.

And sometimes, empowerment means ensuring that people are involved in collaborations, which I’ll talk about next.

Collaboration

In building a culture of reciprocity, respect is a starting place as we relate to our coworkers. We can also ensure people are included through collaborations about using these prescriptive systems, within our institution, within a consortium, or in ways that may actually feed back into their design.

Now, there’s a lot to say about the importance of collaboration before and during a migration. I’m going to talk a bit about ways it improves morale once the system’s in place.

One of the many things that consortia may do together is negotiate for ILS purchasing. Sometimes they’ll even implement a consortial version of the ILS, where all of their systems overlap a little, or a lot. Several interviewees spoke of collaborations within their consortia as places where they experienced boosts to their morale or comfort with the systems. These often start as places where people doing similar work could figure out how the new system worked, share their processes, and work through the problems they were encountering. They were peer-organized, rather than hierarchical settings. A consortial Alma user, one who’d hit some challenges but also felt pretty good about their current work said:

Even though we sometimes complain about the system, we also have really bonded a lot. … The complexity of Alma requires a lot more collaboration and cooperation, among different departments and among people in similar roles at different member institutions.

It reminds me of Fine’s workshops, in that participants can share what they do and don’t like about the new systems, apparently, from their descriptions, without a fear of being looked down on or evangelized about why the new system is better. These are places where a person can share their workaround or where a couple people can split off to work on a problem affecting only them. An interviewee shared that their consortial group was only planning to meet for the first year or two after the migration, but even though the system is pretty much in place, they still meet periodically to share ideas or practices they’ve found useful, particularly when updates come out. When you’re not part of a consortium or larger system, regional user groups can have similar benefits without the pressure that may occur at a national level.

Lest you think I’m overstating the positive impact it can have, after describing the things that they and others in their consortia still couldn’t do in FOLIO, another interviewee observed:

It’s ironic, like you’d think that all the extra workarounds and the fact that we still don’t have workarounds for some things like would lead to low morale. But I really love how we work together on it.

That FOLIO user also found it empowering to be part of the collaborative process of setting user requirements for further development. “I’m part of a wider group of people,” they said, naming institutions and countries from which other special interest group members came. “I’ve definitely gotten a lot of skills I wouldn’t have otherwise.”

Respect, empowerment, and collaboration may look different to you, depending on the kind of work you do, but no matter the kind of library we work in or the technologies we use to make that library work, whether you’ve migrated between systems recently or are still using something you put in place 25 years ago, we all benefit from working in a culture of reciprocity.

Conclusion

I’m not going to pretend this doesn’t take work or time. As I mentioned before, it’s much easier to take 5 minutes to run a report for someone than to spend an hour to teach them to do it. Sometimes that’s the best choice we can make on that day. But, over the course of our careers, we can choose to position ourselves as arbiters or gatekeepers of the systems or we can position ourselves as experts in one part of making Library happen who work alongside those with expertise in other parts.

We can choose to respect our colleagues, understanding that we may both experience the same system very differently. As we respect and get to know them, we can identify ways to set them up to use these systems better, whatever that looks like for them. And we can ensure that people we manage or people who use the systems we support have ways to collaborate on problem-solving or even contribute to their design.

Even if you cannot transform your entire library – I get it, we have over a hundred librarians alone – what can you do to shape how people experience their interactions with you, your team, or your department?

What if we recognized that we are as interdependent with our coworkers as our systems are with each other?

What would it look like if we made it our goal to build a workplace where, as one interviewee put it, “they didn’t let anyone slip through the cracks”?

Thank you.