by Kelly J. Thompson

Introduction

I am an early-career metadata librarian embedded in a traditional cataloging department in a large academic library. Part of my job is to train the MARC cataloging (and copy-cataloging) staff in my department in non-MARC metadata creation for our digital collections and institutional repository. This staff is most diverse in age ranges and technological ability—I am several decades junior to the majority of my colleagues and the first new hire the department has made in a long time.

Most of the library literature to date which addresses the transition of traditional MARC cataloging librarians and support staff to non-MARC metadata creators focuses on applicable skill sets which can be applied in both types of work, ways to build on those cataloging-specific skills to foster skills in metadata creation, and the types of projects which may be appropriate to assign to these staff, both as they are being trained and as they gradually build up competencies. (Boydston and Leysen 2008; Keenan and Sipe 2013; O’Bryan and Palmer 2007; Rodgers and Sugarman 2012; Veve and Feltner-Reichert 2010) I want to speak to a gap in this literature related to generational diversity: the inter-generational differences in work styles, theoretical understandings, and comfort with technology which manifest in a collegial environment. I will speak to a number of barriers to participation in new metadata projects for age-diverse staff, and identify a few strategies that have worked to build inclusivity in my experience managing these projects. I write from the perspective of a new metadata librarian without formal supervisory responsibilities, who is also engaged in the process of acclimating to a very traditional library environment.

I will share some of the communication, training, and project management strategies I have utilized while leading metadata projects that have eased some of the tensions experienced in this process. From technology anxiety (What if I break it? What if I accidentally delete everything?) to sitting with uncertainty (Is there a rule I can read about how to format this title?) and navigating spreadsheet basics, I will talk about some of the on-the-ground challenges and opportunities which exist for the new metadata professional tasked with midwifing the training of a multi-generational cataloging staff with a diverse array of comfort and familiarity with technology in general. I am strongly convinced that what has made our projects successful are mutual reciprocity, active listening, and frequent and open communication. I will talk about ways we can build co-working communities to foster growth beyond barriers to participation in projects that require some members to develop new technology skills with assistance from others.

Strategies Used to Bridge Diverse Generations/Classifications of Staff

Communication, documentation, and checking your own assumptions

In my work as a metadata project manager, I have observed a number of indicators which alerted me to gaps in my understanding of what I was communicating and what was being understood by project staff. Invisible gaps in expertise and shared language can easily lead to frustration and tension. As a new librarian, I had a lot of assumptions about what I knew, and a different set of assumptions about what I thought my coworkers knew. The fact that I was coming into the department as a new person who was supposed to guide them in doing new work was anxiety-provoking for all parties. I observed anxieties among some of the more senior staff in my department regarding their lack of the newest skill sets, or their understanding of what those skill sets were. I dealt with this by increasing the amount of communication in every area of work possible. I continue to ask a lot of questions and strive to practice active listening. It is important for anyone creating new workflows to inquire about procedures already in place, how similar types of work have been done in the past, and how new initiatives may impact other workflows in the organization. If there is existing documentation available about workflows, this is a good place to start, but often you may need to create this documentation as you do your homework. I find it important to consult with my department head before implementing any major steps forward, so that we can go over the plan I’ve developed and the proof of concept. She will often share insight about how a similar situation might be handled in a traditional MARC cataloging situation, which I believe improves our metadata quality measures and makes our non-MARC metadata more interoperable with our MARC catalog data once in a discovery system. I like to discuss any preliminary plans or roadblocks I encounter with my colleagues, as they will often have insight about a way to improve the process, or refer me to another person in the library who has relevant expertise or has done something similar in the past. Because I am curious about the work that my organization is already doing, it is easier for those I am training to develop an interest in what I am asking them to do. It has helped that I was brand new to traditional MARC cataloging when I arrived in the department, as this provided a mutual reciprocity in knowledge transfer that bridged some of these tensions. On a regular basis I will ask my senior cataloging colleagues questions about complex original cataloging, and they will ask me questions about non-MARC metadata they are working on for a digital collection. By recognizing that everyone is bringing some kind of expertise to the table and asking for help when you need it, you set a tone of equality from the get-go.

