Team roles

From CEOpedia
Team roles
See also


Team roles - is the set of patterns of behaviour that members of a team are expected to show, or actually show, while the team does its work. Some roles are formal: they come with a job title, a contract or a project charter. Others are informal and grow out of what people habitually do in meetings, such as proposing ideas, asking for facts, smoothing tension or blocking decisions. Kenneth Benne and Paul Sheats, writing in 1948, described group roles in exactly this functional way, as contributions a member makes to the group's task, to the group's life as a group, or only to the member's own needs[1].

The concept sits between sociology and management practice. Sociologists borrowed the word "role" from the theatre: a part written for the actor, which different actors can play. Managers use the idea more pragmatically. Who decides? Who checks? Who talks to the client? Who keeps the peace when two engineers fall out? A team where nobody owns these questions tends to drift, and a team where three people think they own the same one tends to argue. Role models try to make these questions visible early.

Formal and informal roles

The first distinction worth making is between the role a person is given and the role a person plays.

Formal (task) roles are assigned. They appear in a job description, an organisation chart, a project plan. Typical examples in a project team: project manager, sponsor, analyst, developer, tester, quality controller. A formal role carries rights and duties: the project manager approves the schedule, the tester signs off a test report. It exists independently of the person; when Anna leaves, someone else becomes project manager.

Informal (behavioural) roles are not written down anywhere. Nobody appoints the person who always asks "what are we actually trying to decide?" or the one who cracks a joke when a meeting turns sour. Yet these behaviours shape how the team works far more than the org chart does. An informal leader is the clearest case: someone without formal authority whom others follow anyway.

The two layers rarely match. A senior developer with no management title may act as the team's coordinator and chief critic. The mismatch isn't automatically a problem. It becomes one when the formal role demands a behaviour the person can't or won't supply, and nobody else picks it up.

Role theory basics

Role theory treats an organisation as a set of overlapping roles. Each position (a "focal" role) is surrounded by a role set: the people who hold expectations about how the occupant should behave, such as a boss, colleagues, clients and subordinates. They send those expectations, the occupant receives and interprets them, and the occupant's behaviour feeds back into the next round of expectations.

The classic study is Organizational Stress: Studies in Role Conflict and Ambiguity by Robert Kahn and colleagues, published in 1964 and based on a national survey and intensive case studies in American organisations[2]. Two concepts from that work are still used in almost every discussion of team roles.

Role conflict means that a person receives expectations that cannot all be met at once. Kahn's group distinguished several forms:

  • intra-sender conflict - one person sends incompatible demands ("cut costs, but don't reduce quality");
  • inter-sender conflict - two members of the role set want contradictory things, for instance the client and the line manager;
  • inter-role conflict - two roles held by the same person collide, as when a team member is also a union representative;
  • person-role conflict - the role requires behaviour that clashes with the person's values;
  • role overload - each demand is reasonable on its own, but together they exceed the time available.

Role ambiguity means a lack of clear information about what the role involves: what the person is responsible for, how performance will be judged, where authority ends. New team members feel it most strongly.

In 1970 John Rizzo, Robert House and Sidney Lirtzman developed questionnaire scales for both constructs. Their analysis of responses from managers showed that role conflict and role ambiguity could be identified as two separate and independent factors, and that both tended to be associated with lower satisfaction, higher anxiety and a greater propensity to leave the organisation[3]. Those scales became the standard measurement tool for decades of later research.

For teams the lesson is simple: clear roles reduce stress as well as waste.

Functional roles: Benne and Sheats

The 1948 article "Functional Roles of Group Members" came out of the first National Training Laboratory in Group Development, held in Bethel, Maine, in 1947[1]. Benne and Sheats were dissatisfied with the idea that a group's success depends mainly on its leader. They argued that leadership functions are spread across members, and they sorted the contributions they observed into three classes.

Group task roles (12) help the group select, define and solve its common problem:

  • initiator-contributor
  • information seeker
  • opinion seeker
  • information giver
  • opinion giver
  • elaborator
  • coordinator
  • orienter
  • evaluator-critic
  • energizer
  • procedural technician
  • recorder

Group building and maintenance roles (7) keep the group working as a group:

  • encourager
  • harmonizer
  • compromiser
  • gate-keeper and expediter (keeps channels open, invites quieter members in)
  • standard setter or ego ideal
  • group-observer and commentator
  • follower

Individual roles (8) satisfy the member's own needs rather than the group's, and usually hurt the group:

  • aggressor
  • blocker
  • recognition-seeker
  • self-confessor
  • playboy (modern textbooks often write "playboy/playgirl")
  • dominator
  • help-seeker
  • special interest pleader

That makes 27 roles. The list is old but durable. It describes behaviour, not personality: anybody can be an information seeker today and a harmonizer tomorrow. And it names destructive roles openly, which most later models avoid.

