[SCP-92] Definition of Workstream Leader [Ideation]

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

  • A workstream requiring a single leader
  • The authority to hire and fire within a workstream
  • Discretion over the allocation of a budget approved by governance

Should this proposal pass, it will take effect after 14 days, and apply to all workstreams without a passed superseding proposal.

Current workstreams with multiple leaders are encouraged to expediently elect a single leader and adopt this definition via a separate proposal specific to their workstream.

Future proposals that create, renew, or amend workstreams will adopt this definition of a Workstream Leader by default unless explicitly defined otherwise.

Motivation

There is not 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.

Resourcing and budget are intrinsically linked. A Workstream Leader cannot control one without the other.

A single Workstream Leader is proposed as a clear, effective, and familiar way to mitigate complexities that can arise with multiple Workstream Leaders related to responsibility, accountability, and conflict resolution.

Specification

Single Workstream Leader

A workstream shall have a single Workstream Leader.

The Workstream Leader shall be responsible for the direction, resourcing, budget, performance, deliverables, communication, and representation of the workstream.

The Workstream Leader may only be changed via governance. In the event of a sudden or emergency departure of a Workstream Leader, a Workstream Leader may appoint an Interim Workstream Leader by a forum post, which shall immediately follow the standard governance process.

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.

Budget

A budget is an estimate of income and expenditure for a set period of time.

The Workstream Leader shall be delegated the authority by governance to have full discretion over how an approved budget is spent.

The Workstream Leader shall not be able to spend more than the approved budget by a proposal, without a proposal to amend said proposal.

Workstream proposals must include timephased budget estimates broken down by each month of their proposed cycle (e.g. $15,000 July, $10,000 August, etc.).

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.

Benefits

An explicitly defined and shared understanding of how workstreams and their leaders operate will remove the ambiguity that currently exists within the DAO.

Without a defined and granted delegated authority - a Workstream Leader is unable to lead. The leader role becomes that of a secretary, coordinator or spokesperson.

Drawbacks

There could exist a perceived centralization risk that arises from delegating authority to Workstream Leaders.

This is mitigated by the following

  • Delegated authority is well defined and scoped to an individual workstream.
  • A Workstream Leader can be removed via a governance proposal at any time.
  • A Workstream Leader’s term is always limited and thus up for renewal and potential replacement at the end of any given term.

Vote

  • FOR - Adopt the proposed definition of a Workstream Leader.
  • AGAINST - Do nothing.

0 voters

4 Likes

I would change this to say, “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 a proposal”

Without a change to that specific language, I would not vote for this proposal.

4 Likes

I agree with theobold on this. I will vote no if this is in the proposal as written

2 Likes

The primary issue that I take with this is the combination of sweeping responsibility and onset of effect. As I’ve explained at length in the previous forum post, the terms outlined here do not provide adequate checks against the authority granted to workstream leaders under this proposal. It is not clear that this extent of authority is at all necessary for workstream leaders to wield, and the potential for abuse is obvious.

While this may be appropriate for some workstreams, this is not generally applicable, and a problem around the onset of effect arises in the specific case of the engineering workstream. The 14-day delayed onset gives other workstreams that would prefer an alternate operating agreement time to draft a superseding charter. On the engineering workstream, however, the majority involved find these terms to be highly inappropriate, while @0xdef1cafe disagrees. With these terms, @0xdef1cafe is directly incentivized to do nothing during the 14-day period which follows should this proposal pass, triggering the fallback case and granting himself powers which most of those with the relevant subject matter expertise and context on the situation agree that he should definitely not have. If workstream renewal is contingent on a charter being submitted along with the proposal, since the workstream proposal requires buy-in from the contributors, @0xdef1cafe then must work with the contributors to derive a fair operating agreement.

This provides an underhanded mechanism for forcing organizational decisions on a group who in majority believe this to be wrong.

A competent leader should work with his/her team to leverage the collective experience and judgment available to find optimal solutions to problems instead of forcing his/her singular opinion on the group. It is obvious that the aggregated experience and viewpoint diversity of a skilled group will far outweigh that of any individual, and it is more likely that the optimal solution can be found in the extended solution space available to the group than in the narrow solution space available to an individual.

