SharePoint at 25 — Episode 1: Why We Don’t Need Naming Conventions Anymore

As SharePoint approaches its 25th birthday this March, this episode kicks off a new series focused on how the platform has evolved — and why many organisations are still working in ways that no longer serve them.

In this first episode, I tackle one of the most persistent and controversial habits in SharePoint: naming conventions.

Almost every organisation has a naming convention document. Almost no one follows it consistently. That’s not a people problem — it’s a design problem.

In this episode, I explain why naming conventions made sense in the early days of file servers and folders, why they don’t scale in modern SharePoint, and why I’ve never relied on them to make a solution work across my career. We unpack how metadata, information architecture, permissions, and structure have quietly replaced the need for filenames to carry all the meaning — and why that matters more than ever in a world of AI and Copilot.

You’ll hear real-world examples of how metadata replaces complex filenames, how to keep filenames simple and human-readable, and why governance that depends on people remembering rules is fragile by design. I also talk openly about why naming conventions are difficult to follow in practice, how cognitive load plays into this, and why automating structure leads to better outcomes than policing behaviour.

This episode sets the foundation for the rest of the series, which will cover governance, information architecture, metadata, and the design decisions that actually shape successful SharePoint environments — whether you’re preparing for Copilot, fixing an inherited mess, or building sites properly from the start.

Next episode: why governance isn’t a document you write once and file away — and why real governance has to be built into the design.

Transcript

SPEAKER_00: 0:00

