Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify where ultimate authority for spending approval comes from #75

Closed
brianjrobertson opened this issue Jan 10, 2016 · 4 comments
Closed

Comments

@brianjrobertson
Copy link
Contributor

Currently, it takes quite a bit of constitutional interpretation gymnastics to understand how and when Lead Links have the authority to spend money (or dispose of assets more generally). This could be a hell of a lot more direct and more clear.

Here's the whole complex thread it took me to explain this awhile back (and to some really smart Holacracy-trained people!) - there's got to be a far simpler and more obvious way to structure this in the constitution!

@KoenVeltman
Copy link

very interesting, relevant (and unfortunately complex) topic. don't think I have the answer here. but do recognize it is so relevant for Holacracy run organizations.

What about just having a "default option" much so as there is a default agenda for a tactical. Whether this is constitutionally described or through one (or multiple options) app/policy that is recommended to include when you start.

@karilen
Copy link

karilen commented Apr 11, 2017

I agree and went through constitution mental gynmastics to try to figure out spending authority. With the current framework of the constitution I would make explicit that authority to act does not include authority to spend. I would suggest building it in to Article 1.3 second sentence: However, you cannot spend money you have not been allocated or exert control or cause a material impact within a Domain owned by another Role or another sovereign entity, unless you have their permission.

@gvandegrift
Copy link

As a neophyte here, I would humbly agree that this could be more clear. It was not at all clear to me that

Further, you may not transfer or dispose of the Domain itself or any significant assets within the Domain, nor may you significantly limit any rights of the Circle to the Domain. However, these restrictions do not apply if a Role or process holding the needed authority grants you permission to do so.

means

not even a Lead Link has the authority to dispose of resources (i.e. spend money), even if there were an explicit Domain at play on that role, unless a Policy ultimately allows it ­ because delegating a Domain never delegates the right to dispose of resources within the Domain by default

Doesn't that mean that the policy is somehow stronger than the domain itself? Is that true? It sort of feels like there's another top-level entity here--something like "Resource" that has its own governing principles. Either that, or Domains should allow for disposal. I would equate it to owning web-site infrastructure. If that's my role's domain, don't I have the right to decommission (i.e., dispose of ) virtual machines without going to the Lead Link of the anchor circle (barring a policy that covers that)?

Sorry to distract if I'm way off in my understanding.

@ghost
Copy link

ghost commented Jun 30, 2017

I'm a latecomer to this thread.

I'd like to verify my logic. Is it true to say that:

Article 2.2 refers to the Lead Link Role as defined in Appendix A but does not otherwise specify how the Lead Link Role allocates resources.

Article 4.2 says that the Anchor Circle "automatically controls all Domains that the Organization itself controls," implying that, since the Organization's resources are a Domain, the Anchor Circle inherits that Domain.

Further, Appendix A says "The Lead Link also holds all un-delegated Circle-level Domains and Accountabilities," so the Anchor Circle Lead Link holds the purse.

So, unless the Anchor Circle says otherwise, the Anchor Circle Lead Link has exclusive spending authority in the Organization.

Did I get that correctly?

brianjrobertson added a commit that referenced this issue Jul 9, 2017
brianjrobertson added a commit that referenced this issue Sep 4, 2018
Realized this was still not as clear as it could be; hopefully making
it pretty damn clear now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants