What do staff members think is important within the library to know? Anne Prestamo conducted a study for her dissertation and asked academic reference librarians and other experts the following question: “What are the technology and computer skills required of reference librarians in academic libraries?”¹ The responses she received included knowledge of operating systems, hardware basics and troubleshooting, and software basics and troubleshooting. The import of her study is that she asked the very people doing the work, or managing the work, what they need to know. Her list of competencies, as a result, is quite an accurate snapshot of what academic (and really, all) reference librarians needed to know in 2000. Some things have changed since then, but her list still functions well as a basic primer for academic libraries looking to create a list of technology competencies.

People love to talk. So … let them. Staff members often know best what they need to know to do their jobs. Surprisingly (or perhaps not), they don't all agree on what they need to know for a particular position, but the person doing the job day to day has the most information about what skills are required to do that job successfully. Managers may think they know what each staff member needs to know, and they may have unique contributions to make—particularly in the area of competencies that will move the library forward toward its evolving vision of services—but by and large, staff members know what they need to know.

Set up a three-hour (or more if you can!) brainstorming session at a central location, one that is convenient for as many staff members as possible. Several independent brainstorming sessions are likely to bring about very different lists as well, so you may want to consider holding regional or departmental brainstorming sessions. If you can hold several sessions, consider doing so. Set the dates a good three months in advance to allow for plenty of time to rearrange schedules and find substitutes for desk coverage. Invite everyone. I mean everyone. If every staff member is going to be required to have the competencies, you want people from every position to be there. If you have an all-staff newsletter, publicize the meeting there. If not, post physical flyers in every location. Send out e-mail messages. Do whatever you can to get the word out to as many staff members as possible. Talk with managers in advance and request that they give as many of their employees as they can paid time to attend this event. If there are specific people you think would make valuable contributions, don't hesitate to send individual e-mail messages to them requesting their attendance specially.

Provide plenty of refreshments—snacks and drinks for all dietary restrictions and preferences. Have large markers and large pieces of butcher paper available (those lovely tear-off sheets that fit on easels are perfect), and on these pieces of paper, record what is said. Set up seats in a circle if at all possible (this will lend to the atmosphere of equality and sharing). Provide a fifteen-minute break in the middle of the brainstorming session to allow folks to cool off some heated feelings, re-energize, or simply stretch and socialize with colleagues.

Start the session by reiterating the statement of purpose for the competency descriptions, letting staff members know what the task force has decided about the scope of the competency statements. Tell them also that this is a brainstorming session and should be treated as such. This means that any idea goes, judgments and arguments about specific ideas should not be made at this point, and all contributions are equally valued. From experience, let me tell you that you'll need to re-stress the “no judgments” rule repeatedly during the session. Encourage staff to talk about sample technology competencies—things they feel they need to know to do their jobs successfully—as well as associated concerns or ideas, such as individual comments about having plenty of training or not tying competencies to pay increases. Anything goes.

Have the group brainstorm a list of competencies with no “starting list” given. I have found that if you give staff a list of jumping-off points, sample things to include, they can too easily become focused on what is there already—delving into great detail about what you have listed instead of expanding beyond what you have brought to the table. You may want to encourage staff members to say not only what they need to know for their individual jobs, but also what they believe their coworkers in other positions need to know (sometimes internal staff interactions will have highlighted missing areas of knowledge). After the session, have a task force member transcribe everything into a word-processed document or a spreadsheet, whatever seems to make more sense given the data you've gathered. The task force should discuss these results at a future meeting and take them heavily into consideration during the process of creating competency descriptions.

Developing Competencies Worksheet http://webjunction.org/do/PrinterFriendlyContent?id=1269

WebJunction provides a “Developing Competencies Worksheet” that you could use as a template for the brainstorming process. At the URL indicated in the screened box, you can access this WebJunction tool, which includes printable worksheets asking staff to identify competencies for reference and circulation staff, administrators/directors, technical service staff, volunteers, and even the public; however, I found that this worksheet did not work very well for my purposes, as it does not provide enough space to identify nearly the number of competencies that exist for each staff area (only five spaces each), and staff classifications were broken down differently in the projects I worked on than those that this worksheet listed. But you could use this approach for brainstorming—asking each participant, before the meeting, to compile a written list of technology competencies that he or she can think of for each staff group.

What do managers think their staff members need to know? The task force may want to consider holding a separate brainstorming session for management in which managers can express their opinions about what they feel their employees should know. This becomes complicated as you get into upper management, so the task force may feel the need to individually interview or survey the director, the heads of branches, or other upper-management positions about what they feel middle management should know how to do. For example, the branch managers may feel that they don't need to know what their reference staff members need to know. The director, however, may feel that branch managers should have all the competencies of all the staff positions they supervise, including reference. This may be an opportunity for discussion between the two parties to determine what is expected of branch managers. This is also a good example of how not every decision will be made by the competencies task force. Have the sense to realize when decisions are best left to management and when they are best made by the task force.

Without early involvement of the people affected by the technological changes in the planning process, we set ourselves up for failure. We are talking about more than minimal levels of competencies needed to perform functions; we are talking about attitudes, resistance to change and more.

Carolyn M. Gray, “Technology and the Academic Library Staff or the Resurgence of the Luddites”²

After the brainstorming sessions, the task force members may find they need more information from staff. If you find yourself in this position, or if you are unable to conduct an in-person brainstorming session, consider creating an anonymous survey for staff. Using free online survey tools like SurveyMonkey can allow the task force to quickly gather and analyze data on remaining questions.

The task force might want to target questions at specific positions, for example, asking only circulation workers whether or not they feel they all, at all levels, need to know how to troubleshoot printing from a Web page. One answer for any question like this should be, “I don't know what this means,” allowing staff members who do not understand what you're asking to have a way out—not forcing them to pick yes or no, because if they don't know what it is they'll likely pick no, and a lack of knowledge now doesn't mean they don't need to know it. To get these honest answers, emphasize that choosing “I don't know what this means” will not result in any negative repercussions for the staff member, especially if the survey has been kept anonymous as I recommended. The task force may have more specific questions to ask: “Do all reference librarians at all locations need to know how to unblock the filter on the children's computers, or do just the children's librarians need to know how to do this?” The task force members will know what they need to ask once the members have gone over the results of the brainstorming exercise.

This staff survey may come before or after the task force has created a draft competencies list (or both!), so this step may come slightly out of order.

Nothing will kill a new project—especially one laden with change for staff at all levels—as quickly as a lack of information. Rumors fly, whispering ensues, anger brews … not a positive environment for change. To avoid all of this, the task force needs to make a conscious effort to keep staff members informed at all times about its progress and work. This can be done with a brief summary of each of their meetings, distributed via e-mail, the staff newsletter, staff meetings, or any other method of internal communication the library currently employs. I would not recommend sending out to all staff each draft of the competency descriptions as the record is built. Letting staff know what you are doing, generally speaking, however, will go a long way toward building trust for the group's work and achieving buy-in when the competency descriptions are completed.