Fit access controls to your org, not the other way around

Turns out, you mostly ship your org chart. That's Conway's Law, and it applies to access controls just as much as it applies to software architecture, for better or worse.

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. —  Melvin E. Conway

Our job at Oblique isn't to tell you how your organization should be set up. It's to give you the tools to work with how it already is.

We’ve talked with a lot of organizations about access management. Although they all want to express access controls slightly differently, they’re all more similar than they are different. Your company may be special, but your org chart really isn’t all that special. For example, many organizations have a concept of a small ad hoc team working together on the same project that doesn’t necessarily map to where they sit in the org chart, whether they call it a “squad”, “pod”, or something else. The same concepts keep cropping up across organizations, although the specific implementations might differ.

Organizations mostly use one of three ways to group users together to decide who should be granted access to something:

• By department or function. For example, everyone in sales needs access to Salesforce. This is closest in spirit to role-based access control, but ironically it is often implemented using attributes, with an attribute of department or title. (In Oblique, these are attribute-based groups.)
• By manager or reporting chain. For example, everyone who reports to Samantha needs access to Zendesk, because Samantha runs customer success, which could include multiple departments like support, sales engineering, and DevRel. This is distinct from an attribute — it’s strictly about org structure. If Samantha gets promoted, the access controls follow whoever takes over her old job. (In Oblique, these are reporting groups.)
• By project. For example, everyone working on the MCP server needs access to PostHog, even though that project has engineering, as well as product, design, docs, marketing, and SRE. Often, this is tied to a specific resource rather than an application, like access to a particular Snowflake table rather than the Snowflake app. It can also be tied to a communication channel or group. (In Oblique, these are team groups.)

What an individual needs access to depends on a mix of all three group types. Although the specifics depend on the culture and org structure, almost every organization starts the same way: inherent access tied to employment status, so that all full-time employees get access to basic collaboration tools like Google Workspace and Slack. Additional access depends on what system and data is the source of truth for departments and teams — sometimes it’s the reporting chain, sometimes it’s a department or cost center attribute, and sometimes it’s a completely ad hoc, manually-managed team.

This complexity — of using multiple data sources and group types to manage access — is why access controls end up being so complicated. There are many stakeholders involved in org structure design, but IT is usually not one of them. But then IT is tasked with using an access control system that doesn’t fit reality, and so the result is a mess: groups based on data that isn’t maintained, and access that’s hard to trace and understand.

The goal with defining groups for access management is not only to make the initial setup sensible (so that you can reason about access), but also to make the system possible to maintain. Your decision depends on what data you have and where its source of truth lives. You need data that’s high fidelity, that someone is already maintaining, and that’s in a system that your access controls can integrate with, like your HRIS.

Your access control model needs to map to how your organization works, not the other way around. There is no single ‘right’ way to set up permissions using these groups. There is only the way that works for your org.