Nobody sat down and designed your Microsoft 365 estate. There was no architecture review for the shape it has today — the count of sites, the sprawl of Teams, the environments full of flows, the years of files. It wasn’t planned. It accreted, one project and one person at a time, and the result is an estate you own but never drew.
This is not a failure story. It’s the default story, and it happened to nearly everyone. The whole point of modern Microsoft 365 is that people don’t have to file a ticket to get work done. That self-service model is genuinely good — it’s why adoption succeeded. But self-service at scale, over a decade, produces an estate whose structure reflects thousands of small local decisions and no single global one. Before we can talk about anything else in this series, it’s worth being honest about how that estate actually grew.
A site, a team, a channel — created by whoever needed one
Start with SharePoint and Teams, because that’s where most of the content lives. By default in Microsoft 365, users can create their own sites, and every Microsoft 365 Group — every new Team — brings a SharePoint site with it. Microsoft documents this plainly: users can create and administer their own SharePoint sites, and “when a Microsoft 365 group is created, a SharePoint site is also created.” Spin up a Team for a project, and a site appears underneath it whether anyone thinks of it as a site or not.
That’s a feature. It’s also the origin of sprawl. Microsoft’s own Teams governance guidance is candid about the trade-off: limiting who can create teams “can slow your users’ productivity, because many Microsoft 365 services require that groups be created for the service to function.” So most organizations leave creation open — and get a Team per initiative, a channel per sub-topic, a site per Team. A five-person working group that met for six weeks in 2020 left behind a permanent site. Multiply that by a decade of working groups, reorgs, and “let’s just start a Team for this,” and the site count isn’t a number anyone chose. It’s a sediment layer.
Makers, environments, and the Power Platform layer
The same dynamic runs through the Power Platform, one level less visible. Power Apps, Power Automate, and Copilot Studio are built for makers — businesspeople automating their own work without waiting on IT. They build in environments, and environments multiply: a default environment everyone lands in, personal-productivity environments, a dev environment here, a departmental one there.
Microsoft’s environment strategy guidance exists precisely because this accumulation is the norm, not the exception — it’s a whole document devoted to imposing structure after the fact on something that grows organically. Every flow a maker builds runs under some identity, connects to some data, and keeps running long after the maker moves teams. Nobody is being careless. The platform was designed to let work happen without gatekeepers, and it did.
Sharing that defaults to reach
Layer sharing on top. When someone shares a file or folder in SharePoint or OneDrive, the link type they get is whatever the default is — and the default leans toward reach. Microsoft even documents how to change the default sharing link to “something more restrictive,” which tells you what the out-of-the-box behavior tends to be. “People in your organization with the link” is one click, requires no thought about who specifically needs the file, and gets the job done today.
Every one of those choices was rational in the moment. Sharing broadly is faster than sharing precisely; you share to unblock a colleague, not to design an access model. But links outlive their reason. The document shared org-wide for one meeting stays shared org-wide forever. Accumulate a decade of one-click “just make it work” sharing and you have an access surface no one authored and no one is tracking.
A decade, compounded
Now let time run. Each of these mechanisms — self-service sites, maker environments, default-reach sharing — doesn’t just add content; it adds content that carries its own permissions, its own owner (or, eventually, no owner), its own quiet assumption that someone, somewhere, is keeping track. A tenant we scanned had a few hundred sites and close to a million files — numbers that are entirely ordinary for an organization that has simply been using Microsoft 365 as intended for years.
None of this was negligence. Every layer was a reasonable answer to a real need: let people collaborate without friction. The friction-free estate is the product working as designed. The sprawl was a feature — sites when you need them, automation without a queue, sharing without a form.
That’s the estate you actually have. Not the one on an architecture diagram — the one that grew. Hold that picture, because it’s the ground everything else in this series stands on. We haven’t said a word yet about AI, or about any specific problem. We’ve only established the terrain: a large, organic, self-assembled estate whose shape reflects a thousand small decisions and no single design.
In the next post, we’ll turn to something genuinely exciting — the real, well-earned promise of putting AI to work on all of this content. And we’ll set up the tension the rest of the series turns on: AI doesn’t get a fresh, well-organized version of your estate. It inherits exactly the one you just read about.