When I first moved from being a technical consultant to a manager of other consultants, I took a 5-day course Managing Technical Teams – a bootstrap for managing people within organisations, but with a particular focus on technical people. We do have some particular quirks, after all…
Two elements of that course keep coming to mind when doing Debian work, and they both relate to how teams fit together and get stuff done.
Tuckman’s four stages model
In the mid-1960s Bruce W. Tuckman developed a four-stage descriptive model of the stages a project team goes through in its lifetime. They are:
- Forming: the team comes together and its members are typically motivated and excited, but they often also feel anxiety or uncertainty about how the team will operate and their place within it.
- Storming: initial enthusiasm can give way to frustration or disagreement about goals, roles, expectations and responsibilities. Team members are establishing trust, power and status. This is the most critical stage.
- Norming: team members take responsibility and share a common goal. They tolerate the whims and fancies of others, sometimes at the expense of conflict and sharing controversial ideas.
- Performing: team members are confident, motivated and knowledgeable. They work towards the team’s common goal. The team is high-achieving.
“Resolved disagreements and personality clashes result in greater intimacy, and a spirit of co-operation emerges.”
Teams need to understand these stages because a team can regress to earlier stages when its composition or goals change. A new member, the departure of an existing member, changes in supervisor or leadership style can all lead a team to regress to the storming stage and fail to perform for a time.
When you see a team member say this, as I observed in an IRC channel recently, you know the team is performing:
“nice teamwork these busy days”Seen on IRC in the channel of a performing team
Tuckman’s model describes a team’s performance overall, but how can team members establish what they can contribute and how can they go doing so confidently and effectively?
Belbin’s Team Roles
“The types of behaviour in which people engage are infinite. But the range of useful behaviours, which make an effective contribution to team performance, is finite. These behaviours are grouped into a set number of related clusters, to which the term ‘Team Role’ is applied.”Belbin, R M. Team Roles at Work. Oxford: Butterworth-Heinemann, 2010
Dr Meredith Belbin’s thesis, based on nearly ten years research during the 1970s and 1980s, is that each team has a number of roles which need to be filled at various times, but they’re not innate characteristics of the people filling them. People may have attributes which make them more or less suited to each role, and they can consciously take up a role if they recognise its need in the team at a particular time.
Belbin’s nine team roles are:
- Plant (thinking): the ideas generator; solves difficult problems. Associated weaknesses: ignores incidentals; preoccupation
- Resource investigator (people): outgoing; enthusiastic; has lots of contacts – knows someone who might know someone who knows how to solve a problem. Associated weaknessses: over-optimism, enthusiasm wanes quickly
- Co-ordinator (people): mature; confident; identifies talent; clarifies goals and delegates effectively. Associated weaknesses: may be seen as manipulative; offloads own share of work.
- Shaper (action): challenging; dynamic; has drive. Describes what they want and when they want it. Associated weaknesses: prone to provocation; offends others’ feelings.
- Monitor/evaluator (thinking): sees all options, judges accurately. Best given data and options and asked which the team should choose. Associated weaknesses: lacks drive; can be overly critical.
- Teamworker (people): takes care of things behind the scenes; spots a problem and deals with it quietly without fuss. Averts friction. Associated weaknesses: indecisive; avoids confrontation.
- Implementer (action): turns ideas into actions and organises work. Allowable weaknesses: somewhat inflexible; slow to respond to new possibilities.
- Completer finisher (action): searches out errors; polishes and perfects. Despite the name, may never actually consider something “finished”. Associated weaknesses: inclined to worry; reluctant to delegate.
- Specialist (thinking): knows or can acquire a wealth of things on a subject. Associated weaknesses: narrow focus; overwhelmes others with depth of knowledge.
A well-balanced team, Belbin asserts, isn’t comprised of multiples of nine individuals who fit into one of these roles permanently. Rather, it has a number of people who are comfortable to wear some of these hats as the need arises. It’s even useful to use the team roles as language: for example, someone playing a shaper might say “the way we’ve always done this is holding us back”, to which a co-ordinator’s could respond “Steve, Joanna – put on your Plant hats and find some new ideas. Talk to Susan and see if she knows someone who’s tackled this before. Present the options to Nigel and he’ll help evaluate which ones might work for us.”
Teams in Debian
There are all sort of teams in Debian – those which are formally brought into operation by the DPL or the constitution; package maintenance teams; public relations teams; non-technical content teams; special interest teams; and a whole heap of others. Teams can be formal and informal, fleeting or long-lived, two people working together or dozens.
But they all have in common the Tuckman stages of their development and the Belbin team roles they need to fill to flourish. At some stage in their existence, they will all experience new or departing team members and a period of re-forming, norming and storming – perhaps fleetingly, perhaps not. And at some stage they will all need someone to step into a team role, play the part and get the team one step further towards their goals.
Belbin Associates, the company Meredith Belbin established to promote and continue his work, offers a personalised report with guidance about which roles team members show the strongest preferences for, and how to make best use of them in various settings. They’re quick to complete and can also take into account “observers”, i.e. how others see a team member. All my technical staff go through this process blind shortly after they start, so as not to bias their input, and then we discuss the roles and their report in detail as a one-to-one.
There are some teams in Debian for which this process and discussion as a group activity could be invaluable. I have no particular affiliation with Belbin Associates other than having used the reports and the language of team roles for a number of years. If there’s sufficient interest for a BoF session at the next DebConf, I could probably be persuaded to lead it.