Aside from the specific terms of the proposal, the spirit of this strategy seems to be below board and against the ethical standards of this community. This kind of behind-the-back political strategy is unhealthy for the DAO and is not what we should be doing here if we are interested in finding optimal solutions and maximizing our chances of success.

I would not vote for this proposal.

2 Likes

I dont disagree with your wordage. The workstream leader should be upholding the proposal, and its values. Hhowever, if this prevents the WS leader from making needed changes based on random changes that happen in the ‘world’ then this might be also be wrong. with the above, it leaves some leeway to fit with those changes. I am not sure which way is better. (I will still follow the spirit of this proposal no matter what)

2 Likes

Maybe someone would put up a post/proposal, with the different wordage to have that looked at?

1 Like

I’m working on an alternate default agreement and example charter for the engineering workstream and will post those here in the next day or two.

1 Like

Thats fine. but i was thinking more about the WS Leader post, for this topic, seeming to be contentious.

1 Like

Still a ‘no’ on this.

3 Likes

I would much prefer the folly of governance to respond to an existential threat, than the folly of governance to respond to a theoretical, malicious actor (which should be assumed at all times).

1 Like

In addition, I see no utility to the single workstream leader mandate. I would not vote for this proposal until that is also removed.

1 Like

Im not sure about the Single WS leader aspect. the good/bad thinking for both reasonings im sure is there. Confusion on whom to talk to, its better to have one person to say ‘hey’ vs saying something to one, and getting the ‘oh thats not me, thats other’ , flipside… having 2 means you can split leadership duties. Then again, 1 leader can delegate most abilities to anyone else already.
So, one lead for each workstream has a slight advantage in my thinking, i think.

If theres a malicious actor, we already have some things that are in place. (Malicious about doing things outside of the proposal) Other ppl do watch whats going on, in colony for example. everything is showing. and transactions are onchain.

Thanks! :slight_smile:

1 Like

I wanted to emphasize that this is NOT what @0xdef1cafe said he was going to do during our engineering workstream meeting last week. We discussed this topic at length and @0xdef1cafe assured us he would not include the provision making this effective immediately.

This assurance was also reflected in our previous forum discussion on this topic: [SCP-TBD] Definition of Workstream Leader - #12 by 0xdef1cafe

It is extremely frustrating and concerning when someone in a leadership position makes these kinds of assurances and then goes and does nearly the exact opposite. Especially when considering the nature of the proposal and the person creating the proposal it should not be difficult for others to see why we have such concerns

2 Likes

@elmutt To get ahead of the inevitable ”but it says after 14 days….” comment, this proposal taking effect 14 days after approval is functionally equivalent to this proposal taking place immediately from the perspective of the engineering workstream. I made a comment in the previous forum post that the intent of removing the immediate effect clause was for this to take effect only upon workstream renewal, should it pass governance. That’s what’s most bothersome about this post to me - the addition of the 14-day delay is intentionally misleading to anyone who was not involved in the engineering workstream discussions in that it’s crafted to appear as though this is an attempt at legitimate compromise. This is highly disingenuous and downright dishonest. Frankly, I’m thoroughly surprised and deeply disheartened to see this kind of behavior from anyone at the DAO, and especially from @0xdef1cafe who I have tremendous respect for as a coworker and as a personal friend.

We’re supposed to be working together to find the correct solution for the DAO, not against one another to see that our individual interests are satisfied at the expense of one another. This isn’t a zero-sum game. If we do this correctly, there is tremendous upside for everyone involved. Because there are many more ways to do this incorrectly than there are to to do this correctly, us not working together effectively is overwhelmingly likely to produce an outcome in which we all fail.

I care about ensuring that the right strategies which maximize the likelihood of success for the DAO are the strategies put to action, and I have no reservations about what form those strategies take or who produces them. I sincerely hope that that perspective is shared by everyone involved in this discussion. Please, let’s keep this above board.

4 Likes

In my view, the role of a workstream leader is not to exercise any more discretion than is absolutely necessary. Whatever local minimum the de facto process of day-to-day administration has evolved towards, workstream leaders have de jure no more authority or discretion than the DAO gives them by the specifics of passed proposals. Make no mistake: this proposal does not represent a clarification of previously existing policy, it is a request for a significant expansion to the mandate given to workstream leaders — and one which should have, in my opinion, been required before the recent unilateral decision to radically alter the Engineering workstream’s capacity to discharge its responsibilities.