One challenge of working with staff at different classifications (we have unionized merit staff, professional and scientific staff, and librarians at either faculty or professional and scientific rank) is that non-professional staff sometimes have completely different understandings of the department’s work. Often the same level of communication is not present from administration to non-professional staff as it is to professional staff or librarians. Different types of staff have different amounts of specialized education as well – for example, typically the professional librarians in our organization have completed an MLIS degree, and thus have a background in library theory and a shared vocabulary that accompanies that experience. These differences often lead to non-professional staff being less likely to go about their day with the big-picture view of a problem or project in mind, as they are responsible primarily for on-the-ground details. One strategy to bridge this is to clearly communicate what the project goals and objectives are, providing context for the work within the library enterprise, and to explain why you are doing this project (Who will this benefit?). I have found that it is helpful to succinctly and non-technically share what all of the necessary steps to a project are, even if staff will not be participating, so that all staff have an awareness of the whole workflow. This makes it easier if there is a snafu in one part of the production workflow that impacts other steps down the line. People find it easier to be flexible in their timelines and work if they understand the driving forces causing disturbances to the routine.

It was difficult for me to develop a sense for how much and at what points I needed to be communicating with project staff. The answer to this is usually more often than you think, and I find that I tend to assume people have more understanding of what I want them to do than they actually do. By communicating the big-picture process as clearly as possible, and clearly stating your expectations at each step of the process, you can help project participants both move their skills forward and learn more about the new work you are asking them to do. We communicate in-person and via email, one-on-one and in group meetings, depending on what needs to be communicated, decided, or taught. I have found that I need to document nearly everything. Whether this is a data dictionary for a digital project with examples given for each field value, or a simple procedures document for navigating a document in the ContentDM Project Client, everyone is more comfortable when all staff have a common starting point and clear guidelines with step-by-step references they can return to later on their own. It sounds simple, but I received feedback from one of the catalogers that even simply numbering the steps in a written procedure makes it easier to check in with colleagues when questions arise.

Regardless of how good [you think] your documentation is, as a project manager, staff will still be coming to you with questions, with the expectation that you will have answers. In surveying traditional cataloging staff, Veve and Feltner-Reichert found that 68% of non-MLS catalogers they surveyed said that they will seek assistance first by approaching someone at their institution to answer questions or for other assistance. While 43% of MLS catalogers in their study reported that they would first try to figure out the answers themselves, asking someone at their institution was still the first choice for 31% of the MLS catalogers. (Veve and Feltner-Reichert 2010) This data reassures me that I am most likely not the only metadata librarian who has ever felt flooded with questions from trainees.

The deluge of questions was a bit surprising and “imposter syndrome”-provoking for me at first, but I’ve found a few strategies which helped me become more comfortable with this situation. First, don’t be afraid to admit when you don’t know the answer to a question, to explain where you’ll find this information, and to ask people if you can do some digging and get back to them in a timely manner. By demonstrating that you will follow up and that you are not the sole source of these answers, you can help your staff become more comfortable themselves with not knowing, which can make question-asking less stressful. I also tend to show people how I found the answers to their questions if I sense that they will be open to this. In addition, workflows aren’t always going to function as well as you imagined them. I’ve found that I need to change or update some part of my carefully produced procedures and documentation in almost every project as staff find and report problems. Own your mistakes! Honesty may feel like displaying a weakness, but ideally it will build trust and a culture which supports well-researched risks and innovation.

Good documentation not only makes your life easier today, but it is also good succession planning. By setting clear parameters for the work and documenting much of the project planning, teams have a shared understanding and a good starting point for training. Good documentation makes it is easier to return to the project or replicate it after time away. It enables others to replicate the process, understand the context of the metadata, and add more items to an existing collection while ensuring consistency.

Organizational culture

