[SCP-TBD] Updated Definition of a Workstream Leader

[pastaghost]

Hi ,

BeDiggy:

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

Are these included in the Product Team’s workstream proposal? If not, could you please send them to me so I can look at these documents as an example?

BeDiggy:

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?

Good idea. Some detail should certainly be added here. Off the top of my head, I’m thinking that the original Workstream Leader should generally not be entitled to pay unless a request to be paid has been specifically approved by the DAO. It might also be useful to draft a set policy that adds maternity/paternity leave with specific time limits as a pre-approved exception so we don’t ever end up in a situation where the ability of a Workstream Leader to take paid parental leave is up for debate. To account for an unplanned leave of absence, I don’t know if it is useful to add a time limit to the definition. I think that as long as the Interim Leader is able to fill the role competently and the Workstream Leader is not also being paid while absent, a leave of absence of indeterminate length is not a problem for the DAO. Maybe the time limitation is addressed only with relation to any payment request that may be made by the Workstream Leader so that there is no time limit for an unpaid leave of absence, and if the Workstream Leader wishes to receive payment while absent, this is only possible for a set period of time that must be approved by governance, after which payments will cease. The line at the end of the section, “The Interim Workstream Leader shall assume the role entirely, and is subject to all provisions outlined in this document” was intended to address any questions about removal of an Interim Leader. While filling the role, an Interim Leader would be treated exactly as a Workstream Leader and all removal mechanisms would apply just as they would for a Worsktream Leader. In addition to adding detail about the points you raised, should I rephrase the last line?

[pastaghost]

Hi ,

willy:

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.

If you consider this proposal carefully and in the context of your experience at the DAO and at centralized ShapeShift prior, you’ll see that it should not in practice be any slower than or even distinguishable from SCP-92, except in serious cases where corrective recourse is needed. This does not restrict the authority or autonomy granted to Workstream Leaders relative to SCP-92, and that is intentional. Instead, it seeks to establish policies to adeptly handle highly unusual situations in ways that minimize damage to the DAO.

willy:

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.

This is not an additional requirement, only a statement of the existing requirement and a definition of what is to take place should the Workstream Leader be removed by the currently existing mechanism.

willy:

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.

f any Workstream Leader is regularly at odds with >50% of the Workstream Contributors on their team over issues that the Workstream Contributors believe they can argue to be a threat to the DAO, then there is a serious problem. I have not seen any indication since the DAO began that this is a regular occurrence on any of the workstreams.

Yes, any community member can currently make a proposal to request the removal of a Workstream Leader. In practice, this is extremely difficult to make a case for, and takes more time than is justifiable in the event that a Workstream Leader needs to be removed quickly. With the specification that this mechanism indicates the Workstream Contributors (who necessarily have the greatest context on the competence of the Workstream Leader) from one team have declared their Workstream Leader to be incompetent, this motion carries a greater degree of gravitas than does an ordinary proposal. Furthermore, the path through an expedited governance process allows for the decision to be made quickly, saving time and minimizing further damage in the event that this is necessary.

willy:

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.

As above, this mechanism leverages the expertise of and context shared by the Workstream Contributors from one team to support the argument made against a hiring or firing decision by a Workstream Leader. Any one individual may object to a hiring or firing decision, but this is extremely unlikely to gain wide community support. Because this mechanism requires public support from >50% of a fired Contributor’s team members, this would only be used in the event of a very controversial or obviously unjustified resourcing decision. Instead of speculating about how this might impact Workstream Leaders, I choose to look back at my experience working with ShapeShift for historical evidence. I cannot think of any individual firing that would have triggered this mechanism over the previous 2+ years, so it is not reasonable to assume that this mechanism would need to be frequently used going forward.

willy:

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.

As I’ve argued in other posts, the problem with retaining removal of a Workstream Leader by standard governance as the only corrective mechanism is that it is much too blunt a tool to be useful, except for in extreme cases. I wrote this in my response to above, but I’ll add it here as well: I assume you carry a homeowner’s insurance policy, yes? 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. Likewise, why does it seem sufficient to only provide a mechanism that allows for Workstream Leaders to be removed after significant damage has 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?

I also assume that most individuals have good intentions, but an ounce of prevention is worth a pound of cure.

