Talk:Wikimedia Cloud Services team/Team Social Norms

This is awesome

Thank you for making this explicitly written down! <3 YuviPanda (talk) 20:58, 28 September 2017 (UTC)

Thanks Yuvi :)

k CPettet (WMF) (talk) 15:51, 2 October 2017 (UTC)

Pile on of thanks. This is indeed very awesome and a great tool for onboarding new engineers (volunteers or staff). Thank you. Greg (WMF) (talk) 18:52, 3 October 2017 (UTC)

Adding to the thanks/kudos pile :-) KLans (WMF) (talk) 16:59, 6 December 2017 (UTC)

Concerns without having a solution?

I'm always nervous about a norm saying that you can't critique something without proposing an alternative. Often, people have concerns, but might not have a solution in mind yet. It can be really helpful to surface those concerns, so the group can brainstorm ways to solve them...or can reveal that the concerns are unfounded.

While I support not "objecting" to something without having an alternative, I would like to see this bullet encourage other forms of open questioning or critiquing. KSmith (WMF) (talk) 16:18, 3 October 2017 (UTC)

I think potentially that "Sometimes the alternative proposal is a reframing of the original problem and that's OK." is meant to convey this is a good pattern. Wording/rewording ideas? CPettet (WMF) (talk) 18:11, 3 October 2017 (UTC)

There is space for critiquing without solutions as long as it's done well (imho). For instance, the difference between "That won't work." vs "Did you think of some_other_constraint?" But, I don't think the best use of this document is to wordsmith but instead give general guidelines. In so far as that is concerned I think the current language is good enough (because I believe my "did you think of X?" is covered by what Chase said. Greg (WMF) (talk) 18:56, 3 October 2017 (UTC)

I want to encourage people to say "I really dislike that the proposed solution will cause problem X", or "I really dislike that the proposed solution doesn't also address Y", or "The proposed solution feels messy", without already having an idea of how to improve it. Those seem stronger than (and distinct from) "Did you think of X?", which can also be helpful.

The text in the paragraph does seem to roughly cover my case, which I didn't think it did when I posted this topic. I think the heading was so strong ("propose") that I overlooked that the version below was friendlier ("help craft").

If this were my team, I would push to change the heading (to something like "Do help find an alternative path if you oppose one"). Or "Do help find an alternative if you oppose some path". But if the existing version works for this team, that's cool. KSmith (WMF) (talk) 21:34, 3 October 2017 (UTC)

"if you oppose, then propose" is more of a truism than a purely functional instruction, where I think the wording may seem more forceful but it's really just catchy :)

It's like a proverb instead of a literal "Do not speak unless you have figured out a completely viable alternative". I totally appreciate what you are saying. I'm not sure if the widely used phrase is valuable enough to keep if it contributes to misunderstanding, but the intention here was to associate with the adage in wider use within effective meetings and team building circles.

IMO the problem at the microscopic level this is trying to provide tools for is where person A says "I've been tripping over these boxes for weeks and I'm proposing we move them to the storage room". person B (who often is more senior or has more team equity) doesn't like boxes in storage rooms on principle and says "I don't want to do that, because I don't like the idea of boxes sitting in storage rooms". person A has now had their original problem invalidated and has been effectively cut off from the means of team problem solving. person B could instead say "I really don't want to put boxes in storage rooms, can you help me understand what the original problem you are trying to solve is so we can work together?" i.e. reframing the problem. person B could instead say "I really don't want to put boxes in storage rooms, could we recycle them instead?". It is closely related to the no-sideseat / no backseat driving idea in that team members problems are important and part of recognizing that is letting them solve them or being meaningfully involved. I've heard the "drive by nope" or "drive by -1" meme in use here and other places, and funny enough just last week at a conference I heard this referred to as the "seagull issue" within unbalanced and unhealthy teams where someone will "fly over and poop on" other peoples problems and possible solutions without becoming involved to find better outcomes.

But while it's meant to empower the initiator and proposer I can see how the fear of the pendulum swing is totally valid. I'm thinking on some additional text that could be added to round out the the purpose. I think something along the lines of "Efforts made to help explain the problem to collaborators are necessary for reciprocal good faith" and something something. I don't know yet :)

---