My department’s organizational culture was one area where I needed to bridge some gaps in understanding while implementing some of the newer technology-rich projects I’ve worked on. I am on a number of cross-functional teams at my institution and am frequently outside of my cubicle at meetings or co-working with collaborators in other departments. For technical services departments such as mine, where the number of support staff is much greater than the number of librarians, and where support staff are a bit more rooted to their desks during the day, this was a strange transition for everyone. This was especially hard for staff in the department who would prefer to stop by for a quick chat instead of sending an email when they run into a problem with metadata work they’ve been assigned. Even though my calendar was always up-to-date in our enterprise email/scheduling software, most people did not know how to effectively use this tool. At my department head’s suggestion, I began posting a copy of my weekly schedule outside my office door. This made it less frustrating for staff to know when they could find me in person, or to know that I was in a meeting and was simply delayed in answering their email until I was back to my office. By knowing that I was working somewhere else and not just absent, this created more camaraderie between myself and staff who do not have as hectic of a meeting schedule. As we’ve been engaged in library-wide strategic planning efforts recently, more staff have experienced what it is like to have more meeting commitments, which has also built empathy in my department for differences in schedules. By communicating and demonstrating new modes of work, we’ve been able to come to more mutual understandings of what a 21^st century library’s work can look like.

Strategies Used to Avoid Barriers to Participation

Organizational culture, continued…

A major barrier to the catalogers participating in this new work in my institution was the long-standing internal perceptions that our digital team had about catalogers. “People think of us as dinosaurs,” one of the catalogers said to me during my first weeks on the job. Part of my work was to be an ambassador for the cataloging staff when I went out to meet with other groups in the library to provide metadata expertise and report on projects. I strive to give credit to the cataloger librarians and staff contributing to the metadata work these groups are asking for, and I make sure to give updates on the training and “next steps” I see the catalogers make. I try to emphasize the substantial amounts of theory that these professionals carry, and that while they may not be technologically adept, they are certainly adaptable. For example, by sharing that one of our monographs catalogers had recently independently completed metadata (including customizing a controlled vocabulary) for a new digital collection and was now going to complete the documentation for the project on her own for the first time, some members of the digital team expressed surprise that catalogers were trainable in this area. To anyone who has been a cataloger, you understand how ridiculous this sentiment is, but it continues to be a real, prevailing bias that I encountered among several people in our library, and I share it simply to encourage those working with traditional technical services staff to speak up about the good work people are learning to do. By genuinely acknowledging their hard-earned growth and hard work, you boost morale and excitement among your trainees as well. I also make it a point to suggest that colleagues in my library who are working on digital projects contact cataloging librarians who I know have expertise in areas they are struggling with, such as metadata for library-published journals (serials) in our institutional repository. Technical services librarian Christine DeZelar-Tiedman writes, “Do not assume that your more “seasoned” staff cannot get involved in digital projects or would not be interested. Invite everyone to the table. Experienced librarians have seen radical changes over the years and are used to changing along with them.” (DeZelar-Tiedman 2004) It is vital to select tasks of appropriate scope and complexity for beginning metadata creators. You may have to start with what seems to you like the ground floor, but consider it an investment in the sustainability of your metadata program long-term, as well as the sustainability of your own time.

Scaffold on skill sets

Most of the library literature focusing on what skill sets catalogers can bring to the metadata table imply that metadata creation is such a natural fit for these groups, they tend to gloss over the sticky practical implementation snafus inevitably present. While catalogers bring skills, expertise, and loads of relevant theory, they still need training and lack many of the technology skills that newly minted librarians may take for granted. (Boydston and Leysen 2008) For example, even though catalogers are trained to intuitively understand data models and the need for standardized element schemas, many of them have not been trained to read, produce, or navigate XML, which is how most of the widely adopted schema standards have been documented and serialized. By acknowledging these differences, we can begin to identify where to begin training. In library technology culture, I perceive that there is often an assumption that people should be able to teach themselves anything, to pick up new technologies on their own. I think this is often not the case for many library staff because they do not have a number of ‘preliteracies’ required to begin thinking about library data like metadata librarians or digital library developers.  Before elementary school students can learn to read, they need to develop an understanding of how to hold a book, that letters are put together to form words, and that words represent meanings – these skills are referred to as preliteracies.  (Stahl et al. 1990) There are a number of preliteracies which technical services staff need to develop before they can gain metadata literacies. Background knowledge in how to read and write mark-up languages, and understanding how resource discovery works, how databases work, and the ways that data can exist in aggregate (and outside of one individual record) are some pieces of this. Preliteracies for metadata training are an area of study warranting further research.