Additionally, there is nothing stating that a Workstream Leader must comply with the outcome of an approved proposal challenging any particular decision. Under the current process, if a Workstream Leader makes a highly controversial decision, then a proposal goes through standard governance to challenge this process and that proposal is approved, what happens if the Workstream Leader refuses to comply with the community decision? In that case, a separate proposal must be put forth calling for the Workstream Leader’s removal. The passage of two subsequent proposals requires a minimum of something on the order of 22 days and results in the loss of a Workstream Leader. The mechanism I’ve proposed handles this in an expedited fashion (it could reasonably be as fast as something on the order or three days), mandates that the Workstream Leader comply under penalty of removal, and attributes no fault to the Workstream Leader by default. If the problem is a decision, it is certainly preferable to dispense with the decision than the person unless absolutely necessary. Further, if speed is a significant concern, this model allows for a correction to be made in 6 days in the worst case vs. 22 days under the current model.

I would also add that this sort of mechanism exists in traditional corporate structures, as decisions can always be overridden from above. Here, Workstream Leaders are directly accountable to the community, and their role is to fulfill the directives that the community has set. Adding a mechanism through which the community can override Workstream Leader decisions is a direct analog to the mechanism that is not only useful but necessary in traditional corporate structures.

Note that none of these mechanisms are ever used in this model so long as Workstream Leaders are continually viewed by their team and by the leaders of other workstreams to be acting according to the directives set by the DAO and halfway reasonably toward their own team. That there seems to be such strong pushback to the idea of adopting policies for keeping Workstream Leaders in line directly obviates the need for these mechanisms to exist, in my opinion.

[pastaghost]

Hi ,

I think you may have misunderstood the directive in the resourcing section. With regard to hiring, the proposal states that the Workstream Leaders have the authority and autonomy to make both hiring and firing decisions, but in the event that 50% or more of the workstream strongly disagrees with the decision, then they have an option to appeal and let the community decide the outcome of the decision.

[Giantkin]

No, think i still feel the same way. someone i brought on, isnt doing their job, but they are liked by others, can stop me from removing them. that doesnt sound like the leader has any control. They can easily setup a proposal that would do the same thing. Much smoother. Why have any leaders at all if they are easily removed, by those they decided to use.

[Giantkin]

im not sure i see why another proposal isnt being put up that maybe focus’ on a job to be done. something like. ok, now we dont have anyone that knows about … webusb and we use that alot. Proposal that a team works on that.

[pastaghost]

To be sure we’re on the same page about how this is proposed to work, a >50% majority of Workstream Contributor opinion does not determine whether or not a firing decision is overturned. The majority opinion is required to qualify the appeal to go through governance, and the community decides whether or not the firing was legitimate.

Even in the case that community sentiment overrides an otherwise justifiable firing decision by the Workstream Leader, if it is the will of the community that the Contributor stays on the team, then that’s how it should be. The Workstream Leader may disagree in that case, but it is ultimately not up to the Workstream Leader. The workstream is funded by the community, and it is the community that has the final say in how those funds are spent. The role of a Workstream Leader is to ensure that the objectives set by the community are fulfilled, not to set those objectives independently.

[Giantkin]

That… ill have to think on. (maybe you had that in some of your posts, but missed, as its alot of info in huge blocks - so that might have been me)

Only thing is after that… it would make working in the same group alot harder. and the person …notfired… feel invuln. most likely causing the leader to feel powerless, and unable to do their jobs. (just thoughts to consider) (disenfranchised? might be the right word)

[0xean]

thanks for the responses!

mcchadwick:

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.

I don’t agree with this. This allows a single person who has just been fired to now effectively block the actions of the workstream entirely. This seems like the wrong balance of power. Workstream leaders have been backed by the community as trusted leaders, to then enable the minority ( 1 or 2 fired contributors) to hold the workstream hostage does not make sense.

mcchadwick:

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.

You are also now setting up an environment of extreme accountability / transparency, which I know is something many contributors in the DAO wont like. Do you want a leader who is going to very closely track, monitor, and document each contributors progress and performance to ensure that if need be they will be able to fire that person? The tools to do this, especially for engineering, are there but most engineers are very weary of that process and teams that operate in that manner. It is no longer enough for a manager to understand an individual’s performance on the team, but now the entire community has to be able to understand it and correctly vote on it.

