Yes indeed. Part of this is about clearer expectations among the existing team. But the main goal is to have clear expectations as we do outreach to recruit people for the unfilled roles.
Driver statement updates from me, longer but more complete:
[current situation]: Team communication and momentum is inconsistent and unpredictable. Some team members seem inactive. We don’t have clarity about what commitments and agreements are expected of either continuing team members or potential new volunteers.
[effect]: We’re not reaching our potential, and it’s not clear who is going to do what to get back to better forward momentum.
[needs]: We need clearer expectations and accountability from everyone. Better to have clear but reduced commitment from someone than to have expectations that are repeatedly not met.
[impact]: Clearer and realistic written commitments, agreements, and expectations will increase everyone’s motivation and will enhance trust and mutual support.
I’m not thrilled with the extra wordiness, but I wanted to get across some other language about the significance here.
I’d like to settle on some good enough wording soon so that we can then refer to the statement as we flesh out the relevant agreement documents.
Note that this should probably be modeled on our Code of Conduct. I.e. that is formed as a pledge of “I will” statements about respectful engagement. We could do similar for stating team commitments. Perhaps even some flexibility where people can check which commitments they feel they can make and stick to, which may vary.
Sounds like you want something like the following:
If I agreed to do something, I will do it. If I still break an agreement, I will a) clean up disturbances, b) follow up as soon as possible with those affected and c) change the agreement instead of repeatedly breaking it.
I will respond to all snowdrift-related messages within 48 hours. (Responses are allowed to be “sorry, have no time for this currently” or similar, but I will make sure to respond at all.)
I will participate in the weekly meetings. I will be on time and will stay at least until the formal end of the meeting.
I think it should be fine to do everything else on a case-by-case basis via the respective role descriptions, WDYT?
IMHO it would make sense to have defined membership of the weekly meeting (non-members would still be invited to come, but they might not have consent rights depending on how the actual meeting members decide to handle that), and I think the above could be small/easy-to-keep enough to be a condition for membership. If so, a “meeting member” role could be a good place to document this.
@photm seems like a pretty reasonable draft. The 48 hours seems tight at first glance but if you at least say “can’t address this immediately” or something I think it is a logical timeline.
I do think there’s consensus that we don’t expect people to participate in every meeting, but to at least send regards/notification when absence is expected.
I think this is a great working draft, thanks!
It’s one part of a larger commitment, but it addresses the issues here.
The one detail: on meetings, my feeling is to emphasize the importance and value, run excellent meetings… but not put participation in every meeting as part of the commitment. I’ll accept someone formally on the team who commits to making meetings a reasonable priority and to communicate clearly about expectations.
Acceptable (IMO) meeting commitments include:
- “I just can’t make the current time given my current schedule, but I’ll keep it in mind if my schedule changes or the Snowdrift meeting time changes”
- “I can’t make the meetings reliably, but I will attend when I can and send my regrets (in advance whenever feasible) when I can’t”
as long as those go along with saying, “I will review meeting minutes when posted and proactively follow up on anything I see relevant to my roles” or similar
5 posts were split to a new topic: Consent processes for meetings vs forum or other asynchronous
Adopted from @photm’s suggested agreement
This is still a draft, but I’ve organized it in a way that it seems more appropriate to me: there’s only 2 agreements as a team member (with no explicit consequences at this point - and I hope we never need to have any!), but the implied ‘what does it mean to agree to something’ is clearly stated: this is referencing the principle of accountability from Sociocracy here. @salt I’m particularly curious if you think this is reasonable based on what we discussed
I agree to:
participate in as much of the weekly meeting as I can; If I am unable to attend, I will give notice of my absence in advance (by the meeting’s start time) and relay any pertinent information to the agenda (either through another team member or by adding items to the agenda)
respond to all snowdrift-related messages within 48 hours of being made aware of them via my preferred contact method; If I have other matters that take priority and can’t fully respond in that time, I will notify another team member.
For any agreements I make related to Snowdrift.coop (including the ones above), I will follow up and be accountable for the actions I agreed to. If I break an agreement, I will:
- Clean up disturbances caused
- Follow up as soon as possible with those affected
- Change the agreement instead of repeatedly breaking it
A couple of grammar items: 1) the “or by the…” probably doesn’t need the “or”, 2) close the parenthesis on the first agreement, 3) the second agreement doesn’t necessarily need the parenthesis, 4) the sentence starting with “For these agreements…” is currently in a couple of voices.
Otherwise it looks good and seems short/simple enough to address my concern.
Thanks for the feedback and I’m glad you think so! I updated it and yeah, that last bit was awkward thanks for pointing that out
Just wanted to share some select points (the ones in bold):
- Make clear agreements ( who will do what by when ) that you have a whole body yes to.
- Record your agreements (use a tool like asana).
- Keep 90% of your agreements. Most individuals and teams keep less than 50%.
- Renegotiate your agreements with the affected parties as soon as you know that you might not keep the agreement.
- If you break an agreement, clean it up and restore any broken trust.
Asana is not open source so we can ignore that part but hopefully the rest is useful: Very good practices in general, I’d say. Here’s the whole post:
This sounds as if you should always immediately modify an agreement if you break it once. Is this intended? The S3 pattern breaking agreements says “3. change the agreement instead of repeatedly breaking it”.
Poignant observation photm. I don’t think it’s the clearest language sociocracy uses on that one so I was attempting to clarify and wanted to integrate this point into it
But failed. I reverted the last line of the agreement back to the original @salt I’m confident that won’t be a game changer for you
3 posts were split to a new topic: On “priorities” vs “having time”
In addition to what came up in meeting, I suggest we add a line that mentions keeping your communication preferences updated.
As we finalize this for a consent proposal, I suggest we consider at least these items from the original (old, outdated, and archived) agreement at https://wiki.snowdrift.coop/archives/community/join-committee
- Keep up with the accountabilities for any particular role(s) you accept
- Be available within a reasonable time-frame when others need your involvement and at least communicate clearly when availability may be limited for some reason. [this largely seems covered by the new statement]
- Assure that some representative from each main internal team attends our weekly check-in meetings or at least sends regrets and provide an email update on team progress. [this largely seems covered by the new statement]
- If you cannot maintain your role(s) going forward, communicate the situation clearly and make an effort to find someone else to fill the role(s).
The proposal we have in this topic doesn’t specifically reference role(s) and accountabilities or stepping down from roles with adequate communication and assistance with succession. But maybe “agreements” covers that stuff as long as we make sure that accepting a role is itself where people commit to the accountabilities and the succession planning.
Incidentally, the succession and stepping-down stuff may not be enforceable, but that’s not the point. The point is commitment to this when someone accepts the team membership in the first place.
Meeting availability wording
One more point: I’d like to make sure that the meeting-participation wording doesn’t turn away valuable team members who just may not have compatible availability for meeting times that work for others.
Maybe we should explicitly describe that scenario. People who have schedules that just don’t work for meetings are expected to do something to make up for missing. Maybe that means aiming to usually read over meeting minutes and post any thoughts and concerns?
Team members on hiatus?
How does this commitment relate to situations where someone has to be away for an extended time? Wouldn’t we accept that as long as we’re told in advance and have an idea of the expectations? I don’t want people to be on and off the team each time they have a long vacation or some priorities come up that make them less reliable for a month or two (when they at least make sure to address the issues their absence may cause, and when they really intend to be back and catch up later). Thoughts on this?
I think there needs to be as much flexibility as possible in how much responsibility someone will accept. This way, the barrier of entry to be accountable for doing something is much lower. I’m concerned that succession is a huge and hard job to take care of, so it might be harmful to hard-wire it into all roles.
Maybe the team could do role selection (S3 pattern) to take care of finding someone else to fill the role? Maybe have limited terms to a) reduce the barrier of entry even more, b) reduce the barrier for leaving early enough so you still have the resources to hang around and help the next role-keeper, c) rotate roles where this makes sense, to prevent the role-keeper from accidentally accumulating lots of information that gets lost once he leaves.
I agree, but the original wording of “make an effort” could be maybe rephrased as just “please do what you can to help with succession”. The commitment to tell us at least when you can’t maintain the role (rather than just neglect it and disappear) still seems important at least.
I think this is implied by the nature of agreeing to respond to
If you agree to respond to that, I don’t think that needs to be explicitly addressed that if you don’t want that to be your preferred contact method, you need to update it. I think avoiding adding unncessary details is pretty important: the longer the agreement, the scarier/more dramatic it will be to consent to it
In regards to this, I don’t know it needs to be explicit. Again I agree with @salt to keep it less wordy in general, and this may be more of a case by case basis, a more human-to-human situation as it arises (and if it comes up as an issue after these agreements, then we can always add it in after the fact)
Okay, so I don’t mean that every detail has to be in this statement, but we need a single-starting-point documentation that includes things like a link to the preferred-contact post etc.
Maybe this statement doesn’t need to link to further documentation, but being a team member involves the other stuff. And someone joining the team should be able to review what is involved in being on the team.