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

So i’ve already weighed in the incubation thread (here) on why I think its important for the DAO to vote on this and attempt to clarify any ambiguity around the standard workstream leader definition.

To respond to a few of the comments in this thread from over the weekend:

discourse-post-upload20231125-65354-sr9of9.png theoboldfrazier:

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.

Im not sure that this language makes a huge difference. IMO the workstream leader should have very broad authority over the budget of the workstream they lead and I don’t think adding this helps much with the definition. Instead I think the bounds of any particular leader can always be delineated further in a workstream specific proposal and I don’t think it makes sense to bound it any further on the standard definition side.

discourse-post-upload20231125-65354-zsozg2.png mcchadwick:

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 disagrees. With these terms, 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, then must work with the contributors to derive a fair operating agreement.

I appreciate 's thoughts on this issue but respectfully disagree about the concerns. I think this responsibility already exists for WS leaders within the DAO and the “onset” has really been in effect for a year now and this only clarifies what already exists, as a result I don’t see the responsibility granted by the definition nor the onset of the result as issues here. I also think governance already serves as a more than adequate check and balance on the authority of WS leaders, however I remain open to hearing additional proposals (either to be added to this one or specific to workstreams) that could add further checks like the one I proposed in the earlier thread linked above.

I understand this upsets some of the engineering workstream specifically given the recent changes that wants to institute, but overall I think we need to explicitly clarify that authority for all workstream leaders and that we can weigh in separately on whether we think those workstream leader’s decisions are effective or not. Leaving it ambiguous for any longer than necessary now that contention has come up around definition seems a worse result than letting FOX holders weigh in on this via snapshot from my perspective.

I also understand that various members of the engineering workstream really don’t want the language that puts this into effect in 14 days, but I ultimately think that an item like that is up to governance and not the specific wants of any specific workstream unless they pass a proposal that dictates their workstream works in some different manner (and I think the 14 day delay + this not being up for vote and the time for discussion already had gives ample time for workstreams to suggest other approaches if they don’t want to adopt the standard definition being proposed).

discourse-post-upload20231125-65354-zsozg2.png MrNerdHair:

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.

I appreciate MrNerdHair’s salient thoughts and comments on this topic. I disagree that this is an expansion of authority for workstream leaders as this is how the DAO has operated for over a year, we can argue interpretation all day over what the original workstream docs on the forum and/or wording of specific proposals did or did not implicitly grant and this is precisely why clarifying this now explicitly is so important from my perspective. Specifically what is “necessary” for a workstream leader’s authority is exactly the clarification up for debate here, some in the DAO (including myself) think this type of definition is necessary for a WS leader to be effective on behalf of the DAO, others disagree, that is fine but it is also exactly why I think we need a resolution to this via governance imminently.

I understand and appreciate the prospective view about workstream leaders having more limited authority, but IMO if we don’t give control over the budget of a workstream to the workstream leader we are ultimately hamstringing their ability to deliver on their goals so much as to make them ineffective and I cannot currently support a definition that does not give WS leaders that authority as a result.

discourse-post-upload20231125-65354-17s1df.png Neverwas:

GM I have tried to stay out of this because more seems to be going on beneath the surface and could have issues directly tied to a single WS. At this point though I do not see cooler heads prevailing and I believe that with the attention and fracturing tone of discussion, I as a community member and a contributor would like to discuss this further before pushing this to governance vote.

I don’t personally know the time sensitivity other than Workstreams are up for renewal and the determined need is greater than the time allotted to have a larger community discussion, I of coarse would debate that, we have gone this long with multiple renewals and I believe we can find solutions. If it is beyond this time sensitivity and has to do with DAO fiscal responsibility or determined need of Treasury capability, I do feel the community needs to figure this out.

I don’t know if this will be moved forward to governance at this point, but feel that pushing this to vote or the sense of rushing this through because we can is probably not the best look or alternative. This is just my thoughts and I might not know all of the details or context, but isn’t that the point? If you are asking the community to vote something into governance and something that is beyond a single WS purview how can we vote not knowing the context and having the ability to look at alternative solutions.

That said I do see a lot of disagreement but not allot of presented alternatives besides workstream contributors having concern for verbiage and also presenting with layers of subtext and lack of direct context for voters that seems to revolve around the engineering WS.

I hope that we as a public community acting as a DAO can grow stronger through this, but we do need to deal with it as such, passion and emotion aside we need to have meaningful dialect and present viable pathways forward. We are all beings and don’t have to agree on all points but with the 1 year anniversary a few moments away we can do better communicating, collaborating, and compromising.