I agree with DeZelar-Tiedman’s suggestion that “Perhaps the best way to get involved is incrementally. Not slowly or timidly, but in manageable steps.” (DeZelar-Tiedman 2004) I consider participation in projects to be the biggest source of training we do in my department. It is critically important to select appropriate projects and tasks for beginners, and build up progressively more complex skills from there. For example, we’ve included a number of staff in the metadata creation for retrospectively digitized theses and dissertations to be loaded into our institutional repository. This work includes assigning standardized department headings from a local controlled vocabulary managed in complex spreadsheets. Although the staff have experience working with controlled vocabularies in MARC records, they had very little experience with metadata in Excel spreadsheets in general, a competency I took for granted. The staff had widely varying levels of comfort with spreadsheets. As one of them said, “There is a big difference between typing in a basic Word document versus formatting tables!” By participating in this project, these staff have all developed basic to intermediate Excel skills. I have also been able to begin to identify the individual talents and aptitudes that these staff bring to the department, which will help in deciding who to assign future metadata work to, observing who staff go to as peer mentors, and understanding who is most ready to develop more complex skills which go far beyond spreadsheet work. By starting with spreadsheets, we kept the work at a manageable scale, and we also avoided the need to train the staff to navigate the sometimes complex content management system we use until they have developed some more metadata preliteracies.

Technology anxiety

From the beginning, the catalogers I work with exhibited a fair amount of technology anxiety. This manifests in questions such as, “What if I break it?” or “What if I accidentally delete everything?” This fear is a barrier to learning, because in order to learn a new skill, you need the freedom to experiment and make mistakes with a safety net. We worked around these fears (and potential real issues) by discussing the larger scale systems-view of the work we were doing. By explaining that they were each granted specific permissions in software such as the ContentDM Project Client which did not allow them to delete all of the data, or by explaining that if a program froze up it was not their fault but a system bug, they felt freer to navigate and explore on their own. We work on a lot of spreadsheets, so I keep back-ups of any files that they are working on. Because of this, I was able to demonstrate when one of them accidentally deleted a column of URLs that it was easy to restore that information. You can also think strategically about how to provide low-risk access to shared files necessary for their work, for example, placing read-only permissions on the folders with digital objects in them to be described, or putting files on a server so they can be accessed through the web. By keeping versioned back-ups of all important documents, files or datasets, you can sooth some of the “What if I accidentally delete everything” anxiety for all parties, and free people up to concentrate on the actual intellectual work required of the metadata description process. It is nice to separate the training aspects of metadata content creation from that of software navigation, although this is not always possible.

Technology anxiety can also be due to unfamiliarity with the vocabulary being used. I think that vocabulary is a huge barrier to participation in technology-rich work in libraries. Technical terms, jargon, and acronyms are present in most library work, and it is a worthwhile investment to learn these from each other, as it pays dividends in the efficiency of your communication and the level of understanding you can build in common. At the beginning, it was great to have people remind me when they had no idea what I was talking about, so I could back up and clear up any confusion before proceeding.

Change anxiety

Not all of the anxieties that are barriers to participation are related to technology. Change anxiety is also often present. People in technical services are especially aware of the fact that the information landscape is moving underneath them, but don’t always have the necessary information to know what to do about it personally.

