By Suzanna Conrad

You’ve probably faced people within your organization who are fearful of change, especially technological change. It can be difficult to convince techno-leery individuals that technological change can be exciting rather than scary. Change can take the form of a web redesign, a new integrated library system, virtual servers, morphing roles of library vs. organization IT, etc. Convincing library stakeholders that change needs to happen can be a daunting task as a systems administrator, web developer, technology consultant, or technology manager. This article will discuss fears associated with technological change from a change management perspective. Technology projects will also, within this article, be framed as complex sales or “long sales.” Lastly, this article will provide practical examples for modifying communication patterns to get people excited, or at least grudgingly accepting, of change.

Fear of Change

Fear tends to precede change, regardless of the rationality of that fear. Bob Sacks calls this “the fear that comes along with change from what was once known and comfortable to what is unknown” and that despite “changing and adapting for a millennium…the pundits of the day try to resist the inevitable” (Sacks 2011, 50). Christopher Durney and Richard Donnelly acknowledge the challenges of keeping up with change, as “the pace of technological change often outruns and undermines the best project management planning efforts” (2015, 642). Durney and Donnelly define six strategies that managers can employ to address fear and technological change: (1) identifying risks, (2) defining staff that will be responsible for handling change, (3) using adaptable management styles, (4) focusing on the core business, (5) thinking about how to be resilient, and (6) supporting innovation within the business culture (Durney and Donnelly 2015, 664). Todd Jick presents three phases of change management that are important to address: drafting the vision for change, implementing the actual change, and addressing reactions to change (1993). Annie Bartoli and Phillippe Hemel discuss the various barriers to change, especially in IT management, as separating into strategic, structural, cultural, and behavioral barriers (2004).

Resistance to change in organizations, especially technology innovation, is something oft discussed in management literature. Felicia Su Wong attributes fear of technology to the fear of missing out: “the organizational and personal experience of technological adoption and use often has been driven by a fear of being left behind in this very process of Progress” (2003). Yongchuan Bao asserts that improving communication within an organization can address organizational resistance to technological innovation (2009). Robert Reardon finds that learning culture plays a large part in resistance to or acceptance of technological change; Reardon defines a strong learning culture as one in which “creating a climate of learning should speed the smooth transition to the new technology” (2010). For an organization to have a strong learning culture, the organization needs to be committed to fostering systematic thinking, be willing to experiment with change, able to learn from past experiences and the experiences of peers, and have the capability of communicating this knowledge throughout the organization (Garvin, 1993). Without an established learning culture, change is difficult; in Reardon’s study of blue-collar workers at manufacturing sites, he found a major correlation between lack of learning culture and disgruntlement (2010). Libraries are not anomalies; many of our colleagues may be leery of technological change. They may distrust technology and technologists; and because of these fears they may block innovation or even necessary improvements. But we can frame these projects differently: convincing people to overcome their fear of change can be a gradual, iterative process.

Change as a Complex Sale

Complex sales are sales that require input from multiple decision-makers, often at various tiers of an organization. They are considered to be complex because of the time and monetary investment required to close the deal. Think of the library’s business of purchasing eBooks: a simple sale is made when a subject librarian or selector chooses eBooks to purchase in a specific discipline; one book can be purchased without involving others in the final decision making process. On the other hand, selection of an electronic resources management system for managing eBooks requires buy-in from all levels of the organization to implement successfully. Input on the system would be provided by personnel in acquisitions, cataloging, systems, management, as well as the subject selectors. Selling an electronic resources management system to a library would constitute a complex sale.

Jeff Thull focuses on the idea of “value clarity” in Mastering the Complex Sale. In order to sell a complex service to a company, a salesperson has to be able to connect customers’ needs and potential use cases to the benefits of purchasing a service. In business, it is frequently difficult to close sales due to delayed decisions based on customer uncertainty (Thull, 2010). Pushing through technological change can be similarly challenging: if customers’ needs are not considered, or the communication is not framed in such a way that they can perceive value, projects can stall to the point that the technology is already outdated.

Changing the Narrative

