Thanks for getting in touch. The permission system does not support the case you describe. As soon as a user has team edit, they can edit their own team to grant further permissions (with some major exceptions like adding the 'Administrator' permission).

The permission system is focused on restricting access to Projects and Environments (and Tenants if you use them) in combination with what you can do, e.g. Deploy Project X to Environment Y.

We are currently working on a feature we're calling Spaces that is designed to partition everything in Octopus, so teams can better self manage in their own Space, I would appreciate some more details from you about the extra level of control on permissions.

Would you end up with several roles like, "User/team manager who can..."

Create users to create and release deployments

Create users to manage Environments/Roles

Create users to create/edit accounts

Create users to edit library variables

Create users to help edit teams and roles

Would that become a management overhead?

Wouldn't you end up granting them more access over time so they didn't have to find someone else who had greater permissions?

Aren't you making it harder for these team leaders to be responsible for their area, they would often have to seek assistance from someone with higher permissions as roles and responsibilities grow and change?

So if we think about trying to solve this with Spaces. If you set up the Spaces so the owner/leader of a Space is truly responsible for what's in it, Feeds, Environments, Projects, Library Variable Sets, etc, is that enough of a security boundary? Does it sound like it would help achieve better segregation of permissions for leaders? Or is there something very specific in your organisation that is driving this desire?