Nigel Meakins

Nigel Meakins' Blog

MS Teams–Teams or Channels?

When planning your MS Teams rollout and how to structure your teams there are some simple points to bear in mind.

Teams is for Teams…

As the name suggests, MS Teams is about, well, teams really. Thanks for that fantastic nugget of genius Captain Stating-The-Obvious, what would we do without you? Therefore if you have teams of people already organised for projects, then creating an MS Teams team for each of these makes logical sense. Should you have information that is only for this team, it can be contained within the privacy of the team, as team boundaries are the only point at which access can be enforced. There are no private channels (although this may be something coming down the release pipe though no real indication of as and when).

Teams is Flat

You may not realise this at first, but there are no real hierarchies within MS Teams other than Teams being the parents of Channels, which in my book doesn’t really count. So, no ‘Sub-Teams’. And no ‘Sub-Channels’ either. You will need to think about naming conventions to enable some logical sorting of your teams if you are to avoid a jumbled mess on the UI. Channels within Teams can be collapsed within the Desktop App, but not within the mobile apps. To make mobile users’ lives a little more tedious, the search functionality does not extend to actual team and channel names, so you’ll be whipping your finger frantically up and down the screen to find that team or channel you are interested in. You can ‘favourite’ channels but not teams to help with this, but there is still lots of room for improvement in this area of the application. By organising into teams at least you can manage membership and people will only see those teams and channels they are members of, in addition to any channels they have explicitly chosen to ‘follow’.

Teams and Channels are Hard to Move

Bear in mind that once created, it is not easy to move chat and other team content that is stored outside of SharePoint Online to another team. Don’t assume you can fix things up as your (flat) ‘topology’ develops.This is not something you really want to have to try, and even if you did your options for relocating are limited as things are, well, flat. If you are thinking of having a lot of channels within a team and then reorganising into other teams when the number of channels starts to become overwhelming or a better structure presents itself, this isn’t really going to be easy. Microsoft have not really provided any provision for reorganising your content. The assumption appears to be that users know what their teams are going to look like and what these teams will contain, and that isn’t likely to change, so why add this functionality. I’m sure as the adoption of the service picks up Microsoft will realise that this isn’t really going to cut it in large organisations, where restructuring is sometimes a quarterly activity (“What do you mean we’re moving desks again? My bonsai is only just getting acclimatised!”). For now however best to exercise some forethought and try and avoid this painful exercise. A well thought out demarcation for your teams will avoid a whole world of pain in the not too distant future.

Below is a simple suggestion for how you may start to structure teams for client projects and R&D within a medium sized organisation.

Company TeamsYou may want to have a team that is purely for ‘global’ client stuff outside of projects, in addition to the Project-focused teams.
Client Teams and ChannelsWithin each team the various channels allow the team members to structure their communications in a focussed manner, for the attention of the members of that team only. As you can see, once you start segregating your topics into channels, these project teams are going to be getting rather busy on the channel listing, as this hypothetical project alleviates to. Bunch all of the Client 1 channels into a single team and you can see how things will soon become difficult to manage.

R and D Teams and Channels

The same thinking applies of course for non-client work structuring, such as for our R&D endeavours.

You could of course have opted for bundling everything for Client 1 into its own team, or likewise for R & D, with an increased list of channels therein. With each additional project you will have more channels for your larger audience within the team (as they now contain members for and increased remit) to have to wade through, which over time is probably going to become unmanageable unless you are only looking at a small number of projects. This way there may well be monsters, or at least swamps, quicksand and other things you’ll probably wish you’d avoided…