[con5cience]

mcchadwick:

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?

It was not really an issue at centralized Shapeshift. Squads usually got a completely broken-down body of work to complete, and were empowered to spike moar if needed. They were also empowered to implement features in whatever way they saw fit. If another squad disagreed with how that was done, they could fiddle with that when they got work that touched the same area of the ecosystem. There was also a great deal of cross-pollination of ideas and conversation via peer review and demos/office hour-style events that were scoped only to Engineering. Additionally, we had an architect role at the top who’s primary responsibilities included maintaining and enforcing standards coherence, and they were sufficiently blessed with authority to direct solutions one way or the other when clarity or an external decision was needed on implementation.

Anyway the tl;dr is that, to my potentially inaccurate memory, there weren’t any inter-squad disputes of significant magnitude that they required some manner of intervention from leadership. If there were disagreements, they were usually intra-squad, and they got hashed out via civil private discussion, or our Architects would swoop in and provide some extra guidance.

[pastaghost]

Hi ,

0xean:

I don’t agree with this. This allows a single person who has just been fired to now effectively block the actions of the workstream entirely. This seems like the wrong balance of power. Workstream leaders have been backed by the community as trusted leaders, to then enable the minority ( 1 or 2 fired contributors) to hold the workstream hostage does not make sense.

I think you might be misunderstanding this mechanism. It does not state anywhere in the definition that all actions of the workstream are halted during the time that the appeal process takes place. There is no provision that allows a workstream to be effectively “held hostage” by any of its contributors. Upon receiving a termination notice, the Workstream Contributor has the option to appeal the decision to the community in the case where he or she believes the decision to be unjustified. I’m not sure why this seems novel or unfamiliar to you - Amazon, your former employer, has a nearly identical process. At Amazon, employees are given three options upon receiving a termination notice:

1.) to accept the decision along with a severance package

2.) to enroll in the Pivot program, a performance improvement plan

3.) to appeal the termination decision to a group of Amazon employees

By the accounts of Amazon employees published online, the appeals process is successful around 30% of the time. This demonstrates two things: it is expected to be more likely than not that a termination decision made by a Workstream Leader will be upheld, and that there is a sufficiently large number of illegitimate terminations even at successful companies like Amazon for this mechanism to have significant utility.

I’ve slightly modified the process here to make it even less cumbersome to Workstream Leaders in that eligibility for the appeals process at all requires >50% support from a Workstream Contributor’s team.

0xean:

You are also now setting up an environment of extreme accountability / transparency, which I know is something many contributors in the DAO wont like. Do you want a leader who is going to very closely track, monitor, and document each contributors progress and performance to ensure that if need be they will be able to fire that person? The tools to do this, especially for engineering, are there but most engineers are very weary of that process and teams that operate in that manner. It is no longer enough for a manager to understand an individual’s performance on the team, but now the entire community has to be able to understand it and correctly vote on it.

I don’t see anything objectively extreme about the level of accountability that I’ve peoposed; this only holds Workstream Leaders to some accountability. You proposed in your response the adoption of tools that continually track and publicize the individual progress of all contributors, but I have not anywhere advocated for the use of those tools, nor would I.

All that a Workstream Leader is required to do under this model is to be prepared to provide reasonable justification for having terminated a Workstream Contributor. That should be the case with or without the appeals process in place. Under the strategy that you are proposing, Workstream Leaders would be able to terminate Workstream Contributors for any or no reason at all, such as “idk felt right lol.” This is clearly untenable in a space where Workstream Leaders have little direct oversight, and a great number of serious companies do not operate this way for obvious reasons.

In the model I am proposing, should a completely voluntary appeal take place, the Workstream Contributor (only with majority support from his or her team to do so, mind you) will merely be given the option to assemble evidence and demonstrate that the firing decision made by the Workstream Leader was in error.

[pastaghost]

Hi ,

con5cience:

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.

Ah, I see what you’re saying now. That’s a good idea - I’ll make that change.

con5cience:

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

