In high-growth data teams, unclear data access is the enemy of speed and trust.

Done right, access management is:

• Low effort
• High impact
• Often forgotten

In this issue, I’ll walk you through how I design access management to reflect organizational strategy - so that no new hire ever has to request access again.

Why This Matters

Access and user management rarely make it into the spotlight. Most teams focus on pipelines, dashboards, or ML models. But the truth is:

The fastest way to make a data foundation useful is to make it accessible.

Smooth access is a silent enabler of data-driven work. Friction here leads to blockers, drama, and disengagement.

Good access management is not just about security. It’s about:

• Reducing onboarding time
• Preventing access drama when people change roles or leave
• Empowering teams to move fast with confidence

The best part? You can automate most of it.

Let me show you how.

Step One: Know the Roles

Access should follow structure. And that structure starts with clear roles.

In my approach, I always define access based on groups, not individuals. These groups are shaped by the organizational strategy. I use the following roles across data hubs and business domains:

• Users: Business decision-makers. They consume reports and dashboards. No editing, no publishing.
• Super Users: Advanced business users. They create simple data products (like ad hoc reports) and share them within their own teams.
• Analysts: Technical enough to build complex products. Can work in the data hub or be embedded in domains. They publish company-wide content.
• Analytics Engineers / Data Scientists: Build models, design pipelines, integrate data. Role placement depends on org structure.
• Data Engineers / ML Engineers: Integrate sources and build platforms for the roles above. Typically centralized, but decentralization is possible.

This role setup allows us to assign access rights systematically.

Step Two: Match Access to Centralization

How you manage access depends on how centralized (or decentralized) your org is.

There are three core actions users can perform:

• Read: View existing reports or dashboards
• Write: Publish new data content
• Manage: Organize folders, delete or rename files, change permissions

Each role’s access rights vary depending on the centralization level of your data team.

The Super User and User role will never sit in a central Data Hub while there will ALWAYS be Super Users and Users in business domains.

Similarly, there will typically be Analysts, Analytics Engineers and Data Engineers in a Data Hub.

Whether Analysts, Analytics Engineers and Data Engineers sit inside functions depends on the level of decentralization and can take many shapes and forms.

Let’s explore two real-world setups I use regularly.

Option 1: Semi-Centralized (Common in Scaleups)

In scaleups, I usually implement a semi-centralized system. Here’s how I set it up:

There is some form of content management system. I like to use Google Drive.

Inside it:

• A Data Hub folder for centralized work
• One folder per business domain (Finance, Operations, Marketing, Product, etc.)

Folder Types and Permissions

Each folder type has a clear purpose:

1 Verified Reports (inside Data Hub)

• Everyone can read
• Centralized analysts can write
• Admin analysts can manage

2 Ad Hoc Analysis (inside each domain)

• Everyone except Users can read
• Only Super Users in the domain can write
• One Super User acts as admin to manage content

3 Input Sources (inside each domain)

• Used for team-maintained data inputs (e.g., mapping tables)
• Only Super Users have read, write, manage rights

→ This model supports autonomy without chaos. Domain teams have freedom within boundaries.

→ Nothing is ever managed on an individual level. Individuals are assigned to groups and permissions are managed on group-level.

Option 2: Late-Stage Hub & Spoke (More Decentralized)

For more mature companies, I shift toward a hub and spoke model.

Here’s what changes:

• Each domain now has its own Verified Reports folder
• Embedded Analysts (not just centralized ones) can publish into these folders
• Folder structure remains the same, but publishing power becomes decentralized

This setup keeps the system flexible while reflecting growing team maturity.

Again, all access is managed via groups, never individuals. If a new person joins the Finance team as a Super User, they automatically get:

• Write access to Finance Ad Hoc folder
• Manage access to Finance Input Sources
• Read access to all Verified Reports

No access tickets. No Slack messages. No bottlenecks.

There are more flavors and nuances to it which I cover all in my masterclass "Create massive business impact with your data team." ​

Bottom Line

If you want your data foundation to drive real impact, fix your access management.

You don’t need a fancy tool. You need structure:

• Define clear roles (users, super users, analysts, etc.)
• Understand your org’s level of decentralization
• Build a content management structure that reflects both
• Assign read, write, manage rights based on groups, not people

The goal? New employees can access everything they need from day one. And when they leave or switch roles, access adjusts automatically.

It’s simple. It’s scalable. And it lets your team focus on what actually matters: delivering insights, not chasing permissions.

If your current setup doesn't work like this yet, now is a great time to start.