Leading a large group
The other day someone asked me about how we here at Notre Dame managed a team of 28+ members in regards to our one-year institutional digital repository pilot project (www.library.nd.edu/idr). I did my best to address their questions, and I thought I would copy my reply below. It might prove useful in your setting. (Then again, it might not.)
> I wonder if I might ask you a question or two about > your Team IDR, please? One of the first things on my > to do list is to create an implementation team, and > I'm finding that huge numbers of people should > ideally be included one way or the other. Your full > team was a large one (appendix A). Do you have any > sage advice on how to coordinate such a large team? > Did you have a smaller, core working team? Any advice > you might have would be much appreciated.
In many ways I am proud about the work we did here in the Libraries regarding our one-year institutional pilot project, and the size of Team IDR is one of those things. Thank you for asking, and I do not have sage advice, just reflections on experience.
- As the project was initiated I thought about the types of skills that would be required of the project, and I boiled them down to at least three: 1) people/communication skills, 2) computer/technical skills, and 3) metadata/cataloging skills. I then realized that each of these skill sets existed in our division of 50-some people.
- I actively recruited people by first drawing up a flyer outlining the broadest objectives of the project. The flyer was less than half a sheet of paper long. I went around to everybody in the division, gave them the flyer, told them I sincerely thought they would have something to offer, and asked them to volunteer. After it was all said and done I had recruited about seventeen people.
- There were meetings, but not very many of them, about one every three months. At the first meeting I outlined the broadest of objectives, again, and reiterated that I believed everybody had something to offer. I then outlined a number of group guidelines. These were expected norms of behavior: 1) everybody will keep their electronic calendar up-to-date, 2) we will try to make decisions based on consensus, and if that doesn't work I will make a decision in consultation with my boss, 3) we all do all the work but not necessarily all the time, meaning nobody can be too snobby to say, "I don't do data-entry", and 4) people are expected to finish their tasks on time, and if they can't then they are supposed to give fair warning accordingly and more time will be allotted. These rules seemed to to work very well.
- I divided the project into smaller tasks like: establishing relationships with content providers, learning and installing software, learning about and implementing metadata standards, doing data-entry, etc. I then asked for volunteers to investigate these tasks and most importantly asked them how much time they thought would be necessary to complete them. Time was then allocated and they went off to do their work. My role was to articulate the what of the job, and I took a back seat when it came to the how. I let the sub-groups decide the how's.
- About one third through the project we had a party — a social event — allowing us to mix and mingle. Specifically, I cooked grilled cheese sandwiches for everybody while everybody else brought drinks, chips, paper product, etc.
- As the project progressed and about once every three weeks I got one person from outside the division express an interest in joining the project. I gave them the spiel about the norms, asked them what they wanted to do, and they became a member. Consequently, over time, the group grew to about twenty-eight people.
- As far as the people outside the library go, they were recruited as content providers. Two or three meetings were held with them in small groups. I kept them in the loop, and they passively participated. In the end we had touch about fifty people outside the libraries.
- Towards the end we hosted another grilled cheese sandwich lunch and asked everybody involved to join. About thirty showed up. This event drew closure to the process.
If I were to do this again, then I would not change very much about the process, and I would recommend a few things:
- As leader outline the what, not the how - Let the "people doing the work" decide the how. Trust their judgement. That is what they were hired to do.
- Sponsor a social event so people can get to know each other, interact in a non-work setting, and to celebrate your successes.
- Set clear expectation regarding group behavior - Attend meetings on time. Respect each other's skills and opinions. Keep your calendar up to date. Etc.
- Give positive feedback - When somebody does something well, let them know it in a public or private setting, whichever they feel most comfortable.
- Understand that everybody has skills to offer - Catalogers. Clerks. Computer types. Graphic designers. Reference librarians. Bibliographers. Etc. While you might not have all the skills you need, figure out ways to exploit the one's you do have. Understand that the people working on the group have more things in common than they do differences. Focus on these similarities.
- As leader one of your primary jobs is to facilitate communication - Use many mediums. Email. Paper. Open forums. Small meetings. Big meetings. Demonstrations. One-on-one coffee sessions. The leader is the "glue" and/or the "electrical conductor" of the process. Communication is not efficient. The message needs to be communicated many times and in many ways. People will not get it the first time. They will need to be reminded and given time to think before they can respond. It is really hard to communicate too much.
- Finally, and just about most importantly, set reasonable time schedules and do your very best to stick with them - If you know your project is only a year long, then figure out what you can do in that amount of time and try like heck to stick with it. Put another way, define what success looks like at the beginning of the process, divide the process into smaller tasks, and try really hard not to change course in mid-stream. When additional priorities present themselves (and they always do), go to your boss and say, "Hey, you told me to do this, and now you are telling me to do that. Make up my mind!"
Creator: Eric Lease Morgan <firstname.lastname@example.org>
Source: This was originally a blog posting on the LITA blog at http://litablog.org/2007/03/16/leading-a-large-group/.
Date created: 2007-03-16
Date updated: 2007-12-28