Managers of technology projects, or even stakeholders involved in the process, may want to assess how they approach conflict. Are you defensive when questioned about a change or do you negotiate with stakeholders to try to find compromises? Thomas and Kilmann’s Conflict Mode Instrument defines five areas where one can fall on a scale of assertiveness compared to cooperativeness including competing, avoiding, accommodating, collaborating, and compromising (Thomas and Kilmann 1974).

Competing is the most assertive of the five areas; a competing person would concentrate on getting their own way with little room for negotiation. Accommodating is at the other side of the spectrum; someone who is accommodating allows others to dictate in which direction the project is headed and accommodates others’ wishes. Avoiding is the least assertive and cooperative of the five areas; avoiding the conflict means that it is never discussed or broached. Collaborating falls at the most assertive and cooperative level; collaborating involves working through the conflict or disagreement to dissect what others’ concerns are in the hopes of finding a new solution that is satisfactory. Compromising falls in the center of assertiveness and cooperativeness; it does not involve diving into the details as much as collaborating, but finding wins for each of the parties. Collaboration, though it takes the longest, may be the best approach for technologists dealing with stakeholders. By collaborating, both parties can leave with the feeling of accomplishment and involvement in the process, as the solution should theoretically fulfill the needs of everyone. Compromising may also be a desirable alternative as the original solution may still be possible after working together to find gains for both parties.

In a previous position, I was involved in a major website redesign, which was led by central IT. In the beginning of the process, the library and campus IT had very different expectations of what headers would look like on the library’s homepage. Campus IT had designed a header that included a global search box, which would search all campus pages. It was not a simple process to ask campus IT to change the template; we had to dig deeper and provide feedback about the role of search on the library homepage. Specifically, we presented them with search log analysis, usability testing results, and web statistics to make a case for a library-centric search box. By the end of the process, they had a greater understanding of the library’s role and mission. This was a great example of compromising; it took multiple meetings, data collection, and cordial discussions for campus IT to understand why we were so adamantly against prominent positioning of the campus’ search box on the library webpages. Similarly, throughout this same process, we made concessions. We received a special template for the library, but agreed to incorporate the campus footer as well as certain elements of the campus header.

Thinking about how you approach conflict is just one piece of changing how you initiate innovation. Positive communication is at the core of changing the narrative. There are tactics that one can use to try to minimize fear, impatience, or distrust. Four examples include: (1) delivering regular updates; (2) soliciting feedback; (3) remaining honest; and (4) communicating bad news with potential wins. First, delivering regular updates can make your stakeholders feel informed and included; when someone is not receiving communication regularly enough, it can lead to frustration, anger, and can endanger the success of the project. Sometimes, it’s even worth checking in when there is no update to let stakeholders know why nothing new has developed and give estimated timelines for when more news can be expected.

Secondly, soliciting feedback is important. Few people will willingly accept what is perceived as difficult change if they do not feel that they have been consulted. Many technologists in libraries work in shared governance environments; you especially have to leave room for consultation in these situations. Sometimes you can’t make the changes that someone wants or deliver the product they would prefer, however, if they were consulted and informed, it at least starts a positive dialogue and signals that you care about their input. Also, be willing to take and accept the feedback that is given to you. Your stakeholders have input based on their daily interactions with a system or with the public. You, as the technologist, will not always have all the details. Feedback from stakeholders and users can help with success during implementation even if it does not align with what your expectations may be.

Honesty is important throughout technological change, or any change. Perhaps a change is happening because you have a mandate, you want to improve a service, or because you have more (or less) funding. Change can be spun to be positive, especially if you are transparent and forthcoming. Exercising empathy can help conversations; if you think about what that particular stakeholder is frustrated about, you might be able to work out alternatives, better solutions, or help with training.

Lastly, sometimes there is bad news. An interface may be changing for the worse, or a task might be harder to do in a new system. In the case that these changes are inevitable and include bad news, drawing out potential wins to deliver along with the bad news can help soften the impact. For instance, you’re moving to Office365 cloud services and people are upset that the webmail interface will change to something they do not like. Telling them about increased storage space, then the bad news that the interface will change, and then letting them know they can download the clients on up to five machines may help ease the discomfort with a new user interface.

General Communication Tactics

