[SCP-TBD] Updated Definition of a Workstream Leader

[pastaghost]

This post comes in response to [SCP-92] - Definition of a Workstream Leader. It is the belief of some from the community that the scope of authority granted to Workstream Leaders under this definition is overly broad, and inadequate checks and balances to the authority and autonomy granted to Workstream Leaders by this definition are given. An updated Workstream Leader definition with a more appropriate set of checks and balances to Workstream Leader authority is proposed below.

Summary

This proposal clearly defines a Workstream Leader.

Abstract

• This proposal explicitly defines the roles, responsibilities, and authority of a Workstream Leader, as it relates to

  The authority to hire and fire within a workstream

• Discretion over the allocation of a budget approved by governance
• Policy for removing a Workstream Leader

In addition to this proposal, workstreams are encouraged to expediently adopt a Workstream Charter which outlines the team structure, working agreements, team policies, and may supersede the resourcing and budget sections of this document. In the absence of a Workstream Charter at the time the workstream becomes eligible for renewal, only the terms outlined in this document will apply. Should this proposal pass, the Workstream Leader definition provided herein shall override any previous Workstream Leader definition. Future proposals that create, renew, or amend workstreams will adopt this definition of a Workstream Leader by default unless explicitly defined otherwise.

Motivation

There does not currently exist an explicit definition of a Workstream Leader as approved by governance. This proposal seeks to formalize an agreed-upon definition of a Workstream Leader, including roles, responsibilities, and authority. Workstream leaders are granted some degree of both authority and autonomy by the DAO. As such, it is essential to ensure that the aims of Workstream Leaders are at all times aligned with the best interests of the DAO through an equitable system of checks and balances against this authority and autonomy.

The ShapeShift DAO is a community-led organization. Workstream Leaders are elected to serve the interests of the community by implementing community-generated strategic decisions within the bounds of the scope of their responsibility as stated in the proposal instantiating the workstream(s) they represent.

Specification

Resourcing

The Workstream Leader shall be delegated the authority by governance to make decisions pertaining to resourcing, that is, how the funds allocated to the workstream are used to provide the services and meet proposed goals, including hiring and firing of workstream contributors. The Workstream Leader may undertake a hiring or firing action without independent consultation of the Workstream Contributors during the process; however, the Workstream Leader must notify all Workstream Contributors of the action immediately after such a decision has been made. Subsequent to this notification, a >50% majority of Workstream Contributors may raise an objection to this action by forum post and make an appeal for the action to be decided by governance. In this case, the action taken by the Workstream Leader shall take no effect until the governance process has concluded.

Budget

A workstream budget shall be submitted along with each workstream proposal to inform the DAO as to how treasury funds allocated to the workstream will be spent. The Workstream Leader shall be delegated the authority by governance to have full discretion over how an approved budget is spent within the bounds of that which is explicitly outlined in the proposal establishing the workstream. The Workstream Leader is expected to adhere to the spending plan approved by the DAO, however, budgets need not be overly specific, and Workstream Leaders are encouraged to add line items for discretionary and contingency funds to allow for the workstream to cover unanticipated expenses during the lifetime of the proposal without requiring a budget amendment to pass governance. The Workstream Leader shall not be able to spend more than the approved budget without a proposal to amend said budget. Budgetary decisions affecting funds allocated to Workstream Contributors are considered resourcing decisions and so are subject to the same provisions in the Resourcing section above or as dictated by superseding Workstream Charter, where applicable. The Workstream Leader shall be responsible for coordinating with DAO treasury multi-sig signers to ensure sufficient funds are made available in Colony to ensure expenses can be paid monthly or on-demand. On the 1st of each month, the Workstream Leader shall be responsible for submitting an accounting report to the DAO showing the actual funds spent during the previous month.

Consideration of Organizational Impact

The DAO is an integrated structure containing several workstreams that operate in parallel but are not orthogonal in scope or interaction. it is possible that situations may arise where a decision made by a Workstream Leader has side effects that negatively impact other workstreams, carry an outsized risk to the success of, or have a disproportionately large effect on the strategic direction of the organization as a whole. To avoid these situations, Workstream Leaders may request a consideration of organizational impact by a forum post, where the appropriateness of the decision in question will be evaluated by governance. In this case, the decision called to question shall take no effect until the governance process has concluded. A consideration of organizational impact may also be raised by a contingent of community members by staking a total of one million (1,000,000) FOX in support of a motion created on Snapshot within a five (5) day window. This governance mechanism has the potential to cause significant difficulty to the operation should it be abused, and so this should only be used rarely, in cases where there is a significant risk to the continued successful operation of one or more workstreams or to the organization in its entirety.

Removal of a Workstream Leader

Standard Governance

At any time, a Workstream Leader may be nominated for removal by a proposal. Should the proposal calling for the removal of the Workstream Leader pass governance, an amendment to the original workstream proposal naming a new Workstream Leader and making any necessary budgetary reallocations shall be submitted by the remaining Workstream Contributors from the affected workstream. In the event that a replacement Workstream Leader nomination cannot be decided upon by the Workstream Contributors, the new Workstream Leader shall be elected from a list of candidates supplied to the community by the remaining Workstream Contributors on the affected workstream through governance.

Declaration of “No Confidence”

If, at any time, a >50% majority of Workstream Contributors on a workstream announces a declaration of ‘no confidence in their Workstream Leader by way of a forum post, a decision to remove the Workstream Leader will be made by the community through governance (this is to be replaced with the expedited governance process which has not yet been officially defined.) During the time that removal of the Workstream Leader is being considered by the community, autonomy over resourcing and budget decisions is suspended, pending the outcome of the vote. Should the proposal calling for the removal of the Workstream Leader pass governance, an amendment to the original workstream proposal naming a new Workstream Leader and making any necessary budgetary reallocations shall be submitted by the remaining Workstream Contributors. In the event that a replacement Workstream Leader nomination cannot be decided upon by the remaining Workstream Contributors on the affected workstream, the new Workstream Leader shall be elected from a list of candidates supplied to the community by the remaining Workstream Contributors on the affected workstream through governance (this is to be replaced with the expedited governance process which has not yet been officially defined.)

