“On Managing” column #3, 2003 for
LA&M
By John Lubans

Teams in Libraries

Why do some teams succeed? Why do many teams muddle along?

I’ve worked with lots of with library teams  – special project teams, self-managing teams and departmental teams. My roles have varied, from team member to team leader, to external coach/supervisor. Some teams did well, others did not. Why was that? Was it personality, happenstance, chemistry, or luck? Or, none of the above?  

On the successful side of the ledger, some of my technical services work teams overcame a history of failed streamlining attempts. As often happens, the impediment to improvement was a self–imposed one. The way (the rules and procedures) in which we did our technical work had become more important, for this library, than the outcome. The result was a mountainous backlog and a glacial workflow. And, I was told repeatedly that the only way out was more: more people, more storage and more equipment.

When means become ascendant to goals, more is never the answer. With the firm imposition of measurable goals, a deadline, and assignment of decision making to sub-teams, the teams began to excel, finding ways to economize and move resources to achieve the previously unattainable.  These teams, compared to similar groups at other libraries, went rapidly from last to first in their field – to the great benefit of that library’s users.

Other teams I’ve been a part of never moved beyond the mediocre. Often, our goals were unclear or absent, more static than compelling. Those teams meandered. There was a lack of agreement and resistance among team members to consider ways to improve.  At times, it was a case of, “If it ain’t broke, don’t fix it.”  More often, because of confused purposes, the effort expended was of the “Good enough for government work” variety.

Besides these personal experiences, I’ve been influenced by teams outside of libraries. I still draw inspiration about team potential from a women’s basketball team, a team that was not expected to do well – yet went on to achieve its “impossible” goal. How did they do that?1

Another exemplary team is the self managing Orpheus Chamber Orchestra. Playing without a conductor is the least of their accomplishments – what sets them apart is their music (the team’s outcome) with its unparalleled unanimity of sound. Now in their 30th year, what enables this team to stand out, head and shoulders, above other musical groups?2

Before we talk about the key elements for effective teams, let’s make clear the differences between committees and teams.

Most committees are deliberately representative.

Despite the naivete of administrators like me who want everyone to consider the greater good, focus on the big picture and just get along, committees do what they are designed to do: represent their turf and maintain the status quo as they see it through their departmental eyes.  They work best in exploring issues and presenting the “what ifs” to the library’s leadership - for action, one hopes.  If led by a strong leader, committees can do well.

These are the fundamental differences between teams and  committees:

Expecting a collaborative solution from a committee is like asking a pack of wolves to share its food with you.  If you appoint, like I once did, a committee to merge two departments, the outcome is predictable: It won’t happen. Long lists of questions and concerns will happen, lots of meetings will happen, lots of paper will happen but the job needing to get done will not.

With a bit of imagination, the above contrasts can be used to explain why most departments behave like committees and why pseudo-teams behave like committees or departments.

These are the must have elements (see sidebar) for effective teams.3  Invariably, when a team displays these attributes, they excel. Teams that ignore these aspects may get lucky and succeed (a few of mine went that way), but most fail or perform at minimal levels.

Sidebar:

Elements of Successful Teams:

Purpose/mission
Team member roles
Real work
The how
Deadlines
Support
Accountable
Interdependent

End sidebar

I will explore a few elements more than others. The ones stressed are the pieces that made the most difference, in my experience, for a team’s success.

The team’s purpose/mission is clear and understood by each team member. For me, a team’s success depends on its achieving the performance goals explicit in its purpose and mission. Performance goals are measurable. They have substance and they are achieved in a timely way. In other words, something the team “touches” literally is changed for the better. The goal, if clear and compelling, pulls a team forward; it draws the team toward figuring out the best way to achieve the goal.

 “Improved communication”, “collaboration” and the team’s gaining a “strong sense of responsibility” are not goals. While these are desirable outcomes of teamwork (indeed they are essential to how a team works), they are not the team’s purpose/mission nor its real work.

Worse, exhortations like “improving customer service”, “re-engineering reference”, or, “enhancing the user experience” are all but meaningless as goals – anemic words rubbed pale on the page and faintly heard, summoning no one.

For me, a team’s purpose always has to make a difference. A team’s getting from point A to point B means it has achieved something, it has climbed further up the mountain, it has made measurable improvements. Without clarity of purpose, there is little reason to re-organize into teams or any other configuration. Your present arrangement will do.

Team member roles are explicit, agreed upon, and understood. All group members have a variety of roles, often ones that may change while getting the job done. There are formal and informal roles. Formal applies to the level of expertise and training you bring to a work team and the informal is your role in keeping the team running smoothly. 

All team members work an equal amount doing real work. 

Members pay attention to the how of working together. How will we make decisions? How will we work through problems? How will we give each other feedback? How much risk will we take? These are some of the questions that need answers for trust and team momentum to build.

“Storming” is another way to describe the “how”. The term comes from the Form, Storm, Norm, Perform stages of group development  identified by Tuckman back in the mid 60s.4