I have observed that many cataloging staff members have a real discomfort for sitting with uncertainty. I have noticed that this tends to be stronger among those who have worked with monographs, as those who work with serials tend to have an easier time, perhaps because they are accustomed to the constant flow of title changes and irregularities encountered in the work. As technical services librarian Christine DeZelar-Tiedman writes, “There is a codified set of standards and years of tradition behind the way that we operate. Ingrained in at least some of us is a discomfort with chaos and uncertainty. Cataloging is our own way to create control over a small corner of the universe, which can be very satisfying. In contrast, the digital realm is nebulous and constantly changing.” (DeZelar-Tiedman 2004) Cataloging staff have been socialized over decades to refer to the relatively small handful of standards used in traditional cataloging, including MARC, LC headings, AACR2, and now RDA. All of these standards are meticulously documented and detailed, and are thoroughly rule-based to avoid as much ambiguity as possible. A metadata project manager should not be surprised when presenting catalogers with a data dictionary with few content rules explicitly stated, to receive a follow-up email asking, “Is there a rule I can read about how to format this title?” One of the training exercises we have done in my department is a comparative standards reading, where we looked at content standards for titles in AACR2, RDA, DACS, and DCRM-G. By taking a look at standards from different kinds of cultural heritage institutions and discussing what we liked and disliked about each, we were able to agree on a local policy that worked for us and our users’ needs. I also remedied this by providing example values in all data dictionaries, as well as going through a few practice records together as a group during our training sessions. During projects, I send out regular FAQ emails (the frequency depends on the pace of the project — and number of questions!) recapping all of the questions I’ve gotten since the last update which may be of value to others beyond the original question-asker and which don’t “out” the question-asker.

Reinventing the wheel is not the best use of your time

One of the barriers that I personally had to overcome was that I had very little experience with teaching, project management, or training before stepping into my current position. For me, it was important to learn about each of these in order to help our projects stay organized and run smoothly. Before setting out to reinvent any of these essential skill sets solely through my own experience, I sought out information in the library literature as well as education, agile development, and project management literature. I also partook of services on my university’s campus to assist new professionals in developing these skills.

I experimented with some existing workflow management tools (including Trello, which we use to track in-process Digital Team projects as the work progresses through various library departments), and I’ve developed my own spreadsheet-based workflow tracking tools for individual projects. For individual projects, it is essential to have good file identification systems. To avoid confusion for the cataloging staff, I “assign” each project participant a folder on our shared network drive, where I put spreadsheets or other documents for them to work on. This space also serves as a repository for their own copies of project documentation, so they may edit or notate as needed. By relieving them of having to navigate through dispersed file hierarchies and needing to know the file IDs they were responsible for, we were able to create a much friendlier workflow. I am always able to know who is working on a particular file or who completed which work by referring back to my managing spreadsheet. This is also useful as staff email me questions, because I can use this system to quickly know which batch of data they are referring to.

Many campuses have dedicated staff and centers for helping staff and faculty develop their pedagogical skills. I participated in several workshops through our campus’s Center for Excellence in Learning and Teaching, including a teaching and learning circle which aimed to help participants develop methods for incorporating critical thinking into their pedagogy. This group helped me to begin developing training activities which incorporate active learning, reflection, and problem-solving. I look at example documents from instructional designers at my institution to draw inspiration for my documentation and training handouts. I try to consider a diversity of learning styles and incorporate active learning into our training sessions by having demonstrations, software “tours,” and group practice activities. I’ve also learned from our training sessions that when doing small group instruction with new software, it is nice to have a “helper” in the room. This person can assist those who get behind or need help finding a button so you don’t have to be in all places at once. This can help you to avoid leaving anyone behind during training sessions.

I think it will help overall project management stress to remember that learning is really inefficient and that planning how you are going to use work time also requires an investment of time. By budgeting time for this in your planning, you can save a lot of stress during the project implementation stages. It was hard for me at first to accept that I needed to train my colleagues to take on this new work when it felt like it took three times as long to train them as it would for me to just do the work myself. To move past these thoughts, I needed to think of the long-term sustainability of my time, and to think of these initial projects as investments of time. Each subsequent project has required less start-up time and generally become easier for everyone involved, and I’m now moving toward including certain staff in more complex projects (such as developing local metadata application profiles from scratch, following Shawn Averkamp’s Metadata Design and Development course project model). (Averkamp 2013) I try to see that with each project, everyone gets a manageable amount of new challenges or experiences. I’m now also trying to incorporate evaluation at the end of each project, so that we can share feedback with each other on how the project went, and incorporate that into the next phase of our work. It is important to budget time for assessment as it is always possible to improve communication or documentation, or the ways that you demonstrate the value of the team’s work in a new way or to a new audience.

