Let’s not sugarcoat it.
“Admin” and “Viewer” aren’t real roles.
They’re defaults. They’re how we avoid thinking too hard about permissions in the early days.
And honestly? That’s fine—for a while.
When your team’s under 10, everyone’s wearing five hats. Trust is high. Boundaries are loose.
But then you grow.
And suddenly, weird things start to happen.
- A junior engineer has full access to prod
- A PM toggles the wrong feature flag in staging
- A new hire spends their first week waiting for “the right access”
- And your SREs? They’re stuck manually provisioning roles like it’s 2009
That’s the moment when your “move fast” RBAC starts slowing you down.
The Speed Trap We All Fall Into
Early on, speed wins. That’s the right instinct.
But giving every new hire “Admin” access just to unblock them?
That’s not a strategy. That’s duct tape.
And when you try to scale a duct-tape RBAC model?
- Onboarding becomes unpredictable
- Offboarding becomes a security risk
- Audits become guesswork
- And “security” becomes… vibes
Least Privilege Isn’t About Slowing Teams Down
It’s not about adding friction.
It’s about giving people exactly what they need—no more, no less.
And doing it in a way that’s repeatable and clean.
But here’s the thing:
Most RBAC systems weren’t designed to scale.
They weren’t even really designed at all.
They just kind of… happened.
So What Does a Scalable RBAC Setup Actually Look Like?
This doesn’t mean rolling out some enterprise identity governance suite.
It just means thinking ahead—so access becomes a system, not a fire drill.
Here’s what we’ve seen work:
- ✅ Define roles by function
Think like a system designer. Devs, PMs, SREs, Designers—each of them has predictable patterns. Build role templates around how they work. - ✅ Scope by environment
Staging is not production. Separate credentials. Always. - ✅ Split by system
Being a “Viewer” in Datadog doesn’t mean anything in GitHub. Treat every system on its own terms. - ✅ Automate onboarding
If you’re still manually assigning roles, you’re already behind. - ✅ Review quarterly
Teams shift. Projects evolve. What made sense in March may be irrelevant by July.
Why You Should Care at 20 People (Not Just 200)
Because once you pass 50, everything starts to compound:
- Security reviews get longer
- Access audits get murky
- You stop being able to answer “who can access what?” confidently
- And worst of all, you don’t know if someone has more access than they need
And here’s the kicker:
If you don’t design RBAC now, you’ll be forced to fix it later—probably during an incident.
Start small.
Think in systems.
Make access predictable before it becomes a liability.
That’s how you stay fast without getting reckless.