Leave of Absence

In the event that a Workstream Leader must take a planned or unplanned leave of absence, the Workstream Leader has the authority to appoint an Interim Workstream Leader to assume all responsibilities of the original Workstream Leader during the leave. The Interim Workstream Leader shall assume the role entirely, and is subject to all provisions outlined in this document.

Benefits

An explicitly defined and shared understanding of how workstreams and their leaders operate will remove the ambiguity that currently exists within the DAO. An adequate system of checks and balances on the authority and autonomy granted to Workstream Leaders minimizes the centralization risk associated with the creation of the role and ensures that the DAO continues to be led ultimately by the community.

Drawbacks

There is an inherent centralization risk associated with the delegation of any power or responsibility to a small group of individuals and an additional risk in the possibility of collusion between these individuals to make organization-wide strategic decisions outside governance. Hopefully, the provisions outlined in this document stand to minimize these risks by giving some recourse to the community should concerns arise.

[con5cience]

Looks like a very solid foundation. Some points I’d like to see clarified:

For completeness, can you separately itemize the perceived differences between this proposal and the one 0xDefi submitted?

If the Workstream Leader has the authority to (de)allocate budget on-demand, but doesn’t have full hire/fire authority, what’s to stop them from just “fixing the glitch” by de-allocating funds from an engineer and “letting it work itself out naturally”? Conversely, are there any provisions for an engineer that wants to be a Core Dev but doesn’t really care if they get paid? Is getting paid the only incentive or differentiator for being a Core Dev? Those last two bits are off-topic fo sho but it would be good to have shared context.

Probably want to better quality the “must immediately notify everyone after the decision has been made” bit, like what method and acceptable timeframe for that sort of thing. I expect that notifying the “everyone” group on Discord in the

• channel at 3am local time after waking up from a night terror in a pool of anxiety-ridden sweat is not a great way to do that, for example.
• Much like refactoring via method extraction in software development, I’d call out the workflow for appealing decisions via forum post and moving that to governance in a separate section and invoke references to that where appropriate, just so that process is clear and consistent across implementations.
• How are any of the community overrides, if passed via governance, to actually be enforced at a technological level? Other than bad optics, what’s to stop a Workstream Leader from saying “nah” and not complying in any fashion?
• How does a Workstream Leader formally bless an Interim Leader with the permissions necessary to execute on their behalf during a Leave of Absence?
• Should there be any objective, measurable success metrics around the Leader role? If so, what are they, and how are they used in combination with a No Confidence motion or other community override of a Leader’s decision?

[Major_Hayes]

those are good questions and it goes to show how easy it is to have ambiguity in written communication.

[Giantkin]

• missing an option in the above poll. 1 this , 2 previous. add 3) neither.

  im in a call, so have to read everything better ofc. but i noticed this in skimming.

also, it sounds like ‘charter’ is diff than proposal? i was thinking it meant the same thing in this case.

[Major_Hayes]

• It should add the definition of a charter. My expectation would be that a proposal would be made that would define the Workstream Charter, as opposed to the Workstream creating a charter internally without a governance vote.

[Major_Hayes]

con5cience:

If the Workstream Leader has the authority to (de)allocate budget on-demand, but doesn’t have full hire/fire authority, what’s to stop them from just “fixing the glitch” by de-allocating funds from an engineer and “letting it work itself out naturally”?

Currently, someone can make a request in colony and stake FOX to be paid. The remedy would be to submit a colony request to get paid. If the leader objects to the request, then at least the person can bring that up as part of a “no confidence” or governance vote.

Does anyone have any suggestions for an alternative option? Maybe in the case of a “no confidence” vote, that would trigger the treasury to send budget allocation to a different person/address that would be the designated interim leader?

[jonisjon]

Thank you for posting this alternative definition for the community to consider.

I agree with some of the feedback posted already, and I think some sort of direct comparison of the differences with 's proposal would be helpful to understand for the community to consider.

A few specific comments on this proposal:

mcchadwick:

In addition to this proposal, workstreams are encouraged to expediently adopt a Workstream Charter which outlines the team structure, working agreements, team policies, and may supersede the resourcing and budget sections of this document. In the absence of a Workstream Charter at the time the workstream becomes eligible for renewal, only the terms outlined in this document will apply. Should this proposal pass, the Workstream Leader definition provided herein shall override any previous Workstream Leader definition. Future proposals that create, renew, or amend workstreams will adopt this definition of a Workstream Leader by default unless explicitly defined otherwise.

In order for the workstream charter language to be in this, we probably need to provide the community some examples of what a charter looks like. I think it may be better to simply state that workstreams can override this definition with their own specific proposals more broadly, whether that comes in the form of a charter or as part of their workstream proposal, that doesn’t have to be defined here necessarily as long as its clear governance can always override the definition in specific cases.

In addition, for the same reasons I argued for the other definition, I think this proposal should have a clear timeline of when it goes into effect if approved by governance, I think it should be immediate but something like the 14 days proposed in the other case is reasonable too, but I don’t think it should wait for renewal of workstreams because that could mean 4-6 months of ambiguity in the case of a number of current workstreams.

mcchadwick:

Resourcing

The Workstream Leader shall be delegated the authority by governance to make decisions pertaining to resourcing, that is, how the funds allocated to the workstream are used to provide the services and meet proposed goals, including hiring and firing of workstream contributors. The Workstream Leader may undertake a hiring or firing action without independent consultation of the Workstream Contributors during the process; however, the Workstream Leader must notify all Workstream Contributors of the action immediately after such a decision has been made. Subsequent to this notification, a >50% majority of Workstream Contributors may raise an objection to this action by forum post and make an appeal for the action to be decided by governance. In this case, the action taken by the Workstream Leader shall take no effect until the governance process has concluded.

This section mostly seems reasonable to me, but im not sure about supporting this “appeal” process when a contributor is let go. IMO the proper check on the leader is governance and maybe the no-confidence vote later defined in this, I don’t think allowing a workstream of 2 people for example to question the leader letting someone go this way to make a ton of sense. It also gets more complicated if multiple contributors are let go, is there a process for each person or the group as a whole? I would prefer to see this particular check removed from this, or at the very least it should be raised to a supermajority here of 66%, as I think 50% is too low a threshold to question a firing.