Achieve common goals with a diverse group

I have found that by feeling included and listened to, people are more motivated to do the hard work of learning and trying new things. In my institution, metadata was still just a buzzword when I arrived. For technical services staff who have long been overlooked when the library is considering doing something new, it feels energizing to be included in something new, mysterious, and exciting, and this has been a great help in generating the energy necessary to overcome the many barriers and gaps we’ve needed to bridge.

Another way to generate energy for this work is to orient your project people to the big-picture goal of the project work. Communication about the library’s broader mission and goals aren’t always emphasized in the same way for support staff, who often don’t have access to the same meetings or emails where these are reiterated. By sharing understanding of the “why” of the work they are doing, as well as the “who” it will benefit, you can help people choose to align themselves with common goals of a diverse group.

Conclusion

I think that by intentionally including efforts to be inclusive in staff training, we can increase the diversity of participants in technology-rich library work. An important step in this process is acknowledging barriers to participation faced by diverse work groups, and identifying solutions for moving past those barriers. It is equally important to acknowledge that it takes extra effort and communication to successfully bridge the perspectives and experiences of a diverse work group. I would love to hear more about the processes that others have used to incorporate “traditional” library staff in their technology-rich workflows, as well as what the best practices for on-boarding processes look like for new hires in emerging or innovative positions. I hope that by sharing my experiences, we can start a conversation around the human resources that drive our development as a community.

The author sincerely thanks Joan Leysen for her valuable insight related to the topics in this paper. She also wishes to thank Lori Kappmeyer and the entire staff of the Metadata and Cataloging Department at Iowa State University for their patience and understanding while she learned how to train staff and manage projects on the job.

References

Averkamp, S. 2013. Course Project. Course materials for SLIS 021:239 Topics: Conceptual Structures/Systems: Metadata Design and Development. Available from: https://github.com/saverkamp/metadata-design

Boydston JMK, Leysen JM. 2006. Observations on the catalogers’ role in descriptive metadata creation in academic libraries. Cataloging & Classification Quarterly 43(2):2-17. DOI: 10.1300\J104v43n02_02 (COinS)

DeZelar-Tiedman C. 2004. Crashing the party: catalogers as digital librarians. OCLC Systems & Services: International Digital Library Perspectives 20(4):145-147. Available from: http://dx.doi.org/10.1108/10650750410564600

Keenan T, Sipe V. 2013. Transitioning from cataloging to creating metadata. ALCTS Webinar presented February 27, 2013. Available from: http://www.ala.org/alcts/confevents/upcoming/webinar/022713

O’Bryan A, Palmer KL. 2007. The evolving cataloging department. IDeA: IUPUI’s Digital Archive. Available from: http://hdl.handle.net/1805/705

Rodgers JR, Sugarman T. 2012. Library technical services: key ingredients in the recipe for a successful institutional repository. The Serials Librarian 65:80-86. DOI: 10.1080/0361526X.2013.800632 (COinS)

Stahl SA, Osborn J, Lehr F. 1990. “Beginning to read: thinking and learning about print” by Marilyn Jager Adams: a summary. Urbana-Champaign (IL): Center for the Study of Reading, The Reading Research and Education Center, University of Illinois at Urbana-Champaign. (COinS)

Valentino L. 2010. Integrating metadata creation into catalog workflow. Cataloging & Classification Quarterly 48(6-7):541-550. DOI: 10.1080/01639374.2010.496304 (COinS)

Veve M, Feltner-Reichert M. 2010. Integrating non-MARC metadata duties into the workflow of traditional catalogers: a survey of trends and perceptions among catalogers in four discussion lists. Technical Services Quarterly 27(2):194-213. DOI: 10.1080/07317130903585477 (COinS)

About the Author

Kelly Thompson is the Metadata Management and Cataloging Librarian at Iowa State University Library. Her duties include managing metadata projects, wrangling descriptive metadata for ISU’s digital repository and digital collections, and cataloging scientific, agricultural, and technical resources. She enjoys thinking critically about discoverability, metadata for open access/library-published resources, gender, and critical thinking pedagogy.