As Security workstream leader, I went to great lengths to word the proposals I brought specifically to constrain my discretion as leader as much as possible. I saw myself as having no right to spend money on anything which had not been specifically authorized, and never in excess of the amount authorized for that specific purpose. Frankly, the existence of the notion of a “workstream budget” isn’t even well-defined — workstreams don’t “have budgets”, they execute proposals. It’s purely an administrative convenience that some of those proposals are brought in an omnibus, time-boxed fashions, and that such proposals tend to have the word “budget” in their titles. Most of those delegate significant discretionary power to the workstream leader over the specifics of their execution, and custom and courtesy has dictated that they be brought forward by the workstream leader, but those aren’t fundamental properties.

As an example, someone might bring a proposal that the DAO allocate $50k to integrate support for OrangeJuiceCoin into the ShapeShift web app. We’ve structures such third-party integration efforts as bounties in the past, but there’s no reason that someone couldn’t propose that that task, and the funding for it, be handled in-house by the Engineering workstream. This wouldn’t match the traditional notion of a “workstream budget”, but as proposals go it would nevertheless be a first-class citizen, providing an allocation no way inferior to any created by any other proprosal — and in the same way, funds authorized for one purpose have no business being spent for another, whether that authorization was given as part of an omnibus “budget proposal” or not.

Likewise, a workstream leader who is granted discretion over the administration of certain funds is thereby granted the power to “hire and fire” only in the sense that they have the discretion to choose how to expend those funds, which may involve choosing to retain someone’s services, and may also involve choosing not to continue to pay someone with those funds. Their power, however, is very different than the “hire and fire” powers of a traditional executive, as they cannot terminate someone’s relationship with the DAO. In particular, whether or not someone is a DAO member or contributor cannot be controlled by the decision of a workstream leader to “let them go”. (Case in point — I’ve stepped back from the role of Security leader, and I’m no longer drawing a salary, but I’m still a DAO member; in fact, I’m working on a new KeepKey CLI, so I’m still a contributor, even though no one is paying me to do it.)

Workstreams are self-organizing. While they’ve generally tended toward top-down control so far, in my view it would be possible for a workstream to exist without a leader at all. In fact, an entire workstream could be run without anyone needing to be granted special permissions via the Colony reputation system (though I’ll admit that its interface makes me want to gnaw off my own limbs in its current state). Likewise, the DAO’s ability to hold a workstream accountable isn’t based on its ability to sue anyone, and isn’t contingent on a single leader — the DAO has the ability to decide not to give any more money to a workstream that doesn’t perform no matter how that workstream organizes itself.

Fundamentally, the position of workstream leader is a servant’s position, entirely like that of a secretary, coordinator, or spokesperson, and entirely unlike that of a corporate officer or executive. Holding the position of workstream leader does not make someone a leader of the DAO; they are a DAO leader simply because they are a member of the DAO. Workstream leaders certainly may enjoy a unique level of trust, respect, and even insight, but this is accrued through their discharge of their responsibilities, and is not gained (and should not be given) simply because they hold their position.

I feel that this proposal would imply a sea change in the nature and structure of the DAO. I echo the concerns presented by @pastaghost and others, and at least as currently envisioned I can’t support it.

6 Likes

Thank you for this post NH, made me smile. Glad to have you here, continuing to make contributions <3

PS : its time to remove my moderation perms on forum. I’m not sure who can do that other than @willy but I’m happy to remove those here and now for the community. I would request though, that you stop trying to flag and censor posts @con5cience - with that being said my perms can be removed here and now.

2 Likes

I would request though, that you stop trying to flag and censor posts @con5cience

It’s Inappropriate
This post contains content that a reasonable person would consider offensive, abusive, or a violation of our community guidelines.

I will definitely not stop flagging examples of your behavior that I believe to align with these conditions. If that is “censorship” then I guess I’m an Orwellian fascist.

Also, flagged your post for being off-topic. :smiley:

1 Like

you’re an awful foundation member, just another pawn.

oh wow I’m glad you said something after I told @jonisjon you were flagging posts :slight_smile:

Sounds pretty petty - Censorship isn’t welcome in Crypto.