mcchadwick:

The Workstream Leader shall be delegated the authority by governance to have full discretion over how an approved budget is spent within the bounds of that which is explicitly outlined in the proposal establishing the workstream.

Im not sure this language really adds anything and may just add confusion vs the other definition proposed. I would prefer this language to remain broad discretion for the WS leader to spend their budget however they wish, with the caveat that specific proposals may decide to limit that further (and governance can always override anything so it almost doesn’t need to be said).

mcchadwick:

The Workstream Leader is expected to adhere to the spending plan approved by the DAO, however, budgets need not be overly specific, and Workstream Leaders are encouraged to add line items for discretionary and contingency funds to allow for the workstream to cover unanticipated expenses during the lifetime of the proposal without requiring a budget amendment to pass governance.

Not sure we need this really either. I personally view proposed budgets as plans proposed to the DAO but that are subject to change (within the budget approved) based on discretion of the WS leader. I want to encourage WS leaders to be as detailed as possible in their budget forecasts without trying to set them in stone or take away the ability to make changes as things change.

mcchadwick:

Consideration of Organizational Impact

The DAO is an integrated structure containing several workstreams that operate in parallel but are not orthogonal in scope or interaction. it is possible that situations may arise where a decision made by a Workstream Leader has side effects that negatively impact other workstreams, carry an outsized risk to the success of, or have a disproportionately large effect on the strategic direction of the organization as a whole. To avoid these situations, Workstream Leaders may request a consideration of organizational impact by a forum post, where the appropriateness of the decision in question will be evaluated by governance. In this case, the decision called to question shall take no effect until the governance process has concluded. A consideration of organizational impact may also be raised by a contingent of community members by staking a total of one million (1,000,000) FOX in support of a motion created on Snapshot within a five (5) day window. This governance mechanism has the potential to cause significant difficulty to the operation should it be abused, and so this should only be used rarely, in cases where there is a significant risk to the continued successful operation of one or more workstreams or to the organization in its entirety.

This seems to add more confusion than anything IMO, I would prefer this section is struck entirely. The expectation should be WS leaders take the whole DAO into consideration in their decisions, but I don’t think we need a formal process here as if a WS leader makes decisions governance disagrees with there are ample ways to remove them. Anyone can post on the forum for feedback at anytime, I don’t think we need this section to formalize anything.

mcchadwick:

Declaration of “No Confidence”

If, at any time, a >50% majority of Workstream Contributors on a workstream announces a declaration of ‘no confidence in their Workstream Leader by way of a forum post, a decision to remove the Workstream Leader will be made by the community through governance (this is to be replaced with the expedited governance process which has not yet been officially defined.) During the time that removal of the Workstream Leader is being considered by the community, autonomy over resourcing and budget decisions is suspended, pending the outcome of the vote. Should the proposal calling for the removal of the Workstream Leader pass governance, an amendment to the original workstream proposal naming a new Workstream Leader and making any necessary budgetary reallocations shall be submitted by the remaining Workstream Contributors. In the event that a replacement Workstream Leader nomination cannot be decided upon by the remaining Workstream Contributors on the affected workstream, the new Workstream Leader shall be elected from a list of candidates supplied to the community by the remaining Workstream Contributors on the affected workstream through governance (this is to be replaced with the expedited governance process which has not yet been officially defined.)

While I do not think it is necessary, I am good with this as an additional check on WS leaders. 50% may be too low of a threshold, perhaps it should be 60% at least? Don’t feel strongly about that, but this process should be clearly defined before going up to any vote.I like giving the contributors some mechanism to vote no confidence in a particular leader and then letting governance decide from there in some sort of expedited process.

[Josh_shapeshiftdemo]

Thanks for giving us more to debate on with this important topic.

jonisjon:

While I do not think it is necessary, I am good with this as an additional check on WS leaders. 50% may be too low of a threshold, perhaps it should be 60% at least? Don’t feel strongly about that, but this process should be clearly defined before going up to any vote.I like giving the contributors some mechanism to vote no confidence in a particular leader and then letting governance decide from there in some sort of expedited process.

I can see the use of a “no confidence” vote in the workstream that then goes to community governance. When I read this, my first thought was also 50% was too low, and I preferred something more like 75%. Kind of like to actually remove a US President you need 2/3 majority in the Senate. So maybe, that threshold then, 2/3, or 66% vote inside the workstream needed for no confidence.

I agree with ’s comments about the potential confusion that could be caused by some of the sections that he pointed out, and better to give more authority that is clearer to the WS Leader by default.

Any workstream proposal can create a charter that limits the leader’s authority more, if they so choose. I’d rather experiment at the workstream level with charters, and if we see a leader definition in action that is working rather well that can scale, then consider amending the default definition to include that.

Those are my first thoughts. Will post more an I consider this further.

[0xean]

thanks for getting an alternate definition posted. Generally, I find this alternative currently overly complicated and don’t personally see the benefit of much of the additional complexity. It would seem that there are also several edge cases in the proposal that will lead to bad outcomes, slow decision making and ultimately the community having to vote on topics they will not be properly informed on. I am much more in favor of delegating authority to trust work stream leaders, keeping work streams small to limit their power, and the terms short to allow governance to hold them accountable.

Here are some additional questions/comments that I think should be addressed explicitly in the proposal

Subsequent to this notification, a >50% majority of Workstream Contributors may raise an objection to this action by forum post and make an appeal for the action to be decided by governance. In this case, the action taken by the Workstream Leader shall take no effect until the governance process has concluded.

1. Does the terminated contributors vote count in this 50%?
2. What happens when the workstream is made up of 1 contributor? do they count as quorum for this vote? What about 2?
3. In the event that this occurs we are now asking governance to vote on the retention of a contributor and they most likely will have no insight into their performance. So now we are in a place where a work stream leader has to publicly demonstrate that persons poor performance in front of the community. For many leaders this will not be a path they will choose and we will end up with an immense amount of friction to let anyone go in the future. It will become harder to fire someone than it is at a corporation. If a contributor or group of contributors feels that the worstream leader is making that large of an error, the contributors could self organize into a new workstream and proposal. This seems a much more reasonable path.

