How do you stop Teams sprawl?

Restrict who can create Teams and pair that with a fast approval, agree a naming convention, require two owners for every Team, and review the list quarterly. Sprawl is not a flaw in Teams; it is what happens when creation is frictionless and nobody owns the question of what should still exist.

The pattern is familiar in every business that adopted Teams enthusiastically. Someone creates a Team for a project. Someone else creates one for the same project with a slightly different name. A Team appears for a client engagement that ended eighteen months ago, another for a social committee, three for variations on operations. Two years later there are sixty Teams, nobody can find the right one, and half have not had a message posted since the year they were created.

It matters more than tidiness because of what a Team actually is. Creating one creates a Microsoft 365 group, a mailbox and a SharePoint site. So sixty Teams is sixty SharePoint sites holding business documents, each with its own permissions and possibly external guests, most with no active owner and none being reviewed. That is unmanaged storage containing client data, which is a security and records problem wearing the costume of an organisational annoyance.

Four controls fix it, and none is complicated. First, restrict creation to a defined group and provide a fast request route. The point is not gatekeeping but a moment of thought, since most duplicate Teams exist because creating one was quicker than looking for the existing one. Make the request answerable in a day, because a slow process pushes conversations into places you cannot govern.

Second, name things consistently, and agree the convention before enforcing it. Prefixes carry most of the value: Client - Name, Project - Name, department names plain. This alone prevents a meaningful share of duplicates, because people can see at a glance whether the thing they are about to create already exists.

Third, require two owners for every Team, and check that they are current people. Single-owner Teams become orphans the moment that person leaves, and orphaned sites are where permissions drift and guests outlive their welcome. Two owners is a small rule with a large effect on how much manual cleanup you face later.

Fourth, review quarterly, and keep it brief. Which Teams have had no activity in six months? Which have external guests, and should they still? Which duplicate each other? Archive rather than delete as the first move, since archiving makes a Team read-only while preserving its content and site, and deletion removes everything after a finite window. Archive generously, delete deliberately, and only once you are satisfied about retention obligations.

Guests deserve their own line in that review, because they are the part of sprawl with genuine security consequences. Every external person ever added to a Team is still there unless somebody removed them, and in most tenants nobody has. Clients whose engagements ended years ago, contractors from finished projects, occasionally someone who has since joined a competitor, all still able to open a site holding your work. Listing guests and confirming each one is reliably the most productive half-hour in the whole cleanup.

For a business that already has sprawl, the cleanup is a one-off exercise worth scheduling rather than dreading. Export the list of Teams with their owners, last activity and guest counts, which is a report your provider can produce quickly. Sort by inactivity, confirm ownership on everything still live, archive the dormant, and note anything holding material with retention obligations. A day of work usually retires a surprising proportion and, more importantly, establishes who owns what.

One structural decision prevents much of the sprawl before it starts: agree what a Team is actually for in your business. Most small businesses need Teams for departments, significant clients and major projects, and nothing else. Once that is written down, the question of whether something warrants a new Team has an answer that is not simply how strongly the person asking feels about it, and the request process becomes a two-second check rather than a judgement call.

The honest caveat is that governance imposed without explanation gets resented and routed around. Tell people why the rules exist, in terms they recognise: so you can find the right Team, so client data is not sitting in an abandoned space, so nobody inherits a mess when a colleague leaves. Rules people understand survive; rules people merely receive get worked around within a month. If you want the controls set and the existing sprawl cleaned up, call 1800 456 567.