Ask a small team what’s holding them back and you’ll usually hear budget, or headcount, or some tool they wish they had. Those are real. But they’re rarely the thing that’s actually costing you an hour a day.
The thing that’s costing you an hour a day is that nobody can tell at a glance what anything is.
You open a list of groups and there are four hundred of them with names like Marketing, Marketing-New, mktg_all, and Marketing (do not use). Somewhere in there are the ones that grant access to something sensitive, and they look exactly like the ones that just forward email. So every decision — can I delete this, who’s in this, is this safe to change — turns into ten minutes of digging. Multiply that across a team pulled in ten directions and you’ve lost a workday a week to a problem a naming convention would have solved.
A name is the cheapest documentation you’ll ever write
Most people think of naming conventions as tidiness. They’re not. They’re documentation that costs nothing to maintain, because it travels with the object itself.
A good scheme makes the important distinctions visible without opening anything. Security groups look different from distribution groups. A production connection doesn’t look like a test one. Power Platform objects tell you who owns them and what environment they belong to. Prefixes carry the type, suffixes carry the scope, and the middle carries the plain-English purpose. Nothing clever — just consistent.
The payoff is that a stranger, or you in eighteen months, can look at a list and read it. You don’t need to remember that GRP-0047 unlocks the finance share, because it’s called SEC-Finance-Share-RW. That’s a document you never have to write, never have to update, and never have to go looking for.
The scheme only works if the whole team uses it
Here’s the part that isn’t technical: a naming convention that half the team follows is worse than none at all, because now you can’t trust what you’re reading. A name that might be meaningful sends you back to opening everything anyway.
So getting buy-in is part of the job, not a nice-to-have. Write the scheme down in one short page — not a forty-page standards document nobody opens — and make it obvious enough to follow from memory after seeing it twice. Then bake it into the moment things get created: the request form, the template, the script. Most drift doesn’t come from disagreement; it comes from someone creating an object at 4:45 on a Friday with no idea what the convention is. Put the answer where they’re already standing.
The half everyone skips: cleanup
Naming gets the attention. Cleanup is the other half, and it’s the one that quietly never happens.
Deprecated groups stay in place because deleting things is scarier than leaving them. The old project’s objects sit there. The service account nobody’s used since the migration is still enabled. And it isn’t just directory objects — the same rot shows up wherever you look less often. Keys that were supposed to be rotated on a schedule and weren’t. Blob storage full of exports from a one-time project two years ago. Vault entries for systems that no longer exist.
Every one of those is two problems at once. It’s drag: more noise to read past, more to check, more ambiguity in every decision. And it’s attack surface — an account nobody owns and a key nobody rotated are exactly the things that don’t get noticed when they’re used.
Organization is a security control
We tend to file naming and cleanup under productivity, and security under tools — the EDR, the MFA rollout, the policy. But an estate you can read is an estate you can reason about, and reasoning about it is most of the work.
When someone asks who has access to a system, a legible estate answers in a minute. When a key gets exposed, you know what it touches. When you’re removing someone’s access, you can be confident you got all of it. A messy estate gives you none of that — not because the risk is bigger, but because it’s hidden, and the honest answer to every question is “let me check, and I’m not certain.”
Where to actually start
Most people already know all of this. The obstacle isn’t belief, it’s that there’s no time, and no obvious first move. So make the first move small.
Pick one class of object — just one. Security groups, or connections, or storage containers. Decide on a scheme for that one class, write it on a single page, and apply it to new things starting today. Don’t rename four hundred objects this week; rename them as you touch them and let the estate converge.
Then put cleanup on a cadence instead of a someday list. Thirty minutes a month, on the calendar, with a rotating target: this month stale groups, next month keys past their rotation date, the month after storage. A recurring half-hour that actually happens beats the comprehensive audit you keep planning and never start.
It’s the same discipline as writing things down
If this sounds like the argument for documenting your procedures, that’s because it is the same argument: a legible, maintained system beats heroics. The team that can read its own estate — and its own processes — doesn’t depend on the one person who remembers how it all fits together.
That’s the thinking behind Notavi, too. Whether it’s a naming scheme or a procedure, the win is the same: the next person who looks at this, including future you, can just read it.
Pick one thing to name properly this week. That’s the whole starting point.