If you'll allow me to digress way outside of that box for fun, my subjective macroscopic view is that this truism is centered around team buy-in for problem solving and is meant to bolster the value of "new ideas" intrinsic to continuous improvement models. Usually, the first thing to go in a closed-off, shutdown, psychologically unsafe team is the proposal of new ideas or improvements because it's a lose-lose scenario for the proposer. All new ideas are foreign by nature, and all new ideas that challenge long-held assumptions will be difficult for a team to digest. Whether they are productive ideas or not being secondary. One of the core and most illusive components of Kaizen is written on enwp as:

"The idea is to nurture the company's people as much as it is to praise and encourage participation in kaizen activities."

I always want to find that feedback cycle where we gain by fostering the proposal of new ideas as well as the ability to evaluate them in the context of the system. The system itself is healthiest when the ability to propose is most protected, but that is not code for "battering ram of unstoppable change".

I tend to think teams that grasp for the meaning and not the letter of the law here could be shared something like this:

"It is the mark of an educated mind to be able to entertain a thought without accepting it." -- totally disputed aristotle quote

Could be rewritten as:

""It is the mark of a healthy team to be able to entertain a proposal without feeling forced to accept it."

-----

Other uses:

Ground rules for improved meetings in Immediate Cardiac Care Unit

...

• If you oppose, you must propose.

...

Quality By Design: A Clinical Microsystems Approach, page 255

-------

Conducting Effective Team Meetings

"One helpful adage to keep in mind is: “If you oppose, you must propose.” That is, if you are opposed to one solution it is helpful to propose an alternative solution. The meeting chair can help promote this approach by responding to a negative statement with, “What do you think is an alternative idea we should consider?”

https://www.stepsforward.org/Static/images/modules/9/downloadable/Conducting_Effective_Team_Meetings.pdf

-----

Getting Information Into The Room

|PROPOSAL

|When you need a suggestion, ask for proposals.  Use this after several ideas have been shot down by group members.  “If you oppose, you must propose” is a team-building ground rule.

|}

https://collaborationzone.com/building-your-team-as-they-work/ CPettet (WMF) (talk) 14:03, 4 October 2017 (UTC)

Thanks for the detailed reply. I am well aware of the concept, but I'm not sure I had heard the specific "if you oppose, you must propose" wording before. If I have, it probably hasn't stuck with me because I disagree so strongly with the sentiment.

Perhaps part of the disconnect is that the context matters. In some wikimedia communities, or online discussions in general, there is no shortage of naysayers, trolls, obstructionists, etc. In those situations, I can see value in pushing people to engage with constructive comments, rather than just "No, I don't like it."

On "teams", however, I think it is better to encourage conversation. It takes a lot of guts to stand up and say "I have concerns about this proposal", especially if you haven't yet figured out how to improve it. But from my perspective, it's really valuable to do so. The alternative is to have people with valid concerns remaining silent and feeling shut down, resulting in flawed proposals moving forward because the necessary conversations never happened.

I guess I have seen failure mode B a lot, and A rarely, whereas others have had the opposite experience. Perhaps I'm in the minority here.

The most important thing is for each team to figure out what will work for them. If it's a highly vocal and critical team, then the "must propose" rule could make sense. If the team includes quiet or conflict-averse members, then a different rule might be more productive. KSmith (WMF) (talk) 16:40, 4 October 2017 (UTC)

I agree the leading part of this is aimed at highly vocal and critical environments.

I'm wondering how you feel about https://www.mediawiki.org/w/index.php?title=Wikimedia_Cloud_Services_team%2FTeam_Social_Norms&type=revision&diff=2578634&oldid=2573754 CPettet (WMF) (talk) 12:32, 5 October 2017 (UTC)

1. I felt compelled to raise this issue, but am reluctant to push my viewpoint further. It seems like the team is happy with this point, and it's not my place to change your/their minds.
2. For me personally, the heading is still problematic, and the accompanying text hasn't really addressed my concerns. But see point #1.
3. I think the new paragraph could use some wordsmithing to be clearer and tighter (without changing its meaning). I'll follow up through other channels with suggestions

As an aside, I appreciate all y'all's care and thoughtfulness with this page, and with this thread. Knowing the participants, I'm not surprised by it. But I still wanted to acknowledge it. KSmith (WMF) (talk) 17:29, 5 October 2017 (UTC)

