Column Editor: Xan Arch (Collection Development Librarian, Reed College Library) <[email protected]>
Moving from a large institution to a small one, my management responsibilities have changed. From managing a group of people who all perform similar tasks, I’ve moved to managing two people with completely different responsibilities. I manage far fewer people now, but in some ways it’s more difficult. If you have something new to introduce, a change in workflow or a new tool, a larger group can learn together and use their peers as models, while an individual may feel like they are being judged by the speed at which they comprehend the process or feel that they are being singled out as the only one who needs to learn a new task. They may have created their own procedures, and these new processes and tools are disruptive to established work patterns. Libraries are changing rapidly, and much of the brunt of the change falls on the long-time staff members. How do we manage them through this kind of disruptive change in their work?
First of all, I have learned in the last few years is that not everyone is an experimenter. When I look at a new tool or process, I want to try it out, hopefully without the risk of breaking anything. I want to poke it, play with it, click the random buttons to see what happens. Sometimes I assume other people are like me. I have presented new tools to staff members and said “try it out and let me know what you think,” assuming that the ability to experiment would be exciting for them and a good way to learn the new tool. Not all people think like that, however. For some people, it’s not a liberating experience to play around with a new tool; it’s a waste of time until they understand how it fits into their work. They want to know why and how and when. With a group of staff members, a manager can pick the person who will like to try out a new tool and will provide valuable feedback. Then the new tool can be rolled out to the group more fully-formed. Sometimes the group’s adoption may happen over time and the manager can have a subset of the staff perform the new process until the whole group is comfortable. With a single staff member, however, their adoption is crucial, as is their opinion about the process or tool. If experimenting with a new process is intimidating, not fun, it may be harder for them to be willing to adopt it.
One way around this is to present the new process or tool as a fully-formed idea. Working with someone who doesn’t want to experiment may mean that you are providing training and documentation along with the new process or tool. If presenting it half-baked, as an experiment, leads to confusion or fear, then don’t ask your staff person to experiment. Use it yourself, decide how it will be used in the department, and then roll it out with documentation and training.
The drawback is that if a process feels finished, it is assumed to be finished. How do you ask for feedback and find problems in the process? In the same vein, while the idea behind experimenting is that it’s ok to make mistakes, just because you have provided training and documentation to your staff, they may still make mistakes as they learn the new process. Often mistakes are what they are most worried about. They wanted to know exactly what to do from the beginning because they didn’t want to do it incorrectly.
As a manager, accepting mistakes and correcting them without visible frustration is an important part of helping the staff person feel ready to try the new tool again. And maybe, just maybe, you didn’t provide everything they needed. I’ve often felt frustrated when it seemed like someone didn’t listen to me, or read the document I created, only to find that they have identified a bug in the process or a gap in the documentation. The process might have been clear to me, since I wrote the document, but much less clear to anyone else reading it. If the way to encourage adoption is to present a process with documentation and training, rather than as an experiment, it has to be accompanied by a request for feedback. Often I explain that while I have outlined the process, they know the intricacies of their workflow best, and they can help me correct anything I might have done wrong. And if they make mistakes, everything is fixable.
It’s also important for our staff to know that they are not alone in their work changing. They know how their everyday tasks have evolved, but often they are a lot less clear on the changes in the library as a whole. If your staff members feel like they are the only ones that have to make changes in their work or learn new processes, they may feel picked on or singled out. Managing larger groups, my remedy for this is to provide an update of my ongoing tasks at group meetings. This usually sparks discussion of how these tasks fit into the library’s upcoming projects and goals, and what might be coming down the pike for that group. Since my tasks often involve other departments, I can give the group a wider appreciation of the library’s workings. This is not as easy with a solo staff member, however. There may not be an opportunity to discuss ongoing projects without group meetings as a container. It’s just as important, however, for these staff members to understand what’s going on in their workplace. If they understand the bigger picture, they will understand the institutional changes that make changes in their work necessary. They aren’t being picked on, they are being asked to contribute to a movement that is larger than themselves. In one-on-one meetings, I often talk to my staff about my own new tasks, and my concerns or frustrations with those tasks. Sometimes they have suggestions for me. Sometimes they could care less. But they realize my job is changing, just as theirs is, and just as rapidly.
New processes and tools are an inevitable part of working in a library. Providing context for these changes and understanding how people react to these changes, whether in groups or as solo staff members, can make the adoption process easier for staff and managers.