The workstream targets and metrics by which the performance of each workstream is to be judged is included as part of the workstream proposal. Analysis of workstream performance in comparison to the originally stated targets has typically been performed by the workstream internally and announced at renewal time.

con5cience:

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?

I totally see where you’re coming from, and that was not my intent at all. By “incorrect”, I mean “mistaken in subjective perception of the preferences of the community” with no fault or negative connotation implied. If there’s a better way to phrase that, I’ll happily go back and replace all uses of the word “incorrect” above.

con5cience:

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.

I think this is good. Much of the pushback against these mechanisms has been given in terms of concern about a hindrance to operational velocity. Skipping the meta-processes and allowing these decisions to go straight to governance should substantially ameliorate those concerns. I don’t see a good reason to spend 11 or so days going through the meta-processes plus governance when we could just skip straight to governance, have the community make a decision, and get back to work. I’ll modify the proposal to remove the meta-processes where appropriate.

[willy]

If you consider this proposal carefully and in the context of your experience at the DAO and at centralized ShapeShift prior, you’ll see that it should not in practice be any slower than or even distinguishable from SCP-92, except in serious cases where corrective recourse is needed. This does not restrict the authority or autonomy granted to Workstream Leaders relative to SCP-92, and that is intentional. Instead, it seeks to establish policies to adeptly handle highly unusual situations in ways that minimize damage to the DAO.

I did consider this proposal carefully, and do not agree with this. Simply having longer definitions makes our entire organizational structure and gov process harder to fully grok. We’re seeing ample evidence in this thread that this definition is hard for active contributors to follow. We should strive to keep our organizational structure and governance processes as simple as we can, only adding additional definitions when necessary. I think SCP-92 does this well, but don’t think this definition does for the reasons posted previously.

This is not an additional requirement, only a statement of the existing requirement and a definition of what is to take place should the Workstream Leader be removed by the currently existing mechanism.

My point is that we don’t need additional definitions or processes. Our existing governance process already gives the community ultimate control over a workstream. That said, it would be very strange for the community to ever vote to prevent a workstream leader’s decision to let a contributor go. I think it would make much more sense for the community to either replace the workstream leader if they no longer had faith in them, or for the contributor who was let go to propose their own workstream or even permanent tenured salary from the community if that’s what they want. All of this is already possible in our existing governance process without unnecessary legislation that complicates our entire org.

if any Workstream Leader is regularly at odds with >50% of the Workstream Contributors on their team over issues that the Workstream Contributors believe they can argue to be a threat to the DAO, then there is a serious problem. I have not seen any indication since the DAO began that this is a regular occurrence on any of the workstreams.

Yes, any community member can currently make a proposal to request the removal of a Workstream Leader. In practice, this is extremely difficult to make a case for, and takes more time than is justifiable in the event that a Workstream Leader needs to be removed quickly. With the specification that this mechanism indicates the Workstream Contributors (who necessarily have the greatest context on the competence of the Workstream Leader) from one team have declared their Workstream Leader to be incompetent, this motion carries a greater degree of gravitas than does an ordinary proposal. Furthermore, the path through an expedited governance process allows for the decision to be made quickly, saving time and minimizing further damage in the event that this is necessary.

While I would disagree that we haven’t seen this yet (growth splitting from marketing for instance), even if you argue that we haven’t seen it doesn’t mean the process is broken. In practice, the route you are taking to alter our entire org rather than a more focused approach is more difficult and less likely to be effective.

–

Note that none of these mechanisms are ever used in this model so long as Workstream Leaders are continually viewed by their team and by the leaders of other workstreams to be acting according to the directives set by the DAO and halfway reasonably toward their own team. That there seems to be such strong pushback to the idea of adopting policies for keeping Workstream Leaders in line directly obviates the need for these mechanisms to exist, in my opinion.

We don’t need special mechanisms. The more special mechanisms we have the harder our org is to understand. Also I disagree with these special mechanisms. They seem like a worse approach to potential issues than our existing, simpler process.

I’ve spent a lot of time expressing my disagreement with this proposal and you do not seem to want to budge. Feel free to propose as is if you have sufficient upvotes at the end of ideation. I plan to vote against this as I think it would be a major step backward for the DAO.

[0xean]

Its increasingly hard to follow your arguments across these threads.

