A Quick Guide to Belbin for Teams
Tuesday, 4 Aug 2026
In 2008, I was introduced to Meredith Belbin’s research on the success and failure of teams, as part of a company-wide initiative after a major merger. Without exaggeration, this has been the single most valuable tool I have learned, ever. It has changed the way I look at teams, and at people, helping me see more of their abilities, and strengths, and how to combine them, or support them, to being not just good, but great.
Shortly afterwards, I applied this new-found knowledge to a struggling project, with immediate success. I then started reviewing many teams and organisations through this lense.
In this post I want to give you a flavour of what Belbin’s perspective can bring to your team, and why just having the best people, isn’t enough.
Why your best people aren’t enough — Evidence-based Insight
In the 1970s, Meredith Belbin’s research team spent 9 years watching real management teams work through a business simulation, psychometrically profiling everyone, deliberately composing the teams, and measuring how they performed.
They eventually got good enough to predict which teams would win or lose before the exercise began, and the key finding is worth getting tattooed:
What separates a winning team from a failing one isn’t intellect, it’s behaviour.
Belbin’s “Apollo teams”, built entirely from the smartest people he could find, did worse than ordinary teams. They debated brilliantly, picked the finest holes in each other’s arguments, but never actually got the work done.
Out of all that research came nine recurring clusters of behaviour — the Team Roles. Each has a measurable strength and a predictable allowable weakness. Everyone has two or three comfortable roles, and asking someone to play against their natural grain can be actively harmful to the team.
This overview table is a handy reference for the rest of this post: for each role, its typical characteristics, the strengths it brings, and — just as important — which weaknesses are allowable, and which are not.

You can read up on the individual team behaviours here, and here, before moving on.
It’s All About the Team
Belbin’s controlled experiments show that teams of clones fail, and they fail predictably. All Shapers argue. All diligent Implementers execute beautifully in the wrong direction. Every “pure” personality team was brilliant in one situation and useless in the rest.
Winning teams combine different, and compatible roles — and these patterns can be constructed. But be careful, the same person can be a star in one team, and a burden in another.
Team design must be a leadership choice, and not an arbitrary formality.
Assuming you have current personal and team assessments to draw on, these following guidelines should help you quickly identify troublespots, and areas for improvement.
The Team Rules of Thumb
Size
Five to six is the sweet spot. Under five, people stretch across too many roles; things get dropped. Seven or more and that essence of a team is lost, there are too many people for it to meld together. You don’t need nine people for nine roles, everybody carries a few, so a well-chosen five easily covers the whole wheel.
Balance The Wheel
The nine roles group naturally into three domains, and your “team wheel” should have a relatively even representation across these domains, and ideally across these behaviours as well:
- Thinking: Plant, Monitor Evaluator, Specialist
- Action: Shaper, Implementer, Completer Finisher (CF)
- People: Co-ordinator, Teamworker, Resource Investigator (RI)
Map each person’s top two roles onto the wheel: gaps show what to recruit or consciously cover for; pile-ups show where the fights will start. Duplication is every bit as dangerous as a gap — two Shapers lock horns, two Plants fight for airtime.
Fill the Critical Roles First
A small team needs a Co-ordinator (clarifies goals, delegates), an Implementer (reliably turns decisions into done work — the one role in every successful team), and a Plant (the source of ideas and alternatives). Where success hinges on a few crunch decisions, add a Monitor Evaluator as the designated critic and arbiter — the person who sees the pitfalls, the whole plan, and is rarely wrong.
Super Combos
Some pairings reliably work:
Co-ordinator + Plant (a facilitative chair drawing out one creative mind) this was one of Belbin’s strongest findings
Plant + Monitor Evaluator (ideas + critical evaluation)
Shaper + Implementer + Completer Finisher (a delivery engine)
Resource Investigator + Teamworker (outside opportunities + inside cohesion)
Fatal Fellows
Some pairings reliably don’t:
- too many Shapers (infighting)
- a Co-ordinator and a strong Shaper (leadership tug-of-war)
- multiple Plants (ideas that never converge)
- and all-analytical teams (the Apollo Syndrome — endless debate, no decisions)
Mind the Gap
Watch the gaps too:
- no Plant means no ideas
- no Completer Finisher means missed deadlines
- no Teamworker means unresolved friction
- no Co-ordinator or Shaper means drift and lack of focus or direction
Perfect Patterns
These are the winning blueprints — combinations that always seem to work. Belbin’s winners shared a shape:
- a Co-ordinator in the chair, or a Shaper
- exactly one strong Plant given space and cover
- a Monitor Evaluator stress-testing the ideas
Then fill in everyone else around the wheel, clearly demarcated, so nobody’s scrapping over the same job.
Finally, a self-aware team beats a balanced-but-blind one every time, because a team that knows its gaps can deliberately cover them.
Projects vs Operations
The role mix that suits one can sabotage the other. Projects shift phase by phase — Plant/RI to start, Monitor Evaluator/Specialist to appraise, Co-ordinator/Implementer to plan, Implementer/Shaper/Teamworker to build, Completer Finisher to test and close. So a fixed team struggles as the work matures (early-phase Plants and RIs who overstay are one root of scope creep).
Operations run on Implementer/CF/Specialist/Teamworker discipline; their usual gap is Plant/RI (so toil never gets automated away — “firefighting forever”) and Shaper (so problems never get escalated). Major incidents invert this: you suddenly want a Shaper or Co-ordinator to cut through the paralysis.
The project-to-ops handover is an obvious clash — reckless-vs-bureaucratic — but it’s a role difference, not a competence one, and naming it that way defuses it. DevOps asks one team to hold both profiles, which is hard; hire for the missing cluster and share the on-call rotation.
What’s It Not
You don’t need nine people, just the nine behaviours covered. No role is “better,” though organisations habitually overvalue Shapers and undervalue Teamworkers and Completer Finishers.
Belbin’s research yields a critical insight — it’s not a personality test, roles are behaviour in a team context and will shift over time.
The role you play, and the skills you bring, both personality and experience, are a conversation-starter, not an excuse or a hall pass.
Ideally your individual self-perception is matched with observer assessments from the colleagues and customers you actually work with; the Belbin methodology ensures that this data is both collected, and adjusted for local culture and behaviours.
Nobody is well-rounded, but a team can be. Hire and staff for the role the team is missing — not another copy of its strongest player.
Further Reading
There is more Belbin material — questionnaires, team wheel examples, and long-form role descriptions — in my belbin collection.
For the full story, see Belbin’s two most recent books, and his wikipedia page:
- Management Teams: Why They Succeed or Fail
- Team Roles at Work