I do believe the no-confidence piece of this proposal could be worthwhile to implement, but would also like to see the threshold raised to 2/3rds majority and a minimum number of contributors to establish quorum be set to 5 or more.

[willy]

Thank you for posting this and for all of the time and energy you’ve invested.

I understand the intent behind this definition, but personally find it unnecessarily complicated and have concerns about implementing this in practice. I prefer the simpler definition drafted by that grants default authority to workstream leaders to move quickly while still offering plenty of opportunity for the definition to be modified and/or for any community member to appeal, regardless of what % of the workstream disagree and without any modifications to our existing gov process.

Some quick notes on why I think this is unnecessarily complex:

Standard Governance

At any time, a Workstream Leader may be nominated for removal by a proposal. Should the proposal calling for the removal of the Workstream Leader pass governance, an amendment to the original workstream proposal naming a new Workstream Leader and making any necessary budgetary reallocations shall be submitted by the remaining Workstream Contributors from the affected workstream. In the event that a replacement Workstream Leader nomination cannot be decided upon by the Workstream Contributors, the new Workstream Leader shall be elected from a list of candidates supplied to the community by the remaining Workstream Contributors on the affected workstream through governance.

We already have a path for this and don’t need to add any additional requirements. A proposal can be made to remove a WS leader, appoint a new WS leader, or create a separate workstream. Anyone can make these proposals, and I think the flexibility we have in place is beneficial. No extra requirements or definitions required.

Declaration of “No Confidence”

If, at any time, a >50% majority of Workstream Contributors on a workstream announces a declaration of ‘no confidence in their Workstream Leader by way of a forum post, a decision to remove the Workstream Leader will be made by the community through governance (this is to be replaced with the expedited governance process which has not yet been officially defined.) During the time that removal of the Workstream Leader is being considered by the community, autonomy over resourcing and budget decisions is suspended, pending the outcome of the vote. Should the proposal calling for the removal of the Workstream Leader pass governance, an amendment to the original workstream proposal naming a new Workstream Leader and making any necessary budgetary reallocations shall be submitted by the remaining Workstream Contributors. In the event that a replacement Workstream Leader nomination cannot be decided upon by the remaining Workstream Contributors on the affected workstream, the new Workstream Leader shall be elected from a list of candidates supplied to the community by the remaining Workstream Contributors on the affected workstream through governance (this is to be replaced with the expedited governance process which has not yet been officially defined.)

Similarly, we already have a path for any community member to make a proposal to remove a Workstream Leader, regardless of what % of the workstream disagrees with the Leader, and this path doesn’t require any additions to our gov process, which many already find complicated. Further, if a workstream leader is making a decision to stop allocating funds to contributors, I think the ideal path for those contributors is to propose a separate workstream, either in addition or as a replacement. Our existing gov process already covers this.

Resourcing

The Workstream Leader shall be delegated the authority by governance to make decisions pertaining to resourcing, that is, how the funds allocated to the workstream are used to provide the services and meet proposed goals, including hiring and firing of workstream contributors. The Workstream Leader may undertake a hiring or firing action without independent consultation of the Workstream Contributors during the process; however, the Workstream Leader must notify all Workstream Contributors of the action immediately after such a decision has been made. Subsequent to this notification, a >50% majority of Workstream Contributors may raise an objection to this action by forum post and make an appeal for the action to be decided by governance. In this case, the action taken by the Workstream Leader shall take no effect until the governance process has concluded.

I can understand the logic here though and would be open to this if threshold was increased to 2/3 as suggested. However, I’m not sure it’s necessary and prefer to give workstream leaders authority to act quickly in their decisions to allocate resources, and then if any community member objects they are welcome to propose whatever they’d like to override the Workstream Leader’s action.

Consideration of Organizational Impact

The DAO is an integrated structure containing several workstreams that operate in parallel but are not orthogonal in scope or interaction. it is possible that situations may arise where a decision made by a Workstream Leader has side effects that negatively impact other workstreams, carry an outsized risk to the success of, or have a disproportionately large effect on the strategic direction of the organization as a whole. To avoid these situations, Workstream Leaders may request a consideration of organizational impact by a forum post, where the appropriateness of the decision in question will be evaluated by governance. In this case, the decision called to question shall take no effect until the governance process has concluded. A consideration of organizational impact may also be raised by a contingent of community members by staking a total of one million (1,000,000) FOX in support of a motion created on Snapshot within a five (5) day window. This governance mechanism has the potential to cause significant difficulty to the operation should it be abused, and so this should only be used rarely, in cases where there is a significant risk to the continued successful operation of one or more workstreams or to the organization in its entirety.

Agree with ’s thoughts on this and would prefer for this section to be struck entirely as our existing gov process already handles this.

In general, I prefer to give Workstream Leaders default power, and then if the community thinks the leader is doing a bad job, they can remove or replace the leader rather than forcing the leader to do (or not do) something.

[Giantkin]

From what i read… this proposal basically says “put the leader of each ws, with ability to hire, but never fire. but able to be fired.” This makes it harder to hire ppl. and i already have an extremely hard time letting ppl go.

[pastaghost]

Hi ,

Thanks for helping me firm up the language here. These are all great points and should absolutely be clarified.

con5cience:

For completeness, can you separately itemize the perceived differences between this proposal and the one 0xDefi submitted?

Absolutely. I’ll get something drawn up shortly.

con5cience:

If the Workstream Leader has the authority to (de)allocate budget on-demand, but doesn’t have full hire/fire authority, what’s to stop them from just “fixing the glitch” by de-allocating funds from an engineer and “letting it work itself out naturally”? Conversely, are there any provisions for an engineer that wants to be a Core Dev but doesn’t really care if they get paid? Is getting paid the only incentive or differentiator for being a Core Dev? Those last two bits are off-topic fo sho but it would be good to have shared context.

I tried to account for this case with the “Budgetary decisions affecting funds allocated to Workstream Contributors are considered resourcing decisions and so are subject to the same provisions in the Resourcing section above or as dictated by superseding Workstream Charter, where applicable" clause in the budget section of the original post. If this is insufficient or unclear, I can definitely revise it.