Role preference models

Belbin team roles

The best-known model comes from Meredith Belbin's research on management teams at Henley in the 1970s. Belbin argued that successful teams contain a balance of behavioural roles, originally eight, with Specialist added later to make nine: Plant, Resource Investigator, Co-ordinator, Shaper, Monitor Evaluator, Teamworker, Implementer, Completer Finisher and Specialist. Each role has an allowable weakness that comes with its strength. The model and its questionnaire are described in detail in the articles Belbin team roles and Belbin team role inventory. A broad review of 43 empirical studies by Aritzeta, Swailes and Senior concluded that the model has adequate convergent validity but weak discriminant validity between some scales[4].

Margerison-McCann Team Management Wheel

Charles Margerison and Dick McCann developed a different approach in the 1980s. Their starting point was not team behaviour but work preferences: which kinds of work a person enjoys and does well. In an early article they described how managers' choices fall between "advising" and "organising" roles, with a further preference for "exploring" or "controlling", and proposed a wheel to compare one's preferences with the requirements of the job and the contributions of other team members[5].

The mature version, the Team Management Wheel, shows eight role preferences arranged in a circle:

  • Reporter-Adviser - gathers and passes on information;
  • Creator-Innovator - generates ideas, challenges the existing way of doing things;
  • Explorer-Promoter - searches for opportunities and sells ideas to others;
  • Assessor-Developer - tests whether ideas are practical and turns them into workable plans;
  • Thruster-Organiser - pushes things forward, sets up systems, gets results;
  • Concluder-Producer - delivers output in a regular, efficient way;
  • Controller-Inspector - checks detail, standards and rules;
  • Upholder-Maintainer - supports the team, upholds values and keeps standards stable.

In the centre sits the Linker, a set of coordinating skills that every member needs and the team leader needs most. The questionnaire behind the wheel, the Team Management Profile, scores people on four dimensions of preference: how they relate to others (extroverted vs introverted), how they gather and use information (practical vs creative), how they make decisions (analytical vs based on beliefs) and how they organise themselves (structured vs flexible). The result is a major role preference plus two related ones.

The main difference from Belbin? Margerison and McCann focus on the kind of work, Belbin on the style of behaviour.

Roles in project teams and Scrum

Classic project management defines roles in a hierarchy: sponsor, steering committee, project manager, team leaders, team members. The project manager plans, assigns and controls; specialists execute. Team structure, project team structure and roles of team leader describe these arrangements.

Agile methods changed the picture. The Scrum Guide, in its 2020 edition, deliberately speaks of three accountabilities rather than job titles. "The Scrum Team consists of one Scrum Master, one Product Owner, and Developers", it is typically 10 or fewer people, and "within a Scrum Team, there are no sub-teams or hierarchies"[6].

  • Product Owner - "accountable for maximizing the value of the product resulting from the work of the Scrum Team". Manages the Product Backlog and decides on order of work. One person, not a committee.
  • Scrum Master - "accountable for establishing Scrum as defined in the Scrum Guide" and for the team's effectiveness. Coaches, removes impediments, serves the team and the wider organisation.
  • Developers - "the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint". The word covers programmers, testers, designers, analysts: anyone doing the work.

Notice what's missing. No project manager. The Product Owner decides what, the Developers decide how, the Scrum Master looks after the process. Behavioural roles are not prescribed; a self-managing team must cover them itself. See also agile software development.

Responsibility assignment: RACI

Formal roles become concrete only when they are linked to tasks. The usual tool is the responsibility assignment matrix, often called RACI after its four codes:

  • R - Responsible - does the work;
  • A - Accountable - owns the result and approves it; normally exactly one person per task;
  • C - Consulted - gives input before or during the work (two-way communication);
  • I - Informed - is told about progress or the outcome (one-way communication).

Tasks form the rows, people or roles form the columns. Two quick checks catch most problems: a row with no A means nobody owns the task; a row with several As means ownership is contested. A column full of Rs points to overload, a column with nothing but Is suggests someone who may not need to be on the team. Variants add S (Support) or V (Verify). The article matrix of responsibility covers the technique in more detail.

RACI deals with formal roles only. It says who signs off the test plan, not who calms the room when the test plan is rejected.

Example of a team role coverage matrix

The following example is hypothetical.

A six-person software project team wants to check which behavioural functions are covered. Each member, together with the project manager, marks the functions they perform regularly in team meetings. Eight functions are taken from the Benne and Sheats list: F1 initiating ideas, F2 seeking and giving information, F3 coordinating, F4 evaluating critically, F5 energizing, F6 recording and procedure, F7 encouraging and harmonizing, F8 gate-keeping (bringing quieter members in).