When people feel as though their feedback is being respected, they are more likely to welcome change. Certain communication tactics can help you to ease technology-leery individuals into embracing or at least accepting change. These are simple, logical tactics, which might take practice to implement, but will help in guiding you through difficult conversations.

First, be careful about how you are reacting to discussions. Listen without any disruptions. Do not interrupt as someone is speaking – give them a chance to air their concerns. Also, is your body language positive? If you’re shaking your head “no” as someone is speaking, rolling your eyes, or pursing your lips, the discussion may escalate into conflict. If you have devices, such as a cell phone or computer, do not glance at your devices unless you are referencing something related to the discussion.

The words you use are important, especially when dealing with a situation that is or could become a conflict. Using “I” statements instead of “You” statements is good practice. The statements “You’re not listening to me” vs. “I feel as though I’m not being heard” can be perceived very differently. If you avoid using the word “you” in conversations, you may find that the language you’re using is less confrontational.

Email communication is especially tricky as the written word is easy to misinterpret. The shorter and sweeter your messages in potential conflict situations, the less likely the situation will escalate. Three tips that can help with reducing conflict that could start via email are: (1) be brief; (2) state facts and provide resolutions; (3) avoid emotional language. Brevity means that less is more; try to respond to an email with two sentences if possible. The longer the email, the more likely you are to write something that could be misinterpreted. Stating facts and resolutions allows you to acknowledge a problem and provide a solution rather than to delve into the why or how. Lastly, avoid emotional language. Third person phrasing without the word “you” may help as mentioned in the above paragraph. Avoid the use of adverbs as they add emotion. These can include simple words such as “very” and “just” and most any word ending with an “ly,” such as “easily” or “unbelievably.” Here are some examples of written text that could be perceived as emotional by the reader:

• “I’m sorry you’re having difficulties with the system.” While this sentence may attempt to employ empathy, it could be perceived as judgmental. This is accentuated by the use of the word “you.” Using the word “you” could be read as passing blame to the person you are writing to, especially when used in close proximity to the word “difficulties.” A better phrasing might be: “I apologize for the issues the system is experiencing.” Here the only blame that could be attributed is to the “system.” Often, it is possible to pull the “you” out of a sentence by framing it as an “I” question as in this example.
• “The system was only down for ten minutes.” In this sentence, “only” implies that ten minutes is not a long time. If a reference librarian is answering a patron’s question and that patron has limited time, ten minutes can be a long time. Taking the “only” out of the sentence turns the sentence into a statement of fact: “The system was down for ten minutes.”
• “I’m just trying to resolve the issue.” The word “just” in this sentence is unnecessary and it gives it emotional weight that could be misinterpreted as frustration or anger. Simply stating “I’m working to resolve the issue” leaves less room for emotional interpretation.

It is easy to think your email is not emotional, but it could be perceived as such regardless. If you are not sure whether your email sounds emotional, let someone else read it and see how they interpret it. Or, if the the content is confidential or sensitive, read it aloud to yourself – you may hear the tone differently when you read out loud.

Scenarios

Scenario 1: Campus or City Website Redesign

You receive news that the campus or city will be redesigning their website and they expect the library to take the global template. Additionally, you are informed that you will have to use the campus or city’s content management system, which you have heard is clunky and requires extra steps for publishing.

Frequently, libraries’ parent institutions group the work that we do into the chunks similar to the general business of the organization. For instance, an academic library may be perceived as an academic college. Arguably, the two organizations do very different work. An academic college’s website is more informational and geared toward sharing details about departments, degree programs, featuring faculty, listing available courses, etc. The search function is less crucial than it is to an academic library’s website.

All is not lost though. A message such as the scenario presented here could be an opportunity to rethink the website and how it fits into the mission of the organization. A communication channel can also be opened in which control issues and concerns can be expressed with IT or whichever group is initiating the change. Additionally, opening a communication channel is also an opportunity to open discussions with IT about web services, which could benefit the library in other ways.

