Teams, team-working, and design principles for supporting it

Share

I recently published an article in which I argued that Microsoft Teams is a team-working platform, works well as such, and we should not try to use it is a virtual learning environment. This assumed that there is a big difference between the general use cases: team-work and VLE-based learning. This needs further explication:

Teams have a strong and coherent shared purpose. They have common working practices that are made up of assumptions about processes to follow, ways to behave, places to store things, roles etc. As it’s quite hard to develop and sustain this commonality in large groups, teams tend to be smaller – there’s an optimal size that varies depending on the domain. In technical professions, with detailed processes embedded into systems and protocols, teams can be quite large, and more fluid. For example, accountancy firms deal with regular processes in regular ways (irregularity in accountancy is generally considered to be a bad thing). Creative teams tend to be smaller. But the key factor are strong cohesion, shared purpose and understanding.

When designing a platform for well-functioning teams, with the characteristics described above, we don’t want to impose structure, or put a lot of unnecessary context-setting messaging in the way. So for example, when they come into the team space, team members don’t need to see the purpose of the team and its rules of operation reiterated obtrusively. We just assume they know all that. They can organise files themselves into a structure that makes sense for them. We don’t need to impose order on them. It will emerge through their strong shared purpose and culture. Hierarchies and roles don’t need to be encoded into systems, they are just there in the culture, and adapt as needed. This is what we see in Microsoft Teams, which evolved as an optimal platform for team working. Using it with people who are not working in a tight-knit team produces disappointing results. A lot of confusion! They can’t find anything. They don’t know what to do. They disengage. It’s OK if we are prepared to do a lot of team-building with them, for example with an expert engaging in dialogue and co-working. But you can’t expect them to thrive in this environment without a lot of support to become part of the team.

If we look at a platform designed for people who aren’t necessarily operating as a team, we see something quite different. Often there will be a clear and detailed statement of purpose. On a VLE course page, this can be quite important. There will be a lot of pre-specified structure, and a lot of signposting telling users where to go and what to do. We see design patterns such as the “process funnel” and “scaffolded documents”. Hierarchies and roles are coded-in, so as to guarantee order and correct behaviour. We design and use such platforms without being able to assume the level of shared purpose and understanding that we get with teams.

And that’s why we need to treat these platforms and design challenges so differently.

Dr Robert O'Toole NTF

Senior Academic Technologist, IT Services, University of Warwick Fellow of the Higher Education Academy National Teaching Fellow Warwick Award for Teaching Excellence

You may also like...