awww

I also <3 how you integrated CoC into this. Elitre (WMF) (talk) 08:34, 15 December 2017 (UTC)

Norms adopted by the Developer Relations team

These norms originally created by and for the Wikimedia Cloud Services team have been officially adopted by the Developer Advocacy team. As a result I have moved the content page up to the shared parent Wikimedia Technical Engagement team. BDavis (WMF) (talk) 22:37, 1 August 2018 (UTC)

Translatability

I dislike the line about "No well-actually's". To understand what that really means, you have to know about a particular internet meme, which is a narrow audience. Would you consider changing it to something that translates across languages and cultures, such as "No pointless pedantry"? Whatamidoing (WMF) (talk) 18:47, 14 August 2018 (UTC)

I don't know that meme and still liked that line. I've found myself a few times starting sentences like that without bad intentions but see how it's unhelpful. So I wonder which 'real understanding' I might be missing and if it's crucial. :) AKlapper (WMF) (talk) 02:17, 15 August 2018 (UTC)

I only know it's a meme because I asked a famous web search engine about it. My first thought was that they didn't want people to say things like, "Well, actually, now that I've thought about it longer, I think you're right". Whatamidoing (WMF) (talk) 21:51, 16 August 2018 (UTC)

I also don't consider it to be (meant as) a meme. It works for me FWIW, from my humble POV of a non native speaker. :) Elitre (WMF) (talk) 10:14, 24 August 2018 (UTC)

Reception vs Intent

We were talking about the "no subtle -isms" item, and Bryan had a good explanation that included some comments about the distinction between how a word/phrase was intended, vs how it was received, and trying to be mindful of the latter.

I think it would be really useful to add that abstract explanation into this page. I don't recall the specific phrasing that was used, and don't want to get into specific examples, so I'm hoping Bryan or someone can help.

It could potentially also/alternatively be mentioned within any of the "Do apologize" or "Do forgive" or "Do reflect" items.

Part of it is "know your audience" (e.g. not making 'mature' jokes around people unless you know them really well). But that's not possible in an public/broadcast settings, where the potential audience is the whole world!

One way that I'm thinking about this, is trying to be aware of the complexity of words with different nuanced meanings in different contexts. I.e. Many words can be understood in different ways, and that if you're talking to someone outside of your closest peer group it's good to remember to try to be aware of the possible misinterpretations. Quiddity (WMF) (talk) 09:14, 23 August 2019 (UTC)

Reframe to aspirational rather than what we are

It is alluded to, a bit, with the quote opening the wiki page. Though these values should be reframed away from what we are, and to what we want to be. Open source communities often produce great things. Unfortunately they are often centers of toxic behavior. We are a product of the larger open source world, we cannot escape that, and thus don't really live up to our social norms. Rather we aspire to. I think by making clear that this is what we want to be, rather than what we are, it provides two views that are different from what we have today. One it encourages everyone reading to think about what they do that could be done closer to what we want, rather than "These are our norms. I'm part of the group, therefore I'm what's written here." being the thought, it shifts to "None of us really do this, we come from communities that don't do this, but we can. What do you not do on this list?" Which ties into the second part, the other change is that by stating that we are not this, but want to be it, when we mess up, which we all do, it makes both apology and reflection much easier. The psychology shifts from "Oh! I broke the rules! That everyone else is following! I'm terrible, and not part of the group." Encouraging one to hide what was done, or try to reframe themselves in a positive light, rather than simply think about it. When we start from "None of us are this, but we all want to be." It's a lot easier to step back and actually look at whatever happened, and to try to learn something from it, and apologize for it. One is no longer made the black sheep that didn't follow the rules, rather everyone is the black sheep from the beginning. No one is left feeling separated, and improvement is the norm. VRook (WMF) (talk) 15:22, 17 March 2023 (UTC)

+1 to that, I really like the foundation wide one "we strive for excellence", because of that exact aspirational aspect of it 2A04:EE41:89:A0E6:5D4A:BEA8:E054:DDAC (talk) 14:46, 6 April 2023 (UTC)

(that one was me, forgot to log in xd) DCaro (WMF) (talk) 14:53, 6 April 2023 (UTC)

The lead of the page I hope conveys some of the historic intent:

Our team social norms help aim to guide our behavior in the workplace and improve our collective civility. These norms are unique to the Technical Engagement team, but should be seen as extensions of other WMF and community initiatives such as the Code of Conduct, the Friendly Space Policy, and the Technology deparment’s Communication Guidelines.

This is not a how-to guide on embodying the idea of a perfect teammate, we all have different backgrounds or stories that might not follow these norms, but we can get there together. There are too many intangibles not included for these guidelines to be the ending to any discussion, but these are specific touchstones that can make up the beginning of one. Humility, generosity, kindness, respect, and integrity are all implicit within the norms.

Having explicit norms help us to increase our awareness that these practices are important and require attention and intention from each of us. It’s also important to hold ourselves accountable and assume both individual and team-level responsibility, let's try and make our when workplace a safe environment for everyone.

I believe that these "rules" are what we hope to do, but it is almost certain that we will occasionally not live up to our own hopes or the hopes of others. "Do Forgive!" applies to ourselves as well as others. We try, we miss, we learn, we grow, we try again. BDavis (WMF) (talk) 19:08, 13 April 2023 (UTC)

And I now see that is fresh prose, so thank you to those who added it. I think it matches the spirit of my historic understanding of these norms. BDavis (WMF) (talk) 19:10, 13 April 2023 (UTC)

The new verbiage does add a lot to the end of this topic. Though why don't we change the title from "Team Social Norms" to "Team Social Aims" Norms implies a degree of adherence that I do not believe we have, nor should we attempt to enforce or create. I suspect such an attempt is more likely to create rather than diminish adversity. VRook (WMF) (talk) 12:31, 14 April 2023 (UTC)

For me personally, w:Social norm is an actual thing, and what we were attempting to describe. "Social Aims" seems mostly to be an essay by Ralph Waldo Emerson. I cannot speak to the current team management practices of the Technical Engagement sub-teams, but when I was the manager these were very much enforced norms in that we actively talked about them and applied them in our day to day work. BDavis (WMF) (talk) 23:21, 14 April 2023 (UTC)

I would agree that for me social norms are an actual thing. And that we don't follow what we prescribe. By claiming a list of social norms, there is an enforcement mechanism of ostracization at play. This is not constructive to getting a community to be more collaborative. As described in the opening message of the topic, enforcement mechanisms cause people to hide things, withdraw, or use some interpenetration of the norms to re-enforce a behavior, usually bad, that they do not feel like changing. VRook (WMF) (talk) 17:10, 17 April 2023 (UTC)

I attempted to capture what was being discussed in this thread in an edit to the opening paragraph. Please feel free to keep editing or discuss if I've not covered everything. One remaining item that I believe is mentioned here, but I'm not sure is addressed is around enforcement or accountability. In the spirit of what I think has been discussed here, I would want to make sure the prose relates that it's about helping each other be better people, and not about punishing those who make a mistake. I think the other policies across the movement, including those linked, better address issues should someone's persistent behavior rise to an unacceptable level. NSkaggs (WMF) (talk) 22:18, 24 April 2023 (UTC)

Discussion: Introduction/framing of the social norms

Discussion: Team Social Norms (do)

Something I miss in this norms is the "Engage" in "Engage in civil discourse", and "Together" in "We are in this together".

I see a lot of norms dealing with individual behavior, specially acting as free agent. But there's not many that encourage, or convene that we are a team, thus we are not free agents but members of an organization (decentralized or not), so we do not act alone, and each of us acts as representative of the group, prioritizing group level goals and duties over individual ones.

In that similar sense, there's little in the norms that would make me prioritize collaborating with others over working alone, as long as I share any learnings (that could be considered done by working in public).

As a data point, there's only one mention of collaboration, and it's as part of "collaboration rather than competition", that could easily be interpreted to not prioritize working with others as long as you are not competing.

I think we should discuss and agree if we should work as a team or as free agents (in the spirit of https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/define-team/, workgroup vs team), and reflect that clearly in the norms.