As previously mentioned, I participated in this scenario in a campus environment and initially had to improve information sharing to facilitate the success of the project. After initial hurdles with sharing library perspectives, our relationship with campus IT improved as the web redesign progressed. Campus IT was migrating most of the websites for the campus and once they realized we had a capable web developer, they gave us some additional permissions in the new content management system to allow us to do our own migration for the most part. More advanced template or technical issues had to be escalated to their staff, however, we developed direct working relationships with contacts we had not had in the past. After the migration was completed, our interactions with this department continued. If we had ideas for new web-based services , such as a faculty profile system or an improved group study reservation system, we often would check in with the web services department first, as they took the time to look at our ideas and could provide internal pathways to other IT departments that would help with implementation.

Scenario 2: Consortial System Implementation

You are a part of a larger consortium of libraries. You hear that the consortium is planning on centralizing the library management system. It is unlikely that it will end up being the system you currently use. You are concerned about losing control and having to learn everything new again.

Consortial systems certainly offer benefits in cost and functionality that you might not experience with a standalone instance. Moving these systems to consortial models is also becoming more and more common. Shared systems may lead to staff time savings, shared integration of 3rd party software, monetary savings, etc. There are simple ways to talk about the bigger goals with this kind of move. Perhaps certain tasks will be easier in the new system. Maybe the system will help reduce mundane tasks and give you the chance to work on more exciting projects. Lastly, and perhaps most importantly, you may be able to develop partnerships with institutions and individuals you have never spoken to before. You will have a network of individuals with whom you can interact to make your use of the system more skillful and efficient.

In Fall 2015, the California State University’s libraries embarked upon the Unified Library Management System (ULMS) project to consolidate all library management and discovery systems across the 23 CSU campuses into one shared instance. Discussions about consolidating had begun over two years prior in Spring 2013. Two CSU libraries were already using the chosen software, Alma and Primo from Ex Libris, however, many campuses were using integrated library systems from other vendors. I worked at two CSU campuses during the migration period; first, at one that was migrating from Innovative’s Sierra and then at one already on Alma and Primo. As these discussions were developing at a higher level, staff at the campus using Sierra were panicking. We had only recently migrated to Sierra with some hiccups in the process. Staff were concerned about major changes to workflow, changes in functionality of the system, and the long-term viability of their jobs as the system was marketed as a way to reduce redundant work across the consortium. Because of these fears, our library organized general vendor meetings with all of the vendors who were intending on submitting requests for proposals. Within these meetings, it became clear that certain functions would be much easier in Alma and highly desired features, especially with analytics, would be possible. A few staff began to see that it could benefit them to move to the new system. Internally, we continued to discuss the project as a positive one; the attitudes of the people communicating the change can make all the difference in the success of a project.

I moved to another CSU campus midway through the migration process. This institution was already on Alma and Primo. While we did not have as much to prepare for migration as a campus on Sierra or Voyager, our first migration had not gone as well as we had hoped, so we planned many clean up projects to make the second migration more successful. There was less anxiety about the functionality of the system, although we were more curious about the impact of some of the consortial gains as we had been using the system for a few years before moving to the shared instance. Many of the subsequent wins from the second migration were first realized well after migration; gains in improved processes in technical services have been allowing staff to work on other pending projects. The landscape of resource sharing has changed as we share among our institutions. Not everything is functioning perfectly in the new shared instance, nevertheless, communication amongst all campuses has improved. We have listservs and Slack channels. Staff who did not know one another before are connecting and sharing best practices. Our institution has had an opportunity to share our best practices, thereby featuring the work and successes of our staff.

Scenario 3: IT is Centralizing

You receive a message that IT is centralizing and will be claiming many of the IT staff in the library as well as servers housed in the library. Everyone is panicking about how support will suffer and that the library’s priorities will now be listed with everyone else’s priorities.

For many of us with local IT staff, such as desktop support, web developers, server administrators, and programmers, it can be difficult when staff are pulled away from the library to manage systems and projects for the whole organization. However, centralizing services may help improve service or security in some cases. For instance, recruiting a good server administrator can be difficult; if every department in an organization would need to hire their own server administrator, they might not find enough staff locally. You might also need to hire a server administrator who would handle additional tasks such as web development, application management, etc. A centrally located server administrator in the city or the campus staff could, with proper communication channels, be more effective than dispersed individuals across the institution as efforts could be concentrated on this one area. Furthermore, this message that IT is centralizing is an opportunity to open communication with IT so that they understand the needs and requirements of the library. If communication is initiated, negotiation might even be possible. Perhaps there are ways to keep some of the staffing or services depending on expertise levels in the library. Or it is possible that with centralization, you have access to a larger network of IT support.

