Unpopular opinion: Do not restrict users from creating Teams (Office 365 Groups)
I realize that advocating for no (or very limited) boundaries on who can create Teams puts me in the minority. When I look out across the community, I mostly see consultants in this space suggesting the opposite is a superior approach for various reasons–that the privilege should be constrained heavily.
Especially since the advent of Teams, the advice seems to go something like this: “The first thing you want to do is take away privileges to create Office 365 Groups, and then designate a few select individuals who hold the keys to the collaboration kingdom.”
Then the customer has to implement their own custom “New Team approval process” and do other weird things. Plenty of extra work generated for consultants and the IT department.
Maybe I’m still missing something… but I just haven’t found there to be too many cases where I would genuinely be able to recommend that approach. The self-service aspect of Teams is kind of like… the whole point. Or one of the major points anyway.
Sure, you can name specific scenarios where you would want to exclude limited groups of people from this privilege–if that were really important to you. For instance if you have some part-time contractors or volunteers coming in and out frequently.
But I find these cases to be pretty rare, and on the whole, my attitude is that your typical full-time employed information worker should be able to freely create Teams, associate with others of their choosing and collaborate at their leisure. You know, as was the intention of the product to begin with.
In this post I want to address the most common objection to the default position (anyone can create Teams), and the answer to that objection, as I see it.
But there are going to be too many groups!
So what? Define too many groups. 1,000? 10,000? 100,000? Don’t worry–you still have room (maximum is currently 500,000).
Microsoft does not restrict this privilege for any of their full time employees–that’s a lot of people. And I love that philosophy! The trade-off, of course, is that they end up with some very impressive numbers–check out this PowerPoint slide from their internal Core Services team, shared recently at Ignite:
You saw that right–more Office 365 Groups than total users. But still just south of the half-way mark for the number of total supported groups in a tenant–so they have plenty of room left to grow!
Microsoft doesn’t sweat this sprawl, so why should you?
Because too many groups = confusion, fatigue, and poor end-user experience
Technically we have two major camps of people who discourage open Group creation.
The first camp is made up of people who are still possessed by what I call the legacy or control mindset. These well meaning individuals are usually afraid of giving up too much control and too many permissions, and in general they will attempt to place restrictions on their user base. Their false belief is that users are bound within the structures they set, and if they cannot see the problem, then the problem does not exist.
I mostly ignore the first camp, as it is only a matter of time before these dinosaurs die off entirely–the world won’t tolerate them much longer.
But the second camp is made up of really smart people–people who “get it” and really do care about the end users. They have seen the negative impacts of Groups sprawl–which is a real thing, again especially since the advent of Teams. In fact belonging to too many Teams can lead to something known internally at Microsoft as “Teams fatigue” (or so I have been told).
In short, you don’t want your users throwing up their hands in frustration, and tossing out the baby with the bathwater.
But I feel the same way about taking away rights to create Groups–it is like using a sledge hammer when the job really called for a fine chisel.
The solution: Exercise smarter governance
When it comes to governance, the very best thing you can do here to mitigate sprawl is not to remove rights on creating groups, but to implement a Groups expiration policy. This has recently been improved in that only inactive Groups will be expired–therefore if a Group is still active, it is auto-renewed. So setting this policy down to even 6 months (180 days) is not that risky anymore, and can help you regularly sweep out debris and clutter.
Some groups will just fizzle and die. I know. It’s sad. But such is life. Don’t sweat it; others will take off and produce an abundance of value for the organization! But you can’t predict who is going to start the next big thing. And the owners are going to get a notification with an option to renew anyway, so quit your worrying!
Another important piece of governance magic you will want to implement is retention labels, so that information workers can mark content that they want to have preserved, even if a group does eventually die off from expiry. In fact, you may consider implementing a retention policy to provide a blanket protection for the organization.
Remember that groups will still be expired even if content is protected by retention, but it remains eDiscoverable / “Content searchable“–for as long as the duration of that retention.
There are many other “soft governance” things you can do here, as well; for example using good descriptions for core Teams, and including a Team picture / avatar can go a long ways towards helping people quickly identify their major groups when navigating a sea of objects.
And with regard to governance in general I have a whole bunch more to say on that topic–in an upcoming post we’ll talk about its relationship to education and training. But for now…
Parting thoughts
In my own company, we also have not restricted the creation of Groups. True, this has lead to some pretty crazy Groups floating around out there–I think we have one that is dedicated to Foosball for example. And yes, I probably belong to too many Teams myself.
But here’s the thing, if I did work for an organization that restricted my capability to freely create and to associate with people… I would probably leave.
Not everyone feels this way, but to me it sends a subtle message: that I’m not important, or that my ideas aren’t important. Maybe some other people are more important, and get to make the decisions about what important things are. Well, that’s just dandy. I hope they enjoy their highly important work. Without me.
Say what you will about that–I love being able create a stage on demand–to step up to the mic, and start a conversation. I suppose that’s why I have blog. And here’s the thing: you can’t predict who those people are going to be, and who is going to succeed at starting up something really great.
Of course, I agree and realize that more of your Groups than not will likely whither and die. But that is not so different from anything in Nature. Contrary to popular opinion, Nature produces a lot of waste actually–flourishing abundance requires waste. Good ideas are usually born out of a giant compost heap of bad ones, and success is usually preceded by many, many failures.
So yes, you will belong to Groups that go nowhere. And yes, you may even experience some disappointment when your ideas aren’t the ones that gain a lot of support or attention internally. But you know what? That’s okay. Because the cream tends to rise to the top. Your attention will ultimately land where it needs to, and if you are persistent, then you will find the right channels in which to contribute, and broadcast your own voice.
Comments (19)
This has been a big point of contention for our IT team, primarily because of the creation of a SharePoint site for every Group. Our SharePoint is already in desperate need of an overhaul and we’re afraid having too many Groups will wind up making that worse. Plus, each of the project teams we have already have their own SharePoint site to work in, and having multiple may confuse users. Is there a way to point a new Team to an existing SharePoint site instead of it creating one?
If you are using SharePoint sites that are attached to Office 365 Groups, then you can create a Team from an existing Office 365 Group, sure. But I wouldn’t sweat this too much if not, like if the SharePoint sites are classic and not tied to a Group. Teams are little islands–all to their own. Now some people who came from the SharePoint world have tried to “SharePointify” Teams and treat it like SharePoint–thinking it needs to be more organized and structured. But that is not the modern way. In Teams the nature of work is ad-hoc and unstructured. So you stand up Teams and tear them down all day long. They are not attached to one another or anything else–they are an island of interconnected resources available via a common UI on any platform–web, mobile and desktop. Sometimes you may find out that two different Teams can be combined into one, and that’s fine too. One dies the other lives. No biggie. So I would discourage you from attempting to think about Teams like you thought about SharePoint. It’s a new thing. You can migrate data from old SharePoint to new Teams world (people may prefer Teams over SharePoint long term due to the many other features that are wrapped together and access from common app). You could for example even add a tab to a channel and point that tab at an existing document library if you want to, to ease access and transition, but to reduce confusion I would keep them as separate and distinct containers (e.g. their own built-in document library is the place for files), and move content to the more modern containers over time, and let the old ones die off. SharePoint may still have a place in the end, but it will be severely reduced (more company/communication stuff, less team-based work). And remember–you get 500K groups and 2M site collections now, so I’m sure you’re not that close to hitting these limits no matter how “messy” it seems. Life is messy. Embrace it.
Alex,
We are in progress of migrating from file shares to team sites/Sharepoint. How would a situation look if I allowed my users to create their own teams/channels?
I feel like there should be more to this question–I’m not sure what you’re after yet…
We are in the process to migrate file servers to Teams. I’ve been reading your migration guide. Using the idea of one team per department or business unit and using more channels and less teams wherever possible. My question is… With your unpopular opinion of allowing users to create their own Teams. How would that look? With having users create their own teams with the idea of using teams as a file server replacement. Sorry i’m trying to wrap my head around it. It seams like i’m basically giving users access to create their own file shares.
Correct–the modern way is to give users the power so that they don’t have to rely on IT to have file shares provisioned. You may have some “static” teams based on departments or processes involving several departments, but there may be other Teams needed ad-hoc for various projects. Rather than rely on IT anyone can go get the resources they need, without using something outside like DropBox, ShareFile, etc.
Behind the scenes, Office Groups are a combination of a group and a user account. That user account shares some of the same namespaces as your actual user accounts. In small environments, this is unlikely to cause much potential for collision. In large environments, it’s guaranteed to result in collisions. First one in wins, so that important new hire doesn’t get their user account created (or worse gets a subtly broken user account) by your automated system because someone chose a poor name.
Fake news. And the open approach doesn’t seem to cause a problem for Microsoft–they of course have more than 200K accounts. Also, I am not aware of a “user account” associated to a group. There is a group object which comes with a group mailbox: for example if there is already a team or Distribution list out there called “[email protected]” and someone creates a Team called Executive Team then it will make up a new email automatically for you such as ExecutiveTeam94… but so what? Someone would have to create a Team called like “BrianA” or something similar to take a future person’s potential user name or account. And even then the situation can be easily rectified. Non-issue.
Sorry Alex but you clearly don’t live in a world where you have to deal with the consequences of your policies. This “free market” approach to the creation of these resources only creates confusion and, ultimately, less productivity as users and administrators spend time trying to understand which resource is relevant to its intended purpose. Its simply an excuse to promote fake efficiencies where no lie.
Organizations take both approaches successfully. Just depends on how you implement the right governance. Some prefer to drop the full sledge hammer as you suggested.
From experience with Teams, SharePoint and users in general. Groups are a nightmare if not controlled.
A client of mine just over a year ago started using MS Teams without any format or guidance from us. They now have 45 active Teams (Because we got involved recently and archived lots of them) and 103 active SharePoint sites, which we are in the process of sorting)
They then came to us to complain about how messy it all was and wanted us to fix it.
This is the reason why some (not all) clients need to have restrictions in place, never due to the IT guys being controlling, but rather stopping users being ‘users’ and just doing what they like, for the IT team to then HAVE to pick up the pieces.
The group creation ‘issue’ if a disty group already exists and a user then creates a team with the same name. Then creates the new Group/Team with a different email (I.e. [email protected]), but when the user then want’s to “tidy” this up, they then delete something else. (My recent experience was a user deleted the wrong team, which happened to be where they stored lots of documents, which then deleted most of their companies shared files – which we can restore, but it is then unnecessary downtime for the user and ticket charge)
My comment is mainly aimed at MSP based management, corporate I understand will be slightly different.
The core issue here is that the folks have not yet adapted to the new way of working. This is on both sides. IT and end users. For IT, we have perfectly adequate governance tools to manage the sprawl–but nobody knows about them so they just want to “turn it off.” On the end user side, we have to stop assuming that people can just pick up new software and instantly “get it” and use it correctly. There was a time, when computers were still newer technology in business, when it was common sense that training and adoption programs were part of the investment. Now we think that doesn’t apply for some reason. It does. M365 and platforms like it–this is a whole new information system that is completely unlike your clunky old technology of yore. It’s time to grow up our skillset, get people their digital passports, turn them into modern day digital citizens who understand how to better manage data (this includes stuff like labeling, metadata, etc.), and yes, how to manage the “containers” as well.
Allowing users to create Teams freely can backfire. It certainly did in our case and I am still fighting an uphill battle to put restrictions on it. At the moment we have 649 teams for 225 users. Every time we hire new people, they tend to create ‘yet another team’ despite the clear instructions not to (instructions are – check first if a team does not exist yet for that particular topic). That approach, i.e. education, is clearly not working. Information related to the same project are scattered across multiple teams, teams are often orphaned or abandoned altogether. There is ‘team fatigue’ when people don’t know where to look for certain type of information since it’s all scattered all over the place. Group expiration policy in real life does not work either since one day somebody may suddenly remember that he/she needs particular files which could have been deleted in the meantime. Expiration as ‘archive’ rather than ‘delete’ would help.
Regardless – I am a strong advocate of restricting teams creation and implementing approval process (where users clearly state what/why/purpose) and then the team is created by authorised user.
You can easily solve these headaches with five items:
1. Expiration policy (yes, this will just delete stuff–which is GOOD–go turn it on and don’t ask permission, just forgiveness–it’s worth it)
2. Retention (which will help you retain even deleted content if that is needed in future due to above)
3. Anchor Teams: these represent structures in the org that aren’t going anywhere anytime soon. Could be department or process-based. These teams are easy to identify, e.g. have corporate icons and follow a naming convention, and multiple channels with well-defined parameters/boundaries. (These teams are never in danger of expiry because they are used every day.)
4. Teams outside the Anchor Teams tend to be lead by “whomever” and may follow different convention or no convention–but they are clearly different than the “primary places” of business
5. User education: this is more than “clear instruction”–it’s actual training, and it’s providing resources and support at the point of need–within the context of this work (e.g. have a channel dedicated to it), as well as frequent communication. For example, be sure they know about the expiration policy but you don’t have to tell them you have a secret back door for retrieving their content (retention).
Make the users take responsibility for their information. It is not feasible for IT to handle all the responsibility for every dataset and request related to it. So it IS the users’ job, not yours. But you have to give them all the tools. See my write-ups on History of Governance and Sensitivity Labels for more complete picture of what I’m talking about there.
Absolutely agree with your opinion. Without no self-service teams and SharePoint the control mindset is restricts the employee experience, collaboration and in the end innovation. not good for the company. thank you for this article!
As is often the case, the correct answer to ‘Should you allow users to create groups’ is ‘It Depends.’ One aspect I don’t see mentioned anywhere is security. If your SharePoint policy allows for external sharing, but you want controls over who can share externally and what can be shared, and you don’t want all of your SharePoint sites to have external sharing enabled by default, you probably shouldn’t allow users to create groups. In the above scenario, my experience has been that the corresponding SharePoint site that gets created when a group is created will also have external sharing turned on by default. It’s hard even in a small organization of <50 people to keep track of the SharePoint sites that get created with each new group, I can't imagine doing so in a larger organization.
My attempted workaround for this was to allow users to create groups, but then set up an Alert in Azure to email IT anytime someone creates one so IT could disable external sharing on the corresponding SharePoint site, but the alert rarely fires.
If you add up the time it would take to audit the SharePoint sites that get spun up against the time it would take for a user to simply send a request to IT to create the group for them, it's not hard to figure out which route will cost the company less.
Sensitivity labels can be configured to control this, and when users create groups they can apply the correct sensitivity label, and get the right sharing settings. Instead of restricting users, you can empower them.
Perhaps I’m one of the dinosaurs (approaching 40 years in the business). The old saw about “the lunatics are running the asylum” comes to mind. However, the boss has an opinion like yours – give the people the tools, implement expiration and retention policies, then we’ll see what happens. I did convince him that providing training BEFORE our release of MS-Teams is essential.
If he’s right great, if not I’ll have to sort out the mess, with a cold comfort of “I told you so.”
You are both correct. Without training and proper governance, it will not go well.