Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Building Better Teams

DZone's Guide to

Building Better Teams

Creating your best team requires more than what is in the job description.

· Agile Zone ·
Free Resource

Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.

Nov 2018: If you've been building teams for a while and you've got the hang of identifying "Smart" and "Gets things done" candidates, consider using Belbin's "Team Roles" concepts to help get your teams truly firing on all cylinders.

Even after a few years of doing hiring for teams I'd never really thought beyond "hire really capable people for the job at hand." In technology, that's probably pretty common — if we're looking for 5 Python specialists, 3 JavaScript experts and 2 adept SQL developers, then surely that's what we look for?

Well — maybe.

Or rather, yes — I mean we're not talking about pulling a fast one on some innocent C++ people. I just mean that's not necessarily all we should consider for the best outcome.

Look at the people you work with or study with right now, or have done so in the past. I'll go out on a limb and suggest they weren't identical Software Developer clones: some of them might've had a proper personality in there, a sense of humor and everything!

You probably also noticed different team members did better with certain types of task — some excelled at the early stages, the full-of-possibilities time, the researching tools and products time. Others came into their own at the later stages: keeping their head down and persevering through bugfix after bugfix after bugfix.

And still others perhaps thrived on the keeping-everything-moving parts of the project — how's progress comparing to the part of the plan we should be at? Are we definitely working on that infrastructure task? Is the UI fully done? Really?

That people can contribute in significantly different — but still highly valuable — ways to a team has not gone entirely unnoticed: and this brings us to Belbin's Team Roles.

Belbin's research essentially identifies 9 core contributor roles/styles that are typically seen in teams:

  • Plant
  • Resource Investigator
  • Co-ordinator
  • Shaper
  • Monitor Evaluator
  • Teamworker
  • Implementer
  • Completer Finisher
  • Specialist

Some of these are fairly intuitively named, although "Plant" is a rather cryptic one, and is described by Wikipedia so let's include that definition here to get a feel for what we even mean by these roles:

Plants are creative, unorthodox and generators of ideas. If an innovative solution to a problem is needed, a Plant is a good person to ask. A good Plant will be bright and free-thinking. Plants can tend to ignore incidentals. The Plant might be caricatured as the absent-minded professor/inventor, and often has a hard time communicating ideas to others. Multiple Plants in a team can lead to misunderstandings, as many ideas are generated without sufficient discernment or the impetus to follow the ideas through to action. Plants can also create problems with the timing of their ideas. The fact that the team has decided on a valid way forward and is now in the implementation stage will not stop the Plant from coming up with new solutions and disrupting the implementation process.

Read about it and the others, plus some extra background at the Team Role Inventories page.

If you read the descriptions of the roles via that Wikipedia link, or have just had a bit of a think based on the titles, you've probably got some ideas on which roles describe your own strengths best.

As an individual, I find that recognising that people can contribute differently but equally is quite liberating: don't beat yourself up if you're delighted at being hailed as the nails-the-late-bugs team member, but the thought of having to choose the database platform for the next 5 years brings you out in hives. Let Plants be Plants, and let Completer Finishers do their thing.

This can be summarised really as "play to your strengths" — and don't feel guilty for doing so!

Watch out too though: don't use your own affinities — self-assessed or otherwise — to hide away in your comfort zone, or as an excuse to avoid the sometimes dull work that actually nobody wants to do. "I'm a Plant, I don't file expense claims, leave me alone!" won't wash, sadly.

And don't limit your own development options either: if you'd love a gig in R&D or helping out the sales group, don't ruin your own opportunities by telling yourself "I'm just a Monitor Evaluator, I could never work there!".

There's a special significance to all of this for the Performance Reviews: if you've got any kind of decent relationship with your manager, you should both be able to have an open conversation about your "strengths" and "areas to improve" in the context that nobody can possibly be perfect on all such dimensions. The notion that professional development is akin to "levelling up" all your skills to 10/10 like some weird computer game is nonsense, and can be quite toxic.

(Belbin Team Roles are not personality categories, by the way: don't go around introducing yourself as a "Monitor Evaluator and a Capricorn" at parties)

If you're managing a team already, hopefully you're already aware of each member's strengths and preferences and aligning tasks with those as much as possible — and there are of course limits.

Where I suggest Belbin comes into play in this scenario is simply for reinforcing that kind of good practice, and perhaps supplying a formalized rationale for doing so.

I think it also gives us pause for thought when considering "pushing" people: if Alice is a debugging superstar and will immerse herself in the codebase for a week if need be, clutching a fixed bug in her figurative clenched fist at the end of it, don't blindly rush to swap her tasks with Bob who loves being front and central with the sales team, driving from sales pitch to sales pitch.

By all means, talk to people and work on actual goals and development plans, but just be mindful that pushing someone into a task or role that's simply a terrible fit could do an awful lot of damage, affecting morale, confidence, and team members' overall wellbeing.

To be clear: there's a difference between challenging and developing people on the one hand, which usually will involve a little discomfort as they grow and improve, and mis-assigning them on the other, which could be really harmful: do the first one, not the second!

You might also use the Belbin roles to consider whether your team makeup is, on the whole, a good one for the task or project at hand: 5 Co-ordinators and a Plant probably won't make a great fist of getting through a pile of 300 tax returns without some drama and/or injury.

What problems does your team have — lack of drive? Too many "hot heads"? No-one can finish one task without starting two offshoots? Could Belbin roles help understand those problems, and in doing so work to alleviate them?

Finally, we get to the bit we mentioned right at the outset — improving our hiring!

In a nutshell, awareness of the Belbin Team Roles helps us build a more balanced team — and by identifying gaps in our current team, or an overall Team Role Profile we'd like to put together in a new team, we can bring a whole new set of insights to the hiring activity we engage in.

For example, a successful software development team might consist of:

  • 1 x Plant
  • 1 x Resource Investigator
  • 1 x Co-ordinator
  • 1 x Monitor Evaluator
  • 2 x Shaper
  • 2 x Teamworker
  • 6 x Implementer
  • 3 x Completer Finisher
  • 2 x Specialist

Now — I'll be upfront that I've completely made this up. This is in no an "Approved Profile."

But I think that's A Good Thing — anyone can read the role descriptions and begin thinking what sort of team attributes they need. And just thinking a little bit about the different contributions will, surely, help anyone building a team to see the huge benefits those bring.

Note that the total role count there is 19: that doesn't mean 19 people, 1 per attribute. A team of 8 could happily tick all those boxes: people will usually fit into multiple roles: Implementer and Shaper.

Of course, finding talented, qualified people can be tough on its own, never mind having to take into account the additional complexity of factoring in team roles and contributions.

You're probably not going to knock back that award-winning, book-publishing, GitHub-repo-proliferating Python specialist just because she seems a bit of a Shaper, and, well, thing is we've already got someone who fits that bill, so... y'know... it's not you, it's us...

But if you do spot someone like that who looks like a Plant and a Shaper — and now you know how crucial it is to have someone in the team tick those boxes — snap her up!


Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.

Topics:
team ,teamwork ,collaboration ,strengths and weaknesses ,agile

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}