we went through this exact mess a few months ago when we were onboarding a bigger team and nobody had really thought through who should be able to do what. It sounds boring until you're four weeks in and someone has accidentally published something to the wrong workspace or a new hire has been sitting with basically no access because nobody remembered to bump their role up from the default. The default member role is pretty limited intentionally, like search and install only, which is fine for a joe-who-started-monday situation but it's easy to forget to revisit it.

what i ended up doing was just mapping out who needed what before touching any of the settings, because otherwise you end up clicking around reactively. The breakdown we landed on basically looks like this:

the part that took us a while to realize is that workspace-level roles and org-level roles are separate, so you can give someone full access in one workspace without touching their permissions anywhere else. That's not obvious from just poking around the ui. We had someone set up like samira across everything when they really should have been like eddie, just scoped to their team's workspace.

i'm probably biased here since i work at tessl, but this isn't something we put together internally, someone else worked through the same setup and documented it and it maps pretty closely to what our team kept running into: https://tessl.io/blog/tessl-admin-guide-organizations-workspaces-and-roles/