Member (formal role) F1 F2 F3 F4 F5 F6 F7 F8 Functions
Anna (project manager) X X X 3
Ben (senior developer) X X X 3
Chloe (business analyst) X X X 3
Dev (developer) X X 2
Ewa (tester) X X 2
Felix (UX designer) X X X 3
Members covering 3 4 1 3 2 2 0 1 16

The 16 marks spread over 8 functions give an average of 2.0 members per function. The average hides the real picture:

  • Gap - F7, encouraging and harmonizing, has 0 members. Nobody tends to relationships. With a team full of critics (F4 = 3) this is a warning sign: disagreements will surface but nobody is set up to defuse them.
  • Single points of failure - F3 coordinating and F8 gate-keeping each rest on 1 person, and it's the same person, Anna. When she is on holiday, coordination and inclusion both disappear.
  • Overlap - F2 information has 4 members and F1 ideas has 3. Plenty of input, possibly too much talking and too little deciding.

A simple rebalancing plan follows: Chloe, who already sits between business and developers, agrees to take on F7 explicitly; Ewa backs up F3 when Anna is away; Dev drops back from F2 to give Ewa and Chloe more space. After the change F7 = 1, F3 = 2 and F2 = 3, with the total still 16 marks. Not perfect. But the gaps are now known, and that is the point of the exercise.

Advantages of team role models

  • They give the team a shared, neutral vocabulary. "We lack a completer-finisher" is easier to say than "Ben never checks his work".
  • They shift attention from personalities to functions, which helps in planning team development and in staffing new teams.
  • They reveal gaps and overlaps before they show up as missed deadlines or conflicts, as the example above shows.
  • Clear formal roles reduce role ambiguity and role conflict, which role theory links with lower stress and lower turnover intention[3].
  • RACI-type matrices make accountability auditable.

Limitations of team role models

  • Self-report. Most preference instruments are questionnaires that people fill in about themselves. Answers reflect self-image and what the respondent thinks the organisation wants to hear, not necessarily observed behaviour.
  • Weak validity evidence for some instruments. Furnham, Steele and Pendleton tested the Belbin Team-Role Self-Perception Inventory in three studies and found unimpressive or low alpha coefficients and factor structures that did not clearly reproduce the proposed roles[7]. Later reviews were more favourable but still reported weak discriminant validity between some roles[4]. Commercial instruments are often validated mainly by their publishers.
  • Stereotyping. Once a person is labelled "the plant" or "the controller-inspector", colleagues may stop expecting anything else. Labels can turn into self-fulfilling prophecies and limit development.
  • Context. Behaviour depends on the task, the team and the stage of the project. The same person may coordinate in one team and stay silent in another. Static profiles miss that.
  • Balance is not everything. A team with perfect role coverage can still fail through poor goals, lack of skills, weak leadership or groupthink.
  • Formal roles can harden. Rigid job boundaries ("not my role") slow down small teams where everyone should be ready to help.
  • Time and cost. Profiling and workshops are hard to justify for short-lived teams.

Related approaches

Team role thinking connects with several neighbouring topics. Stage models of group development, described in phases of team creation, explain why roles shift as a team matures. Group norms describe the shared rules that often define informal roles. The ability to work in a team and the advantages of teamwork are, to a large extent, about people's readiness to move between roles. In virtual work, role clarity matters even more because many informal cues disappear; see virtual team.

References

Footnotes

  1. ↑ Benne K.D., Sheats P., Functional Roles of Group Members, Journal of Social Issues, 1948, pp. 41-49
  2. ↑ Kahn R.L., Wolfe D.M., Quinn R.P., Snoek J.D., Rosenthal R.A., Organizational Stress: Studies in Role Conflict and Ambiguity, John Wiley & Sons, 1964
  3. ↑ Rizzo J.R., House R.J., Lirtzman S.I., Role Conflict and Ambiguity in Complex Organizations, Administrative Science Quarterly, 1970
  4. ↑ Aritzeta A., Swailes S., Senior B., Belbin's Team Role Model: Development, Validity and Applications for Team Building, Journal of Management Studies, 2007, pp. 96-118
  5. ↑ Margerison C., McCann D., Team Mapping: A New Approach to Managerial Leadership, Journal of European Industrial Training, 1984, pp. 12-16
  6. ↑ Schwaber K., Sutherland J., The Scrum Guide, 2020, section "Scrum Team"
  7. ↑ Furnham A., Steele H., Pendleton D., A psychometric assessment of the Belbin Team-Role Self-Perception Inventory, Journal of Occupational and Organizational Psychology, 1993, pp. 245-257
Team roles — recommended articles
Belbin team roles — Belbin team role inventory — Project team — Team structure — Small team — Matrix of responsibility — Roles of team leader — Advantages of teamwork
Retrieved from CEOpedia