Welcome to this special series on SharePoint Governance and Information Architecture. As SharePoint approaches its 25th birthday this March, I'm using this series to reflect on what's actually changed over the years and what good practice really looks like now. We'll be talking about governance, metadata, structure, and the decisions that matter if you want your environment set up properly. Whether you're preparing for copilot, fixing existing mess, or building things the right way from the start. So today I want to start with something that almost always gets a reaction. Naming conventions. This is one of those topics where most organizations feel like they should have a strong position, even if the reality doesn't quite match what's written down. Almost everyone has a naming convention document. Almost no one follows it consistently. And that disconnect is what I want to unpack in this episode. I first want to be very clear about my own position up front. Across my entire career working with SharePoint, I've never designed a solution that relied on naming conventions to function properly. Not one. That doesn't mean I haven't documented them. I have. Often because that's what a client wanted or expected. But personally, I've never built a SharePoint environment where things fell apart if someone didn't name a file in a very specific way. And there's a reason for that. Naming conventions ask people to do a lot of thinking at exactly the wrong time. You're busy, you're in the middle of the work, you just want to save a document and move on. Now you're meant to remember a format, apply it correctly, and do it the same way everyone else does every time? For me, that's never been realistic. I've always struggled to remember naming conventions. And if I'm honest, that hasn't improved with age. If I had to follow one strictly, I'd need it written in front of me at all times. And I'd have to consciously check it every single time I saved a file. That's not how people work. And governance that depends on people behaving perfectly forever is not governance. It's optimism. To be fair though, naming conventions weren't invented for no reason. They existed because file names used to be the only place you could put meaning. File servers, deep folder structures, limited search, file names had to carry everything. Document type, version, status, department, date. They were doing the job metadata does today. At the time they made sense, but we're not in that world anymore. So what's changed? Metadata, structure, and signals. So modern SharePoint has metadata, it has structure, it has permissions, it has information architecture, and now it has AI and Copilot sitting on top of all of that. Search relies on structure. Automation relies on signals. AI relies on context. And file names are one of the weakest signals you can give a system. Copilot doesn't understand what you meant when you called something final, version 7, approved, use this one. It understands metadata, permissions, currency, and relationships between content. That's where meaning lives now. So what do I use instead of naming conventions? Well, instead of naming conventions, I design the environment so file names don't have to do all the work. I use metadata to describe what a document is, not what someone happened to call it on a busy afternoon. I use information architecture so content lives in the right place to begin with. And I use permissions to control visibility and access so context is already built in before anyone opens a file. I also keep metadata deliberately minimal and relevant so it actually gets used rather than becoming another thing people work around. For example, instead of asking someone to save a file as HR policy leave approved 2024 final, I'll let the file simply be called leave policy. The meaning doesn't live in the file name, it lives in the metadata. The document type is set to policy, function is HR, status is approved, and the effective year is captured separately. The file name stays human and readable while the system understands exactly what it is, how it should be surfaced, and how it should be managed. Another common scenario is project documentation. Rather than enforcing something like financial project X, Risk Register, version 3, 2025, doc, the file might just be called risk register. The context comes from metadata, the project name, document type set to risk register, status set to current, and ownership defined through the site or library it lives in. Views then surface the right version automatically without anyone needing to remember prefixes, suffixes, or version numbers. A lot of this metadata can be automated or defaulted based on where the document lives, what library it's in, or what template was used to create it. The goal isn't to make people think harder or remember rules, it's to reduce cognitive load. When the structure is right, file names can stay simple and the system does the heavy lifting instead. This doesn't mean that file names don't matter at all. They absolutely do. For humans, people should name documents logically, in natural language, so someone else can recognize what they're looking at. Clear, descriptive, human-readable names like leave policy or risk register, not strings of codes, prefixes, dates, and version numbers designed to compensate for missing structure. The key distinction is this. File names help humans recognize content, while metadata helps systems understand it. Those are the two very different jots. Trying to force file names to do both by turning them into things like HR Policy Lead approved 2024 final or Finance Project X Risk Register Version 3 2025 is where things start to fall apart. So before we get on to the AI reality check, when would using naming conventions actually make sense? There are situations where naming conventions still make sense, but they're far more limited than most organizations assume. They tend to apply to environments where files are deliberately leaving SharePoint and moving between systems that don't share metadata. For example, when documents are exported to external regulators, courts, or legacy systems that strip context away. Legal teams are often cited here, but even then, it's usually about document packages rather than everyday working files. In most modern legal and compliance scenarios, SharePoint metadata, version history, audit logs, and retention labels provide stronger control and traceability than file names ever could. So, yes, there are cases where naming conventions help, but they're the exception, not the rule. Designing your entire environment around them, just in case, is usually a sign that metadata and information architecture haven't been fully trusted or used yet. So now it's time for the AI reality check. This conversation becomes unavoidable once you start talking about Copilot. If your AI readiness depends on people naming files perfectly, you're going to be disappointed. AI exposes wick structure very quickly. It doesn't fix mess, it reflects it back to you. And file names alone don't provide the consistency or context AI needs to work properly. That's why this topic matters now, not just as a theoretical debate, but as a practical design decision. Naming conventions aren't evil. They're just no longer the right primary control mechanism. They're a workaround from an older era that we've been reluctant to let go of. This episode is really about recognizing that the platform has evolved and our habits need to evolve with it. Letting go of naming conventions is often the first uncomfortable step toward better governance, better structure, and better outcomes. In the next episode, I'm going to build on this by talking about governance and specifically why governance isn't something you write once, file away, and never look at again. Those documents might exist, but no one reads them. And if governance only lives on paper, it doesn't actually exist. Real governance has to be built into the design of your SharePoint environment. Otherwise, it simply doesn't hold up in practice. This series is all about practical, real-world SharePoint design, not theory, not trends, and not governance documents that sit untouched in a library somewhere. If this episode made you question how you're doing things, that's where the conversation gets interesting. Make sure you subscribe because next time we're moving from naming conventions into governance and why design decisions matter far more than anything written in a document. As SharePoint approaches its 25th birthday this March, this series is about taking a hard look at how the platform has matured and whether the way we design and govern it has matured along with it. Naming conventions are just one example of a habit that made sense once but doesn't always stand up anymore. Over the coming episodes, I'll be unpacking the decisions that actually shape long-term success in SharePoint, especially as AI and Copilot raise the bar on structure, clarity, and trust. Thanks for listening, and I'll see you next time on the Simply SharePoint podcast.