Once we know how we organize and communicate between ourselves we can start organizing our systems and processes to match (https://en.wikipedia.org/wiki/Conway%27s_law), trying to maintain a system that does not match the way we organize ourselves only brings friction. DCaro (WMF) (talk) 08:41, 17 April 2023 (UTC)

David, I would support the idea that we are a team by the google definition linked. That said, given our broad responsibility set at times (and the intention that these are shared across the department), the "working group" moniker definitely could apply at times. Can you offer an edit or specific prose on what you'd like to see in this space? Would it be an axiom to commit to not siloing knowledge? Something else? It would be helpful for me if you could propose a norm (or edit one) and include a "This can look like" example to go with it. NSkaggs (WMF) (talk) 22:26, 24 April 2023 (UTC)

Some principles/ideas that would point to the direction of "team" as shared in the rework page:

• Nothing is someone else's problem (your problems are someone else's too): Demonstrate care for your teammate's struggles, offer help whenever you can, if something is broken, even outside your comfort zone, fix it. When building something, make sure you share more than enough information for anyone else in the team to jump in and collaborate with them. We collectively share the responsibility of all our services.
• Disagree and commit: When discussing any subject, we offer our personal opinions and points of view, when the subject is decided, we commit to follow the outcome, even if we disagreed with it during the discussion.
• Better together than solo: When starting a project, make sure to plan to include more people as soon as possible, prefer doing things collaborating with others in a slower pace than doing things by yourself faster.
• Shared better than public, public better than private: Whenever possible, actively share your knowledge and situation with others, fallback to just making it public for others to find, and try keep at a minimum private information and communications.

Some practices could look like:

• At least two people per service: each service that the team provides should have at least two people with enough knowledge to keep it evolving. **This does not mean that everyone knows everything**, it does mean that you should not know only one thing.
• Periodical, rotating knowledge sharing sessions, howtos, demos, ... so we have an idea of how things work, what's there and what's not, so we can share insights, learn, discuss.
• Standardize service documentation (similar to the team API effort), alerts, design docs, ... so it's easy for anyone to find the docs on any other supported service (and thus, jump in, help, fix broken things).
• Standardize practices, so it's easier to start working on any other project without having to adapt to all the different processes.
• Shared oncall + alerts + runbooks (as opposed to split oncall, personalized notifications, docs in places that are not common/hard to find)

Some behaviors could look like:

• I start every morning reviewing patches from any project, by anyone.
• I'm creating a new project, and I use the team agreed practices, even though I prefer formatting my code with tool Y.
• I make sure that the team has more than one way to know what I'm currently working on, and actively share that information.
• There's an alert that I don't recognize, and it has no runbook, I jump in to investigate and will write the runbook myself with whatever I find out.
• I seem to be the only one working on this area, let's share that in the next team meeting and find someone else to work with.
• Someone shared that they are working on something by themselves and want someone to jump in, I'll give a hand, as somebody else is helping me now with this other project.
• Feature A on project X is blocking my project, I'll jump in and help delivering it instead of just waiting and expecting others to do it for me.

That should not look like:

• I have to learn everything about everything: you only have to learn as much as you can, but you have for certain have to share that knowledge with someone (might be more than one person for different parts of that knowledge)
• I have to fix all alerts all by myself all the time: you are not alone, and there's a scheduled rotating time to focus on alerts, you will have to focus on it but it's not all of the time, and it's not by yourself.
• I can complain on anything: feedback is always welcome, but constructive feedback is way better, and continuous non-selective involvement is the best way (see the backseat driving rule).
• I should not do anything by myself: there's still times where there will we constrains that will force us to do solo work, that's ok, it should be an exception, and should be remediated as soon as possible.

This was way longer than what I had in mind xd, these are suggestions, not as one block, but each individually. DCaro (WMF) (talk) 08:43, 25 April 2023 (UTC)

Make me a bit sad that none of the above made it to the team social norms. DCaro (WMF) (talk) 09:00, 13 July 2023 (UTC)

Discussion: Team Social Norms (no)

Discussion: Our commitments

I made an edit to remove specific timing for when to revisit these norms. I do think this page will continue to be a part of onboarding and thus will be reviewed accordingly. The statement to "Provide respectful and meaningful feedback to the norms and propose changes if we deem necessary." seems sufficient without more detail. Anyone should be able to propose and discuss these norms as needed. Thoughts / Edits / Reverts welcome! NSkaggs (WMF) (talk) 22:12, 24 April 2023 (UTC)

Discussion: other

Other things you'd like to discuss or comment about the Team Social Norms page. KHernandez-WMF (talk) 18:53, 13 April 2023 (UTC)