Tuckman’s alliterative phrase has legs – it is still gospel in group development theory. Not all groups storm the same way each time, but like my story (see sidebar) illustrates, storming is an unavoidable and unpredictable phase in team development. Library teams tend to avoid the storming phase, preferring to maintain the politeness in the forming stage. Yet, storming is going on – pretending it is not there, does not make it disappear – it simply dives below the surface leaving much unsaid and roiling underneath. Without resolution, a team can get stuck haplessly in “storming”. The result is low trust and low appreciation for other team members – and few positive outcomes. Telling team members to get along, to treat each other nicely is useless unless team members work their way through their differences, their fears, their uncertainty.  Our initial inclination in storming is toward competitive behavior: to assert that my needs are this, my ideas are better than yours.

Sidebar:

Storming – Inevitable and Unpredictable.

I was at a multi day “training the trainer” session. We were 20 strangers split into two teams. The training curriculum was the same and we were usually within sight of each other during the day. We shared meals.

By the end of the first day, I was miserable. I’d alienated all but one of my team mates by not going along with guidelines the majority set up. I disagreed and told them so in strong terms. When my partner and I did our presentation to the group, their feedback was terse and unsupportive. That our presentation was not all that good made it even more humiliating.

Across the way, the other team was always laughing, working together, clearly supportive. I was drawn to that happy team. When I asked the instructors to transfer into the other team, the answer was no. That night I thought about leaving, catching the bus back to the airport.

The dawn, to coin a phrase, brought a new day. Slowly, my team mates and I, with a little help from the instructors, worked at our differences and by the end of Day 2 things were not so grim. I’d explained my views, they’d listened and made a few concessions – things were lightening up. Importantly, my most vehement opponent helped me with one activity – it was done in a spirit of generosity and I responded in kind. We were making good progress.

On Day 3, the other group stopped talking. Now, they were the unhappy campers, sending envious glances our way. There’d been a falling out, cliques formed, and the last hours were spent in conflict.  There was little time to resolve the differences, but with the instructors intervening, progress was made. By the morning of Day 4, with a scheduled noon departure, things had pretty much calmed down.  “Storming” was never featured in the curriculum, but I hope all learned as much as I did about it.

End of sidebar

Storming is the discomfort zone, it is not where we want to be, but it needs to be gotten through to create the essential trust for people to share their ideas, good and bad. You want to achieve the level of trust and respect that I saw demonstrated in an Orpheus Chamber Orchestra rehearsal. A French horn player stopped the orchestra in mid-musical phrase and exclaimed: “This … is not what Mozart wanted!” Laughter ensued, but he made his point and the playing improved.

Deadlines are stated and respected.

Demonstrable support comes from the “top” leadership. The level of support answers team questions about how much creative freedom the team has. Can they question the basic assumption or only improve on the system. Can the sacred cows be corralled or must they be left, unharried, to graze in their pastures? If there are too few dollars for new hardware for branch libraries is  an advisory budget team restricted to certain budgetary zones or can it look for dollars in the entire budget? Teams, obviously, want to know to what extent top leadership will support and protect them.

The team is accountable to the organizational leadership. Effective teams do not set their own agenda – not even self managing teams. Someone in the administration cares, knows about, and influences the work of the team.

The team is interdependent with other teams. It is not insular and willingly offers support to other library teams. It always mystified me when team members proactively helped each other but resisted helping anyone outside the team. Another illustration of failed interdependence is a team’s blaming other teams for library wide problems. This bad mouthing drains trust and gains nothing in the long term. An effective team aware of its interdependency is much more willing to offer constructive criticism face to face  and to chip in with real help.

While it is delusional to think that simply substituting the word team for the word department  will make for effective teams, that is a not an uncommon approach when libraries use teams. For teams to perform well, a library administration has to make extraordinary commitments – in support, training and patience.

In sum, I would hypothesize that a team’s effectiveness can be correlated to the extent that the “Elements of Successful Teams” exist in a team. When fully present, there’s no stopping that team.

 

 Notes:

1. Lubans, J. “Orchestrating Success” in People in Charge: Creating Self-Managing Workplaces by Robert Rehm New Society Pub. 2002.  pp.187-197

2. Lubans, J. “A reason for rain : Hoop Lessons for Library Leaders”, (On Managing column) Library Administration & Management, 13: 39-43 Winter, 2001

3. These clues for a successful team are derived from experience, research and the work of Katzenbach and Smith as it appears in The discipline of teams : a mindbook-workbook for delivering small group performance by Jon R. Katzenbach and Doug K. Smith.  New York: Wiley, 2001.

4.Tuckman B., ‘Developmental Sequences in Small Groups.’ Psychological Bulletin, 63: 384-399, 1965

 

Author’s note:  John Lubans has been known to strum an air guitar. Less privately, his workshop on teamwork in libraries draws on a decade’s worth of real experience with library teams. E-mail: john@lubans.org


http://www.lubans.org