Interesting presentation about teams, from HR at Canonical.
https://dl.dropboxusercontent.com/u/920614/Belbin%20Team%20Roles%20-%20Nov%202013.pdf
I’m copy and pasting from my email response:
I have a few questions about it and a few thoughts on how
this relates to us:
Since we are a small team we frequently end up playing more than one
role. Does this discus any of the challenges with regards to playing
multiple roles? Do you think some of the roles conflicts with each
other? How do you transition from one role to the next in a
projects/in different projects? Does weaknesses tend to add up or
cancel out?
I would like to map this to the roles involved when developing
software applications. There are many different roles to play:
figuring out what to build, figuring out how to best build it,
debugging the problems, polishing the UI, etc.
With tech I feel that the more roles I need to play in one software
project, the more tedious it becomes. If I’m the person driving
product quality, ensuring everything is implemented properly,
polishing the user interface, thinking about whether we’re using the
best technologies and methods, debugging the problems, maintaining the
system and providing support to the users it feels like I end up with
a lot of acceptable weaknesses and I don’t know if the sum of them
becomes unacceptable?
Claire is the head of HR for canonical so I assume she also applies this to sw development teams. She used these slides for her presentation at the shuttle worth meeting (which I didn’t attend).
I can’t answer on her behalf, but assume this is more helpful to understand personalities and general roles than specific job responsibilities - as a way to understand team dynamics and identify why some collaborations may work better than others.
For software developers, the industry trend- at least for small orgs- goes towards more integrated (creative technologist) roles, but there needs to be a balance between feeling overall ownership of something that gets built (taking ownership of a number of different roles) and feeling distracted/overwhelmed.
You mention 7 different things that you need to do. There will always be some combination, but which of the roles do you think could be handled by other team members or outsourced to let you focus more?
Do you think the industry trend is towards teams of 1-2.
What is important to me in a team is to be open to people playing different roles. A software dev can make a good UX contribution and a designer can point out a confusing API.
Mmm, I didn’t actually keep count of the number of things I mentioned 
If someone else helpes in driving the project - being the product owner - it helps me a lot. And user support is something where other people can help.
Maybe we should consider swapping some roles in projects we are doing like doing each other’s bug fixes? @Erika, next badges bugfix is on me
Copying and pasting from my email response
I’m late to this thread I know, but couple of thoughts [responding to D and Erika’s comments elsewhere]:
- don’t forget frameworks of this kind aren’t really about labelling or pigeon-holing, they’re about finding new ways of describing what we already know, to (hopefully) provide useful insights. Such systems are never meant to constrain but to liberate, by (hopefully) helping explain observed phenomenon: teams/projects that have worked well, teams/projects that just don’t seem to get traction.
So take what you find useful and throw away the rest; never meant as a one-size-fits-all magic pill for management.
Personal thoughts: what I find interesting and useful in this framework is the emphasis on roles not personalities, and emphasising each person will fill multiple roles in diff teams and/or diff phases of project. Seems particularly useful in small teams/orgs like P2PU, where we do wear multiple hats, and perhaps could be useful (when planning, or when stuck) to think about which roles we’ve got onboard at that point, and which if any we’re missing.
Responding to comments from others [in emails off this thread]:
- framework like this should be of v limited use in hiring decisions; person only takes on a role when working in team; can’t be preassigned a slot;
- these aren’t and shouldn’t be “sticky” labels; as noted we all manifest aspects of variety of these roles at diff times
- changing between roles will largely ‘just happen’, tho I suppose you could use this like de Bono’s hats if you wanted to focus efforts on a tricky/stuck project.
- Dirk’s comments re playing all roles in a team of 1 is interesting; in some regards this thesis has nothing to say on that as only relevant to teams: a team of 1 either gets the job done or not; but for a bigger team this model can be useful in identifying which roles (ie traits) are onboard and which are missing.
- unacceptable weaknesses… I wouldn’t get hung up on them. Think their point is more to draw out this useful thought that every role comes with strengths and weaknesses and it’s important in organising just to be thinking through what’s acceptable/inevitable in the role, and what’s really not…
Sorry - had more to say than I thought. Interesting slidedeck.
1-2 people is very small, but in small orgs that do some software development, developer teams will be small as well. It’s the same for our learning “team of 1” (with a little bit of my time). Small means lots of responsibility, but also lots of different things one has to juggle.