I have not been part of a centralization where staff are moved out of the library into IT, however, I have joined a library shortly after this happened. At my previous institution, there had been four IT staff members in the library, two of whom managed desktop computers. The other two staff managed the integrated library system and the library website. When centralization occurred, the library lost both staff members assigned to desktop support, but kept the web developer and ILS manager. The library was able to make a case that those two functions were core to library operation. One of the staff members who was moved was still assigned to the library as our main desktop support person for the first year or two, so the transition was easier, as we were familiar with him.

After two or so years, IT assigned a team of desktop support technicians to the library to manage our labs, classrooms, and staff desktop support. While the transition was not always smooth, we established new connections within this department of campus IT. It did, at times, take longer to get a response, but generally we had a network of individuals to contact, so if someone was out of the office, a knowledgeable replacement could be sent quickly. The director of the program was involved in a number of technology spending projects on campus, and due to our new integrated model, he confirmed that usage in the library was higher than other areas of campus. Therefore, computer refreshes in the library building were prioritized very quickly. We also had discussions with this director about purchasing computer usage statistics software that would allow us to build availability maps and similar tools for student convenience.

Scenario 4: Moving to a New Discovery Layer

Your library has decided to move to a new discovery layer. Many are displeased with the news, as they have been using the existing catalog or discovery layer for a number of years. Instructional guides and tutorials will need to be changed. Users will have to be re-educated about the change.

Normally, there is a reason for moving to a new discovery layer. One reason may be evolving user needs; many users expect a comprehensive search and are not interested in searching in multiple silos of content. There may be a cost savings to adopting a new discovery layer that could allow for spending in other areas. If the discovery layer is being adopted because of changing user expectations, discussions with stakeholders about ease of use for the patrons is an initial topic to broach. If you have usage data, usability studies, or anything to support these arguments, this would be helpful. Transparency in cost savings, if possible, may help to illustrate good reasons for moving to a different discovery layer. If there are hesitations due to the limitations of the new discovery layer, presenting better features not available in the existing system may be a starting point. It may also help to discuss the vendors’ enhancement timelines, to see when and if certain features will be usable.

Within a few months of getting my first tenure-track librarian job, the consortia I was working in purchased a new discovery layer and our campus opted in for purchase. In efforts to prepare to move to the discovery layer, I served on a local task force investigating the change. I offered to do a survey of student users to gauge their reactions to the new discovery layer. I had nearly 600 responses to the survey with 99% of the responses coming from undergraduate and graduate students. The response to the discovery layer was overwhelmingly positive. We had been separating search results between the library catalog results in a Millennium OPAC and a Metalib search of articles. The new discovery layer combined these indices. I summarized the results of the survey, showed a demo to librarians, and we scheduled a launch. In this instance, this could have been handled more effectively. I launched at a less than optimal time during the semester, as I was not familiar with the teaching schedule of many of our librarians. I also was too green to understand the importance of delivering a message multiple times and letting some discussion or contemplation occur. Many of our librarians were dissatisfied with the implementation of the discovery layer. Over time, many adapted and began to use the discovery layer more consistently, but this situation taught me to take the time to consult with stakeholders and to provide adequate feedback loops. Sharing of data and decisions did not need to happen within a short period of time, but should have been spaced to allow all to feel consulted and included.

Scenario 5: Launching a New Website

Your systems department is working diligently on a website relaunch, as the template you are using is many years old. Content has become unmanageable and many potentially unnecessary webpages exist within the site structure. Your staff is hesitant to make this change as printouts, instructional materials, and other printed materials will have to be updated. Furthermore, they are wary about learning the new interface as they are comfortable with the existing site’s functions and content.