Regarding the questions about unpaid Core Devs or unpaid Workstream Contributors generally, I think it’s probably a good idea to consider the Core Dev/Workstream Contributor designations to be independent of pay rate. There is no distinction between Workstream Contributors by salary range currently, so an unpaid Core Dev or Workstream contributor officially added to a workstream roster is a full member of the workstream with a salary of $0.00. Part of the motivation for allowing groups of Workstream Contributors to make motions for Consideration of Organizational Impact or No Confidence motions is because of the domain-specific context Workstream Contributors have about the ongoings of their own workstreams that is unlikely to be shared outside the workstream. This context comes from being an official contributing member of a workstream and has nothing to do with their pay rate. That said, I think the same provisions should apply to all Workstream Contributors, paid or unpaid.

con5cience:

Probably want to better quality the “must immediately notify everyone after the decision has been made” bit, like what method and acceptable timeframe for that sort of thing. I expect that notifying the “everyone” group on Discord in the channel at 3am local time after waking up from a night terror in a pool of anxiety-ridden sweat is not a great way to do that, for example.

That’s a good point – with no timeframe or mechanism specified, it would be allowable for an unscrupulous Workstream Leader to technically satisfy this requirement in ways that do not accomplish the objective. How about “…the Workstream Leader must notify all Workstream Contributors by DAO contributor email, during normal business hours for the Workstream Leader, and no longer than 24 hours after such a decision has been made.” ?

con5cience:

Much like refactoring via method extraction in software development, I’d call out the workflow for appealing decisions via forum post and moving that to governance in a separate section and invoke references to that where appropriate, just so that process is clear and consistent across implementations.

Are you saying that it would be better to move the “Consideration of Organizational Impact” and “Declaration of No Confidence” sections to a separate document and indicate in this document that Workstream Leaders shalle be subject to those provisions?

con5cience:

How are any of the community overrides, if passed via governance, to actually be enforced at a technological level? Other than bad optics, what’s to stop a Workstream Leader from saying “nah” and not complying in any fashion?

For this, I think it’s worth adding a primary mandate to the definition of a Workstream Leader. Any violation of the primary mandate is grounds for removal of a Workstream Leader. That mandate should maybe include something along the lines of, “Workstream Leaders are expected to abide by directives received from the DAO, and to align their efforts with the objectives, priorities, and interests of the DAO in a timely manner and to the best of their ability.” What do you think? Is there anything else that a Workstream Leader mandate should include?

con5cience:

How does a Workstream Leader formally bless an Interim Leader with the permissions necessary to execute on their behalf during a Leave of Absence?

Blessing an Interim Leader with the necessary permissions would probably require at least some permissions modifications in Colony and role additions in Discord. Currently, that would require assistance from both and . In the case of the engineering workstream, Interim Leader permissions would need to be updated in GitHub, CircleCI, etc. That would require assistance from the Workstream Leader prior to taking leave.

con5cience:

Should there be any objective, measurable success metrics around the Leader role? If so, what are they, and how are they used in combination with a No Confidence motion or other community override of a Leader’s decision?

Success metrics around the Workstream Leader role would be, at minimum, continual compliance with the primary mandate. Violations of the primary mandate would constitute grounds for removal by either standard governance or a No Confidence motion from inside the workstream. As far as performance metrics go, the effectiveness of a Workstream Leader would have to be evaluated in comparison to the KPIs and deliverables specified in the workstream proposal, under consideration of external factors that may reasonably hinder a Workstream Leader’s ability to meet the goals originally set. For example, the current market conditions are affecting performance for many workstreams currently, and that is out of anyone Workstream Leader’s control. Violations of the primary mandate aside, I think that it has to be left for the community to decide whether or not Workstream Leaders are being reasonably effective. The intent of the option to allow the community to override Workstream Leader decisions via a motion for Consideration of Organizational Impact was to provide a mechanism to correct the action of a well-intentioned, but incorrect Workstream Leader with no fault being attributed to the Workstream Leader in that case. An unreasonable number of approved community overrides in a single budget cycle is reasonable grounds to issue a No Confidence motion or to make a case for removal by standard governance. Likewise, making an unreasonable number of No Confidence motions which go unapproved in a single budget cycle as a Workstream Leader or a Workstream Contributor in one of any number of groups is grounds for removal or termination. In either of these cases, the community would decide whether or not to remove the Workstream Leader by examining the evidence presented in the motion.

[pastaghost]

Hi ,

Thanks for reading over this and providing well-considered feedback.

jonisjon:

In order for the workstream charter language to be in this, we probably need to provide the community some examples of what a charter looks like. I think it may be better to simply state that workstreams can override this definition with their own specific proposals more broadly, whether that comes in the form of a charter or as part of their workstream proposal, that doesn’t have to be defined here necessarily as long as its clear governance can always override the definition in specific cases.

I think you’re right about needing to provide at least an example of a workstream charter if it is referenced in the above definition. The portion that I wanted to be clear about is that the resourcing and budgetary discretion sections should be overridable, but Workstream Leaders should not be able to override the checks on authority and community override mechanisms outlined in the document. What do you think about, “Workstreams may provide, in a separate document approved by governance or as part of the workstream proposal, an agreed upon set of terms which supersede the resourcing and budget sections of this document. In the absence of any such superseding terms, only those outlined in this document shall apply.”?

jonisjon:

In addition, for the same reasons I argued for the other definition, I think this proposal should have a clear timeline of when it goes into effect if approved by governance, I think it should be immediate but something like the 14 days proposed in the other case is reasonable too, but I don’t think it should wait for renewal of workstreams because that could mean 4-6 months of ambiguity in the case of a number of current workstreams.

We definitely don’t want to prolong the period of ambiguity. I am fine with adding language to specify that this definition is to take immediate effect should the proposal pass.

jonisjon:

This section mostly seems reasonable to me, but im not sure about supporting this “appeal” process when a contributor is let go. IMO the proper check on the leader is governance and maybe the no-confidence vote later defined in this, I don’t think allowing a workstream of 2 people for example to question the leader letting someone go this way to make a ton of sense. It also gets more complicated if multiple contributors are let go, is there a process for each person or the group as a whole? I would prefer to see this particular check removed from this, or at the very least it should be raised to a supermajority here of 66%, as I think 50% is too low a threshold to question a firing.

I do think it’s worthwhile to keep some form of appeals process in place for workstream contributors who feel they have been wrongfully terminated. Traditional companies have HR departments who can assist in situations where unreasonable conflict has arisen between managers and their direct reports, cases where discrimination is alleged, etc. We have no such mechanism to mediate or remedy these sorts of interactions prior to a potential wrongful termination, so I think that at the very least we should allow an aggrieved contributor a formal process to make a case to the community, even in the case of a workstream with only one contributor. Consider it this way – what is the cost of reviewing a frivolous appeal? In my case, perhaps an hour of my off-the-clock time to read and comment in a forum post. The cost to me and to the DAO in terms of productivity is potentially much higher should we wrongfully lose a valuable contributor who has no means to appeal the termination.

If multiple contributors are let go, there are potentially four options to be taken: each contributor could appeal their individual firing should a sufficiently large group of workstream contributors support the appeal, a No Confidence motion could be made if the terminated group is large enough or another Workstream Leader objects, a no-fault motion for Consideration of Organizational Impact could be raised if the terminated group is large enough, or any member of the DAO at all could put forth a proposal calling for the Workstream Leader to be removed and the Workstream Contributors to be reinstated.

jonisjon:

Im not sure this language really adds anything and may just add confusion vs the other definition proposed. I would prefer this language to remain broad discretion for the WS leader to spend their budget however they wish, with the caveat that specific proposals may decide to limit that further (and governance can always override anything so it almost doesn’t need to be said).

Not sure we need this really either. I personally view proposed budgets as plans proposed to the DAO but that are subject to change (within the budget approved) based on discretion of the WS leader. I want to encourage WS leaders to be as detailed as possible in their budget forecasts without trying to set them in stone or take away the ability to make changes as things change.

The objective is to encourage Workstream Leaders to be as detailed as is reasonable without writing budgets into their workstream proposals that mislead or provide false expectations to the community during the approval process. Maybe the expectation is something that we could add to a Workstream Leader primary mandate instead and leave it up to the Workstream Leader to exercise proper judgment there?

jonisjon:

This seems to add more confusion than anything IMO, I would prefer this section is struck entirely. The expectation should be WS leaders take the whole DAO into consideration in their decisions, but I don’t think we need a formal process here as if a WS leader makes decisions governance disagrees with there are ample ways to remove them. Anyone can post on the forum for feedback at anytime, I don’t think we need this section to formalize anything.

My intent here is to provide a mechanism for the DAO to override a particular decision made by a workstream leader with no fault attributed to the Workstream Leader in the process. The concern is that removal of a Workstream Leader is much too blunt an instrument to use effectively. If a well-intentioned but incorrect Workstream Leader makes a decisions that the community largely disagrees with, I don’t see any reason why the community should be left with only the two undesirable options of accepting the results of the poor decision or removing a Workstream Leader who might otherwise be a valuable asset to the DAO. Consider also this hypothetical case – with a currently very unpopular decision to lay off more than half the engineering staff pending, what if the current engineering workstream leader were to, two months from now, decide to lay off the remaining engineers leaving only himself. What would the DAO do then, spend the time in governance to remove him after the second round of layoffs? It is a completely plausible outcome in that scenario that the DAO could be left in a position with no engineering resources at all, when there would have been the possibility to course-correct quickly through expedited governance even before the first round of layoffs if there was a process through which the community could express its intent and override what it saw to be a poor decision. With this mechanism, I think the community can exercise more fine-grained control over the direction of the DAO, and we should endeavor to always be aligned with the interests of the broader community.

jonisjon:

While I do not think it is necessary, I am good with this as an additional check on WS leaders. 50% may be too low of a threshold, perhaps it should be 60% at least? Don’t feel strongly about that, but this process should be clearly defined before going up to any vote. I like giving the contributors some mechanism to vote no confidence in a particular leader and then letting governance decide from there in some sort of expedited process.

From my point of view, if 50% of the contributors on a workstream are sufficiently aggrieved to bring the matter to the community, than something is sufficiently wrong that we ought to at least take a listen. A No Confidence motion does not automatically remove the Workstream Leader, but lets the community decide quickly whether there is indeed an issue that warrants removal or not. I’m glad we’re in alignment about this being a potentially useful tool for the community.

[con5cience]

I appreciate your response, and I’ll reply to your reply to my reply today fo sho but I saw something in your reply to Jon that I wanted to reply to immediately in a new reply:

If a well-intentioned but incorrect Workstream Leader makes a decisions that the community largely disagrees with, I don’t see any reason why the community should be left with only the two undesirable options of accepting the results of the poor decision or removing a Workstream Leader who might otherwise be a valuable asset to the DAO.

Couldn’t the aggrieved parties can also elect to submit a governance proposal to form a new workstream composed of themselves, with a new charter/structure, effectively side-stepping the alleged over-reaching of authority? Isn’t this supposed to be an advantage of the agility of a DAO? I can easily see a situation where a new workstream is stood up alongside and those who prefer group A can be in that workstream while those who prefer group B can be in the other, everyone belongs to a group of people committed to their preferred social contract, and we can all get back to doing what we like, that is, building stuff. 1f642

Just a thought.

[con5cience]

mcchadwick:

That’s a good point – with no timeframe or mechanism specified, it would be allowable for an unscrupulous Workstream Leader to technically satisfy this requirement in ways that do not accomplish the objective. How about “…the Workstream Leader must notify all Workstream Contributors by DAO contributor email, during normal business hours for the Workstream Leader, and no longer than 24 hours after such a decision has been made.” ?

Sure!

mcchadwick:

Are you saying that it would be better to move the “Consideration of Organizational Impact” and “Declaration of No Confidence” sections to a separate document and indicate in this document that Workstream Leaders shalle be subject to those provisions?

Maybe – I’m saying the bit about invoking a forum poll to gauge sentiment followed up with a

