work

Dunbar’s Number in Relation to Team Size and the Effect of Shuffles and Shaping

I had an interesting chat with Steve Freeman at the Limited WIP Society meet this week about the way the relationships within a group change in relation to it’s size during which he introduced me to Dunbar’s Number. Based on my reading so far, Dunbar’s number would appear to be commonly thought to be in the region of 150. In the context of our conversation though, Steve suggested that it was actually a sequence (If I remember rightly 1, 2, 5, 12, 30 … 150) of numbers through which you could identify the points at which relationships within a team change.

I’ve always held the belief that in terms of team size, there is a sweet spot of greater than or equal to 5 and  less than or equal to 8. I’ve previously observed that a team of less than 5 find it difficult to self organise and whilst I can’t substantiate this, I theorise that it may be possible to tie this back to the work of the likes of Belbin and Tuckman. At the other end of that scale, I think that a team larger than 8 needs to consider further the leadership structure and it was this point in particular that led Steve to raise Dunbar’s Number.

Of particular interest to me though is that by coincidence, the department that I work within maps to the sequence outlined above. In the past year our organisation has grown and as a consequence the department has roughly doubled in size. Throughout that growth we’ve made some changes to the way in which the teams are structured going from 3 teams with roughly 4 people on each, to our current state of 4 teams with on average 6 people. We’ve chosen to introduce or at least formalise somewhat the existing Lead roles that we had in place (Rob has previously posted details of the Roles and Responsibility documents that we created at the time for those interested.). Through the processes that we use within the teams, we’ve placed a greater emphasis on communication and I think that is paying dividends. Furthermore, communication at a departmental level is good too.

There are of course areas in which I feel we could improve, none of which I can necessarily single out at this stage, it’s my intention to spend some time understanding them more with other members of the department over the coming months. With the probable introduction of another 4 people to the department this year and the fact that that will take us ominously close to a contingent of 30, the next number in the sequence though, I’m keen for my own curiosity’s sake to attempt to measure the effect of any new team members joining. Not only within the context of the team but of the department at large.

Which leads me to question what to measure? I’ve previously used rather crude measures such as capacity of the team to do work both in the lead up to the introduction of a new person and for a period of time thereafter (I appreciate now that this was wrong, mapping a team’s productivity to it’s overall well being was naive.). I’m thinking of perhaps using something like the satisfaction chart towards the end of this post though I must confess that the value I think would derive from the data would be questionable. I’ve always quite liked the Pillar’s of Agile retrospective because as a tool it can be used by a team feasibly on a regular and ongoing basis to drive recognition of the results of the continual changes they are making to their practices. I wonder if this could be purposed in a different manner, I can absolutely see it working at a team level, I’m not sure how it would work at a departmental level though.

How about you? What if anything are you measuring outside the classic delivery / throughput criteria within your team and or department (in which case outside of appraisals too) that could you point to and say “This event caused this impact on us as a team.”? Does it matter to you that this sort of thing be measured?

Standard