Neverwas I respect and appreciate that you want to move the conversation towards one more of unity and agreement, I would love to see that here too and generally is the approach I always want to see in governance discussion. However I do think there are times when something is so contentious between 2 or more sides that governance is required to clarify for the DAO to move forward, and this seems like one of those circumstances to me where we have a disagreement about the scope of authority of elected WS leaders between a specific WS leader in engineering and those he wants to allocate funds away from to complete his mission as he sees appropriate. We can disagree all day long about whether that decision is correct or not, but I think it is imperative that the DAO has clarity on this topic in regards to at least what the authority of a WS leader is or is not.

In the end this is the best proposal I have seen so far to clarify this issue and let the DAO move forward so right now I do believe it should move forward to snapshot if it has the requisite votes in ideation and be decided by holders of FOX. I do, however remain open to alternative definitions or alternative workstream proposals that define WS leader differently for their specific workstream, just so far I have not seen any other positive options proposed, only critique of the current definition (which is fine, but I think seeing alternatives side by side is far more likely to move the conversation forward in some manner at this point). I know mentioned he was working on an alternative, so I look forward to reviewing that with fresh eyes once it is posted.

Maybe if someone would spell out the effects this proposal has on each of the workstreams.

IE: how does this change …what im doing, or product/marketing/ops etc. - maybe taking out the NOW, and making it upon renewal of next proposal for each ws, instead of ‘now’ (not that i notice a change, but maybe thats scaring ppl?) in my proposal, i put a Total in. and then i mention what i was going to use it for. Wondering now, if i should just do the Total, and leave all the details out. (which is what i was told to do initially)

Regarding:

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.

I want to add that a clause for a “leave of absence” should/could be added. For example, while I’m away on maternity leave I have two team members taking over my day to day work. I do not believe they should go through the governance process for a temp leave.

I also think a blanket formula for WS Leader might not work for the entire org, especially if we continue to grow and we have workstreams for all sorts of different products, teams, and maybe even fun things like the “DJ workstream” (when the bull market is here, this will all make sense 1f609 ). The Product leader will most likely have much different desires for her workstream than the DJ’s…so perhaps just sticking with a high level WS leader code of conduct would be a better approach then trying to define the position overall.

Here is the JD I created for myself when I was creating our workstream for example of what I consider needs to fall under my umbrella: Customer Support Workstream Leader - JD - Google Docs

discourse-post-upload20231125-65354-zsozg2.png willy:

The ideas that workstream leaders are corporate, that we should have flat workstreams, or that we should have workstream leaders with accountability but no authority are opinions that I wholeheartedly disagree with. While it may sound nice in theory, this does not work in practice.

This has been stated many times axiomatically, but not much argument has been provided to support this point of view, and there are immediate counterexamples to the statement that organizational strategies other than a strict hierarchy do not work in practice. The engineering workstream at its inception had an explicitly flat organizational structure. confirmed this at the engineering retreat. held an extended set of responsibilities as workstream leader, but did not consider himself to be in a position of authority above the other workstream contributors. The engineering workstream had no difficulties as a result of operating under this model, and in fact, all of the recent operational difficulties on the engineering team have come as the organizational structure has tended in a more centralized direction. The Protocol Engineering Core Unit at MakerDAO successfully operates as a team of 11-16 engineers with a $6.12M annual budget under a flat organizational structure. is completely correct that, at least in the context of the engineering workstream, this is a request for a significant expansion to the mandate given to workstream leaders and that is precisely why this topic is so contentious.

discourse-post-upload20231125-65354-zsozg2.png willy:

I disagree wholeheartedly. Please stop trying to make this seem like this is against DAO ethics or spirit or is some kind of “behind-the-back political strategy.” Many contributors, workstream leaders, and community members agree that this is not only how the DAO should operate, but how it has been operating. I think it’s very misleading to try and cast this proposal in such a negative light when IMO clearly has the DAO’s best interest in mind.

, the accusation that I am being dishonest or trying to make this seem like something it isn’t is one that I take very seriously. I always welcome and legitimately consider any feedback, but if this is your point of view, then you’re going to have to make your case instead of blindly throwing an accusation at me. To clarify, what I said is this: made an agreement with the community to remove the immediate effect clause after public conversations about the effect of that clause with respect to governance. The intent of removing that clause was known. Instead, chose to replace the immediate effect clause with a different clause that is functionally identical. In this way, it appears to the community as though the agreement to remove the clause was kept when in reality it was not. I am doing nothing disingenuous or misleading in pointing that out. It is also not clear to me that inserting intentionally misleading language in a governance proposal or making flatly untrue statements about MakerDAO’s governance policy during the weekly governance call can rightly be considered as acting in the DAO’s best interest. If a person finds it necessary to engage in unethical tactics to convince a group of his or her point of view, I think it’s worth deeply considering whether that point of view is one worth holding.