Many libraries struggle with implementing a new library website. Staff and patrons are often attached to user interfaces they are familiar with and push back when changes occur. It may be necessary to move to a new website because of a dated infrastructure for the website, or perhaps your library wants to have a more modern look and feel. Involving stakeholders in the feedback process when you are designing a website can forewarn them to the change and help ease the transition. This may entail organizing surveys, focus groups, or sharing plans at various points of the process. Planning for support and training can also reduce anxiety about change.

I have been involved in a number of website relaunches, both in library and corporate settings. The implementations that have been the most effective were those in which feedback loops were built into the project timeline. Most recently, I participated in a complete relaunch of a library website where all prior content was discarded and new content was built from scratch. A consultant was hired to administer focus groups, provide a human centered design report, and build templates based on the data. We held focus groups with both staff and patrons. We made transcripts and recordings of these sessions available to library staff for review. Analytics reports were reviewed to discuss the information architecture of the site. A website update team was formed including representatives from all departments. After feedback was collected, the consultant compiled results into a report, began creating mockups, and defined the information architecture for the site. We built feedback loops into all stages of the process: whenever a new template or new deliverable was received from the consultant, it was reviewed by the website update team and library administration. All departments crafted text for the webpages affecting their areas; the website update team reviewed these texts to try to align the voice across the website. A library-wide meeting was scheduled once templates for the homepage and subsequent pages were developed; the consultant presented the template and our team talked about launch dates and implementation plans. We left time for questions and also fielded questions via email or phone after the presentation. In the weeks leading up to the launch, we publicized the upcoming change across campus and kept library faculty and staff informed about progress. Overall, the launch went successfully. We had some parts of the website that were not ready for production and were launched subsequently. As analytics were collected over the following year, we shared out the results of the changes. I believe that this project ran more smoothly because all of the opportunities for feedback that were included in this process.

Conclusion

Approaching change with an attitude of fear or trepidation will almost always make the change more difficult. As a technologist, you can prepare others for change with good communication skills and reassurances. It is rare that a technology will only have negative implications; normally the silver lining can be represented in some way. Thinking of change as a “complex sale” that has to be chipped away at for success is a first starting point to implementing change. How you communicate that change, whether verbally or written, can also define and determine the ultimate success of adoption. Thinking through the perspective of the user by using empathy can also help your project succeed. If you understand and acknowledge the insecurities of those you are supporting with the new technology, it may make it easier to communicate with them and get them on board.

References

Yongchuan, B. 2009. Organizational resistance to performance-enhancing technological innovations: a motivation-threat-ability framework. Journal of Business & Industrial Marketing. 24(2): 119-130.

Bartoli, A., Hemel, P. 2004. Managing change and innovation in IT implementation. Journal of Manufacturing Technology Management. 15(5): 416-425.

Durney, C.P., Donnelly, R.G. 2015. Managing the effects of rapid technological change on complex information technology projects. Journal of the Knowledge Economy. 6(4): 641-664.

Garvin, D.A. 1993. Building a learning organization. Harvard Business Review. 71(4):78-91.

Jick, T.D. 1993. Managing change: case and concept. Columbus (OH): The McGraw-Hill Companies.

Reardon, R.F. 2010. The impact of learning culture on worker response to new technology. Journal of Workplace Learning. 22(4): 201-211.

Sacks, R.M. 2011. Fear and survival. Publishing Executive. 26(2):50.

Song, F.W. 2003. Being left behind: the discourse of fear in technological change. Hedgehog Review. 5(3): 26-42.

Thomas, K.W, Kilmann, R.H. 1974. The Thomas-Kilmann conflict mode instrument. Tuxedo (NY): XICOM, Inc.

Thull, J. 2010. Mastering the complex sale: how to compete and win when the stakes are high. 2nd Ed. Hoboken (NJ): John Wiley & Sons.

Acknowledgements

Thanks to Dean Yaukey of Phantom Entertainment for the helpful tips regarding communication brevity and emotional language when writing emails. Thanks to Carolyn Thomas, former Library Director at Sierra Madre Public Library for her tips about providing facts and resolutions in conflict situations.

About the Author

Suzanna Conrad is Associate Dean for Digital Technologies and Resource Management in the University Library at California State University, Sacramento. Her research interests include human-computer interaction, scholarly communication and ethics in librarianship.