Here you are modeling policy after mega corps, and in others arguing against corporate structure (Cuts, Cuts, Cuts & The ShapeShift DAO - #16 by mcchadwick)

The analogies to traditional corporate structure cannot apply here, because the essential preconditions for successful operation of an organization of that form do not exist here.

Additionally, if you want to adopt Amazon like policy’s you have to understand Amazon’s culture and the amount of time from both managers and engineers spent tracking and documenting performance. A policy that requires a workstream leader to prove to the entire community that a person is underperforming will require them to invest time and effort into tracking and making publicly visible each engineers performance. I have very hard time believing that this will not change the culture, processes and therefore tooling within a workstream.

[pastaghost]

, thanks for spending as much time as you have on this. Even though we disagree (which is completely fine and furthermore expected from the community in part - I’d be skeptical about whether a proposal on this topic had been well-considered if it received unanimous support or the opposite), I can see that you put a lot of time and effort into your responses and your engagement here has demonstrated that this is an extremely valuable part of the governance process as are you. Gm ser.

[pastaghost]

,

0xean:

Its increasingly hard to follow your arguments across these threads.

While that may be true for all I know, having spoken with you on several occasions about other matters, you are going to have a very difficult time convincing me that you of all people are actually experiencing any intellectual difficulty with this. Corporations do many things, have many policies, and put in place many practices. Disagreeing with one policy or practice put into action by a corporation does not mean that I cannot simultaneously find utility in another, entire separate policy or practice. In the same way that I do not have to subscribe to the entire ideology espoused by a political party to find one or more of its positions to be useful, I don’t have to purchase the entire catalog of ideas to find value in one or more of the listed items, so long as those ideas are not in direct contradiction with one another. I know that you know this, but I’m clarifying my position for the thread.

I argue in the thread that you linked (which I would appreciate your feedback on in another conversation, btw) that the application of a strict hierarchical corporate structure at the DAO would be a mistake. I do not think anything I wrote there implies that I think the DAO should, without proper evaluation, write off any policies that may have previously proven to be valuable at other companies, specifically because they are put to use in corporate-land.

I think that we’re at risk of getting a little off-track here, so let’s try and bring the conversation back toward the direction of cleaning up the proposal before governance. Thanks, .

[0xean]

Sounds good, thank you for the conversation and discussion. I wont be around to vote on this one either way but think all of the discourse does ultimately help the DAO. Good luck with the revisions.

[Giantkin]

Thinking about this still… Im still against it. Only thing i can think of is an Anology.

The DAO owns the company. They designate a Captain to build (or take over) one of their ships. That Captain brings on a crew. One of that crew isnt doing their job, (for whatever reason) captain decides to drop that crew member off somewhere. That crewmate goes to the other crewmates that like him enough to stage a mutiny. Either the captain is killed off, or removed and dropped off instead.

Yes, that is how i see it. Now the next Renewal comes up, maybe the Captain didnt do a good enough job, and is relieved of duty. Myabe that ex crew mate goes to the DAO and states a case to work on something, and does his own Ship (either right away, or later)

If the Captain isnt trusted by the DAO, then a Proposal could be put up to remove/replace without any issues as well . Without having the Mutiny first. no 50% needed. just put up a Proposal stating such. From my point of view ofc, if the other Captains thought i was failing, i would work on things, or look for a replacement myself. (but that might just be me)

I am anti corp set up. Unions (which is roughly what this feels like) isnt a great setup.

Thanks! 1f642 Mostly been a fun conversation.

*edit. i have NO idea why that part BOLDED. (and intially, it quoted first…) trying to clear those.

[elmutt]

I support this definition and the additional flexibility it brings. I’m also having some trouble understanding why many community members are SOOOOOO against it. Its quite similar to the original and I believe the additional checks / balances could be helpful. It’s most likely the types of situations where the checks / balances are needed will never occur, and if they do I think it’s a good thing to have some of these scenarios spelled out.

I will be a strong YES on this proposal if it goes to vote

[PTT]

a lot of this isn’t what I see as part of a workstream leader and will be voting no at this time.

[Josh_shapeshiftdemo]

I understood from the governance call that you will be splitting these into separate proposals, and then each can be debated separately. I think that’s a great idea. Thanks.