discourse-post-upload20231125-65354-zsozg2.png MrNerdHair:

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.

This is spot-on. I’m not sure that “workstream leader” is an appropriate title for the position, and I think that might be a significant contributing factor to the disconnect on this issue. Yes, many of the functions of workstream leaders are necessary, but those specific functions aside, I’m not sure it’s an effective or efficient use of resources to have the separate divisions of the DAO “led” by single individuals. We’ve all had different experiences, and there is great strength that comes with viewpoint diversity. In the context of engineering, the idea of rallying the entire development effort behind a single point of view is just silly.

Workstream leaders play an important role in the organization. Because the DAO is dependent on these roles being undertaken competently, we should do our best to ensure that the individuals occupying these positions are motivated to do so for the right reasons, and not for any peripheral advantages like authority, autonomy, or job security. In my opinion, the most effective way to ensure that workstream leaders have taken on additional responsibility with only the best interest of the community in mind and not in self-interest is to remove the peripheral advantages in the first place.

I want to clear up a few things about MAKER, I wasn’t in the governance call so I cannot comment on that, but what is posted above isn’t accurate either.

The Core Unit Facilitator role is very close to what is being outlined by here for a workstream leader. Facilitator’s are trusted to have autonomy and control of their budget and are able to make hiring and firing decisions at will inside of their budget.

Please see - MIPs Portal - for reference.

Regarding the Protocol Engineering Core Unit specifically, the team does have a flat structure in that all team members report to Derek_ directly. (MIPs Portal) The “flat” refers to the fact that there is no other hierarchy of people reporting to managers that then report to Derek_. I have spoken with Derek_ directly, and he absolutely has the sole power for hiring and firing within his budget. He does of course consult with his team members, but ultimately he is the arbiter of the budget and is held responsible for that by token holders and governance.

Additionally, Derek_ does have the ability to set priorities on the team within his charter and does so when needed.

There is a large difference between a flat org and a leaderless org structure.

discourse-post-upload20231125-65354-zsozg2.png mcchadwick:

The engineering workstream at its inception had an explicitly flat organizational structure. confirmed this at the engineering retreat. held an extended set of responsibilities as workstream leader, but did not consider himself to be in a position of authority above the other workstream contributors. The engineering workstream had no difficulties as a result of operating under this model,

At the Engineering Retreat I said that I remembered saying to people “I guess I’m not your boss anymore.” And I did think of it that way. I do think that if I needed to fire someone during that time, that I would’ve done so, and been supported in doing it.

I disagree with the statement that we had no difficulties. While we had no internal conflict, I do think that as a team of engineers we were getting complacent. I talked about this at the time. I say “we” as I include myself in this statement. I thought we needed a leadership change, and bringing in James, who is more of an expert/achiever leader (for those who follow in that framework), was what the team needed. The team was getting smaller. He has a better sense of what should be possible in what timeframe, and better able to unblock people with technical challenges to achieve what is possible.

I have mentioned to engineers that in retrospect, this whole discussion about what should happen with the workstream would have been better if we all talked about it together at the retreat. That would not have changed my opinion that James as the workstream leader should have the ability to make the final decision if needed, and I do think we might have come to some common understanding about it all.

I support this proposal as it is. I agree with and some others that I would have preferred if this did not have the 14-day clause. However, at the end of the day, we are only talking about a matter of weeks - whether that is two weeks, or four weeks until the middle of August, or six weeks until the end of August. In August, we will need a new workstream proposal that will begin on September 1, if we want engineering efforts to continue.

I understand will propose a workstream with him as the workstream leader as defined here. If there is another one that someone (?) wants to propose with a flat leaderlesss structure, you still have 14 days from the passing of this proposal (if it does pass), before this definition takes effect and applies to the current Engineering workstream.