governance motion should be called out as its own section in your document, and then places in your document where that is invoked should have references to it instead of plopping the whole big

thing in every context. That way there isn’t any confusion about whether the flow is different depending on the context under which it is invoked, etc.

mcchadwick:

What do you think? Is there anything else that a Workstream Leader mandate should include?

Sure, we can say that stuff, but perhaps the mandate should specifically leverage more direct governance action versus meta-actions? See below.

mcchadwick:

Blessing an Interim Leader with the necessary permissions would probably require at least some permissions modifications in Colony and role additions in Discord. Currently, that would require assistance from both and . In the case of the engineering workstream, Interim Leader permissions would need to be updated in GitHub, CircleCI, etc. That would require assistance from the Workstream Leader prior to taking leave.

Given that there are multiple external parties involved here in the permissioning, seems legit.

mcchadwick:

KPIs

Do we currently harvest, aggregate, and/or store any of these data somewhere?

Also, overarching topic: I’ve seen the word “incorrect” used in quite a few places here with relation to the perceived quality of a Workstream Leader’s actions, which feels like an inherently emotionally loaded term rooted in subjectivity. Is governance not the ultimate objective measure of correctness and legitimacy in decision-making here?

After swishing it around a bit mentally, it just seems like rather than having polls and threads and Discord chats and forum discussions and THEN governance, you could just skip straight to governance on all of these things and be done with it. I guess I don’t get why the meta-processes would need to be there at all when anyone can personally roll the guillotine up to the Bastille and let the crowd decide what happens.

[BeDiggy]

We have a team agreement and some other early documents related to Product’s role within the DAO.

[BeDiggy]

https://global.discourse-cdn.com/standard10/uploads/foxcookieco/original/1X/00a68ff65f1fbf885ac82801d274ebd966a4f3ab.png

Since this proposal is so detailed, I feel like this section is really lacking by comparison. For example is the workstream leader still entitled to pay while on a leave of absence? Is there a limit for how long they can be on leave? What happens if the interim leader is not performing well? Can they be voted out by an act of governance?

[pastaghost]

Hi ,

Thanks for the feedback.

0xean:

Generally, I find this alternative currently overly complicated and don’t personally see the benefit of much of the additional complexity.

This proposal admittedly contains more text than SCP-92, but it is not very much more complicated in structure. Both proposals allow Workstream Contributors the same flexibility and ease of performing day-to-day tasks; this one adds only a monthly budget reporting responsibility and a few mechanisms to check the actions of Workstream Leaders only in the event that something goes awry. You’ve been working with the DAO as long as I have, and so you’ve also seen that the of major issues that the newly-introduced mechanisms are intended to cover don’t actually happen very often.

Since March 2020 when I began working with ShapeShift, there have been only two necessary firings that I’ve been aware of. One, an executive for reasons that I was too new to the company to understand, and the second, an engineer who should have gone to prison. This is a low number of instances in a more than a two-year period. Speculation about how frequently these processes may have to be used can produce wildly varying estimates, but historical data seems to indicate that the voting burden imposed on the community by the inclusion of the additional measures allowing for the removal of a workstream leader are very low. Assuming that the rate of necessary firings and rate at which other proposals submitted holds for the next two years and that all fired parties object, this would result in an additional 2 out of (2*86) proposals, or a 1.16% increase in voting effort required from the community.

0xean:

It would seem that there are also several edge cases in the proposal that will lead to bad outcomes, slow decision making and ultimately the community having to vote on topics they will not be properly informed on.

I’m not sure there’s as much risk of this happening as you might imagine. No DAO member has to vote on anything. As a responsible DAO voter, I choose to abstain from voting on topics that I don’t feel I’m sufficiently well-informed to have a qualified opinion about. Looking at the voter data in Boardroom, the variance in number of votes cast by each voter is quite wide, so it appears that many others do the same. Furthermore, as a FOX holder and active community member, I would always rather have the option to participate in decision-making than to be protected from inconvenience by any person who considers themselves to be more qualified to weigh in on a decision than I am in a community that we all share. Remember that governance participation is optional, so there is no additional burden imposed on members of the community who would rather not participate, and those who choose to participate always do so voluntarily.

0xean:

I am much more in favor of delegating authority to trust work stream leaders, keeping work streams small to limit their power, and the terms short to allow governance to hold them accountable.

I assume that you carry a homeowner’s insurance policy. Does knowing that you’ll be reimbursed by your insurance company for theft or damages make you feel comfortable leaving your front door unlocked and open when you’re away from home? Of course the answer is no. Even though locking and unlocking your door multiple times per day costs you a small bit of time, the minimal overhead is absolutely worth the added security. Likewise, why does it seem sufficient to only provide a mechanism that allows for Workstream Leaders to be removed after significant damage may have been done to the DAO? How is this superior to adding a mechanism that allows for the DAO to avoid the damage in the first place, with no fault attributed to the Workstream Leader in the process? I also operate under the assumption that most individuals have good intentions, but an ounce of prevention is worth a pound of cure.

I’m not sure that the size of a workstream is correlated with the power that workstream holds in terms of DAO impact – I think that function is a much stronger contributing factor. All of the currently existing workstreams play important roles at the DAO, but the actions of some have larger or more immediate impacts than others. Ultimately, this is a software company. Marketing is critical for growth, but should there be a temporary disruption in marketing efforts, we likely would not lose our current users. Should there be a temporary disruption in engineering efforts and the application go down during that time, then we would immediately be in significant trouble in terms of our ability to meet the needs of our users. I think there might be something here though – while limiting the size of workstreams would not necessarily limit the power of any individual workstream, redundancy would. Having two parallel teams for essential functions would necessarily reduce the risk of giving full autonomy and authority to workstream leaders, as both would have to fail simultaneously for the output of that function to fail entirely. What do you think about exploring this strategy?

