How to set up roles and permissions for a small team

Small teams tend to run one of two permission models. The first is everyone-is-an-admin, which works beautifully until the day a contractor deletes a shared folder or a departing colleague still has access three months later. The second is a spreadsheet of who-can-do-what, drawn up once during an audit and never opened again.

The middle path is boring and effective: a handful of roles, assigned deliberately, reviewed occasionally. Here is how to get there without a project.

Start from what people do, not who they are

The instinct is to map roles onto seniority. That produces access nobody needs and blocks people who do. Sort by activity instead — most people fall into four buckets:

• They produce the work — writing documents, building sheets, preparing decks. They need to create and edit.
• They react to the work — reviewing, approving, suggesting changes. They need to comment, not to edit.
• They consume the work — reading the output, sharing it onward. They need to view.
• They run the place — adding people, changing settings, cleaning up. They need to administer.

Almost everyone belongs to exactly one bucket for any given body of work, and the buckets map cleanly onto the roles most tools ship with. In Ettex they are Administrator, Editor, Commentator and Viewer, with Guest for someone who needs one document by link and nothing else.

Set it up

1. Write the list of people before you touch any settings. Include contractors, the agency, and the person who left last month — a permission review is also an exit audit.
2. Assign each person the least role that lets them do their job. Being asked for an upgrade takes seconds; discovering a deletion takes weeks.
3. Keep administrators to two. One is a bus problem, three is nobody's responsibility.
4. Invite each person with their role attached rather than granting access first and sorting it out later — the second step never happens.
5. Group people by department once the list is longer than a screen, so future reviews take minutes instead of an afternoon.
6. Put a recurring reminder in the calendar for a quarterly pass over the member list.

The rules of thumb that survive contact with reality

• One owner, always current. Ownership should follow the person actually responsible — transfer it before someone leaves, not after.
• Reviewers get Commentator. It is the single most under-used role: it invites feedback without risking the document.
• Externals get Guest or a link, never a seat. Agencies and freelancers need one project, not your workspace.
• Off-boarding is part of the process, not an afterthought. The last step of “someone left” is removing them the same day.
• Log first, argue later. A team log that records who was added, whose role changed and who was removed answers most access questions before they turn into a discussion.

What not to bother with

Small teams routinely over-engineer this. You do not need a role per department, per-document exceptions as a habit, or an approval workflow for read access. Every extra rule is one more thing that will be wrong in six months and one more reason for someone to work around the system entirely — usually by emailing a copy of the file, which is exactly the outcome permissions exist to prevent.

If a permission scheme cannot be explained to a new joiner in two minutes, it will not be followed.

Permissions are not a security project for a team of eight. They are a twenty-minute setup, a habit at joining and leaving, and one calendar reminder a quarter.