, the accusation that I am being dishonest or trying to make this seem like something it isn’t is one that I take very seriously. I always welcome and legitimately consider any feedback, but if this is your point of view, then you’re going to have to make your case instead of blindly throwing an accusation at me. To clarify, what I said is this: made an agreement with the community to remove the immediate effect clause after public conversations about the effect of that clause with respect to governance. The intent of removing that clause was known. Instead, chose to replace the immediate effect clause with a different clause that is functionally identical. In this way, it appears to the community as though the agreement to remove the clause was kept when in reality it was not. I am doing nothing disingenuous or misleading in pointing that out. It is also not clear to me that inserting intentionally misleading language in a governance proposal or making flatly untrue statements about MakerDAO’s governance policy during the weekly governance call can rightly be considered as acting in the DAO’s best interest. If a person finds it necessary to engage in unethical tactics to convince a group of his or her point of view, I think it’s worth deeply considering whether that point of view is one worth holding.

Never accused of dishonesty, but I do stand by my request to please stop making this seem like it is in any way unethical, against the spirit of the DAO, or some kind of “behind-the-back political strategy,” which are very bold claims that I do wholeheartedly disagree with. I see this as ethical, very much in the spirit of the DAO, and a public and transparent conversation that is complying with every requirement in the governance process.

In this same paragraph, you do accuse of dishonesty by inserting intentionally misleading language and as well as making flatly untrue statements about MakerDAO’s governance policy. If somebody says something incorrect (honestly not sure who is at fault here and would like to hear the statement in question so we can get clarity here), I certainly don’t think we should assume that they are doing this intentionally, unethically, or without the DAO’s best interest in mind. That is against the spirit of the DAO imo.

I also do not see any mention of this in the comment where you made the claims:

To clarify, what I said is this: made an agreement with the community to remove the immediate effect clause after public conversations about the effect of that clause with respect to governance. The intent of removing that clause was known. Instead, chose to replace the immediate effect clause with a different clause that is functionally identical. In this way, it appears to the community as though the agreement to remove the clause was kept when in reality it was not. I am doing nothing disingenuous or misleading in pointing that out.

Mentioning this and disagreeing with it would have been fine, but that is not what you did; you claimed the entire strategy was unethical.

If a person finds it necessary to engage in unethical tactics to convince a group of his or her point of view, I think it’s worth deeply considering whether that point of view is one worth holding.

I completely agree.

See i was going to stay out… But maybe have this apply only to w-engineering. as they might need clarification. as far as i can tell, no other WS is having this issue.

‘leaders’ are just the ones that are fulfilling the proposal as they discussed and got voted on.

I’ve provided an alternate Workstream Leader definition here.

This has gone to snapshot here Snapshot

I acknowledge that we need governance direction one way or the other here, but I really would have loved to have seen you coordinate with @pastaghost on posting your individual proposals to Snapshot simultaneously after the community discussion had come to a more organic state of completion. 1f494

Part of the intent of the ideation step is to allow the community to review any modifications to or alternatives to proposals. You can read that here. Prior to your decision to move this to SnapShot, you were given the alternate proposal in advance, informed that the alternate proposal would be headed to the forum, and the alternate proposal was posted here. You also just yesterday agreed verbally to review the new proposal in order to collaborate on this. I sent you the proposal in advance yesterday to establish some record of these conversations having taken place in anticipation of something like this being attempted.

To be clear, the FOX Governance Process document says:

discourse-post-upload20231125-65354-zsozg2.pngFOX Governance Process

From time to time there may be conflicting proposals. To avoid issues, the Ideation phase can also serve as time for anyone to list their preferred alternative option on the forum. Each proposal on an associate topic will have a [TOPIC] block placed in its title.

After that time, a formal proposal will be put forward including all options available to move forward with that received majority support in Ideation. This will ensure that everyone has the ability to surface their preferences while keeping decision timelines reasonably short.

and also says:

discourse-post-upload20231125-65354-zsozg2.pngFOX Governance Process

  • Timeline: 5 days minimum

  • Proposal may move forward if the majority votes in favor after timeline specified above

Given that this post was originally made at July 8, 2022, 1:13PM MST and the proposal was moved to Snapshot at Jul 13, 2022, 10:17 AM, the minimum five-day ideation phase had not concluded prior to this being moved out of ideation.

Perhaps more importantly, I think the decision to knowingly advance this proposal to Snapshot before the community had a chance to review modifications or the proposed alternative unfortunately represents yet another action that is against the spirit of governance.

Although there are currently more votes ‘AGAINST’ this proposal than ‘FOR’ on Snapshot, I think that the right thing to do in order to see that the best wishes of the community are reflected here is to remove the proposal from Snapshot at this time.

Reposted to snapshot after the required 5 day period - apologies it was posted 3 hours prior earlier today

https://snapshot.org/#/shapeshiftdao.eth/proposal/0x3529a9ab550387d1eedf34d0ba26b5c80ed1c04a74a3c407d9b06a6ea90325ab