Short cycle times are good for the DAO in terms of increasing the resolution with which accountability can be directed, but this comes with proportionally increased uncertainty about job security for Workstream Contributors and makes it difficult to attract and retain talent. I can’t speak for the other workstreams, but the DAO is fighting an uphill battle when it comes to the engineering hiring pipeline, and for completely understandable reasons. There are a very large number of tech companies that will offer engineers much larger compensation packages than we can, benefits, career longevity and industry stability, as well as unlimited free snacks. We already have a difficult enough time convincing talented engineers to come work with us instead of going to companies who can make offers that appear to be more compelling in the short term, and it stands to reason that introducing greater uncertainty about job security by reducing the workstream cycles to three months instead of six, for instance, would only make that even more difficult. As was evident from the experience trying to hire engineers earlier in the year when market conditions were good, this is already a very tough problem. We had three open positions with high salaries on the engineering roster and could not fill them.

0xean:

Here are some additional questions/comments that I think should be addressed explicitly in the proposal

Good feedback, we should definitely try and resolve any ambiguities here.

1.) Yes. If the decision can be reversed on successful appeal, then the firing decision cannot be said to have been completed until the Workstream Contributor has declined to appeal or lost an appeal by governance.

2.) If a workstream has only one or two Contributors, then a loss of one or both Contributors would almost certainly have a significant impact on the productivity or output of the workstream. Under this consideration, I think it is in the best interest of the DAO to allow Contributors from workstreams of any size to appeal so long as the above conditions are met.

3.) I can definitely see where you’re coming from on this one, but I think that there is actually self-correcting mechanism here. Think about it like this: radical transparency is a policy that cuts both ways. First, any Workstream Leader who chooses to fire a Workstream Contributor should have an abundantly clear case to support the decision. That being the case, any Workstream Contributor who chooses to appeal the decision frivolously risks having his or her poor performance demonstrated publicly, and any Workstream Leader who chooses to fire frivolously risks having his or her questionable managerial competence revealed to the community. People are typically quite sensitive to public embarrassment, so there is tremendous motivation for Workstream Contributors not to appeal unless they firmly believe they can prove that the decision was made in error, and equally strong justification for Workstream Leaders not to fire unless they are sure that the decision is justified.

I agree that separating and forming a new workstream is an effective strategy to resolve the error, but only under the assumption that the community would support the new proposal. What about situations where the community would much rather see one workstream under unified leadership than two? Should we abandon the option for recourse in this case?

I’ll add clarification about these items to the proposal.

0xean:

I do believe the no-confidence piece of this proposal could be worthwhile to implement, but would also like to see the threshold raised to 2/3rds majority and a minimum number of contributors to establish quorum be set to 5 or more.

I’m glad you find some utility to No Confidence motion as well. I’m not sure I agree about raising the threshold. Consider this: if 50% of the employees on a team that you managed had sufficient qualms with you to jointly file an HR complaint and call for your resignation on-record, would you take this seriously? How many times have you heard of something like this happening? In my experience it’s quite rare, but in nearly every case I’ve heard of (aside from the hyper-politicized environments at companies like Netflix as of late , but I digress…), the accusations were extremely serious and needed immediate attention. I think the intent of raising the minimum threshold to a greater than 60% majority is to reduce the frequency of these cases, but I don’t think there’s any evidence to suggest that these cases would occur frequently at all, and if they did, it is still not clear to me that raising the threshold by 10% would make a meaningful difference.

[pastaghost]

Hi ,

Good ideas, thanks for your feedback.

Josh:

I can see the use of a “no confidence” vote in the workstream that then goes to community governance. When I read this, my first thought was also 50% was too low, and I preferred something more like 75%. Kind of like to actually remove a US President you need 2/3 majority in the Senate. So maybe, that threshold then, 2/3, or 66% vote inside the workstream needed for no confidence.

You are right that removal of a sitting U.S. president requires a 2/3 majority vote from the Senate. However, to begin impeachment proceedings, where an indictment is made and the case to remove the president is tried, a >50% majority vote and presentation of Articles of Impeachment are required from the House of Representatives. The 2/3 majority vote from the Senate determines whether or not to convict and remove the sitting president once the case has been presented in court. The No Confidence motion is behaves in a similar fashion. Note that a No Confidence motion cannot directly remove a Workstream Leader. The motion only allows for the case to be presented to the community, and it is the community that must decide whether or not to remove the Workstream Leader once those who put forth the No Confidence motion have made their case in governance.

Josh:

better to give more authority that is clearer to the WS Leader by default.

Note that this proposal does not actually limit the authority of Workstream Leaders in comparison to SCP-92, it only introduces new mechanisms that can be used to check the actions of a Workstream Leader in the event that something goes wrong.

Josh:

Any workstream proposal can create a charter that limits the leader’s authority more, if they so choose. I’d rather experiment at the workstream level with charters, and if we see a leader definition in action that is working rather well that can scale, then consider amending the default definition to include that.

Given that the additional sections that you are referring to from this proposal are only put to use when there is a significant problem, I’m not sure that makes sense. The frequency at which these mechanisms would be used on any one or a small number of workstreams would be much too low to make the determination that it was worthwhile to include them in the global definition. To your point, if these mechanisms were included in the default definition and proved to be used more frequently than was reasonable, the default definition could be amended at any time to remove them and individual workstreams would still retain the option to reintroduce them via their team agreements.

Josh:

Those are my first thoughts. Will post more an I consider this further.

Please let me know if you have any further thoughts on this so we can continue to shape up this proposal prior to governance.

[pastaghost]

mcchadwick:

I think there might be something here though – while limiting the size of workstreams would not necessarily limit the power of any individual workstream, redundancy would. Having two parallel teams for essential functions would necessarily reduce the risk of giving full autonomy and authority to workstream leaders, as both would have to fail simultaneously for the output of that function to fail entirely. What do you think about exploring this strategy?

Hi ,

I think that’s a great idea, so long as the community approves of the spend and does not strongly prefer that the function be directed under singular leadership. I think there is a strong case to be made for increased robustness in having parallel workstreams for essential functions akin to the necessity for consensus between multiple validators. Having two or more parallel teams for essential functions would necessarily reduce the risk of giving full autonomy and authority to workstream leaders, as all would have to fail simultaneously and in the same way for the output of that function to fail entirely. How would you go about the process of resolving disagreements between parallel teams? Was this even an issue under the squad model at centralized ShapeShift?