Wikimedia Technical Engagement/Team Social Norms
|“||We call them soft skills but they are hard to pull off.||”|
—Kelsey Hightower, (Kubecon 2017 Austin, TX Keynote)
We must work together over the long term to find the best possible solutions to our challenges given our limited resources.
We will need each other as collaborators long after the challenges of today are past.
To survive we must innovate.
To innovate we must share a sense of safety.
To share that sense of safety we must demonstrate respect.
- 1 Do:
- 2 No:
- 3 Origins
- 4 Attribution
- 5 Code Of Conduct
- 6 Further reading
- Do propose a different path if you oppose oneEdit
Beginning with the good faith assumption that everyone is doing necessary work, if you have concerns about a proposal then engage and help to craft an alternative approach. Mindfulness that it requires courage to stand up and say "I have concerns about this proposal" is required on both sides. An alternative proposal can be the result of reframing the original problem and that's OK. An alternative proposal can be an agreement to share knowledge and catch everyone up in the conversation and that's OK too.
- Do apologize for and acknowledge behavior we seek to avoid when it has happenedEdit
A team of humans supporting a 24/7 environment will experience being tired, frustrated, and overwhelmed. Mutual respect is the only currency we have to navigate these challenges long-term. Demonstrating that respect means acknowledging its value. Saying you are sorry is a very grown up and mature thing to do. Being human is tough.
- Do forgiveEdit
Forgiveness is a conscious, intentional, and deliberate decision to release feelings of resentment.
Take a breath. Take a walk.
Demonstrate and share lines of code, adhoc commands, and general understanding. The teams efforts will be limited by the point of the most constraint, and for us that will most often be cognitive constraint. Collaboration rather than competition.
- Do reflectEdit
Give these issues, behaviors, and expectations serious thought and consideration.
- No belittlingEdit
You belittle someone when you speak or act in a way that demeans, trivializes, or undermines a person's worth. “Belittling” is never simply an evaluation or even a negative criticism. It is usually shrouded in the latter, but with the additional intention or effect of hurting or demeaning the other person. In this regard, the medium is the only message delivered, and any possibility of developing psychological safety disappears. This often arises when respect is offered or withheld based on your opinion of a colleague's work rather than based on their inherent worth as a person.
- No feigning surpriseEdit
This means you shouldn't act surprised when people say they don't know something. This applies to both technical things ("What?! I can't believe you don't know what the stack is!") and non-technical things ("You don't know who RMS is?!"). Feigning surprise has absolutely no social or educational benefit: When people feign surprise, it's usually to make them feel better about themselves and others feel worse. And even when that's not the intention, it's almost always the effect. As you've probably already guessed, this rule is tightly coupled to our belief in the importance of people feeling comfortable saying "I don't know" and "I don't understand." See also xkcd 1053.
- No well-actually'sEdit
A well-actually happens when someone says something that's almost - but not entirely - correct, and you say, "well, actually…" and then give a minor correction. This is especially annoying when the correction has no bearing on the actual conversation. This doesn't mean that we don't care about being precise, but in our experience almost all well-actually's are about grandstanding, not truth-seeking.
- No back-seat drivingEdit
If you overhear people working through a problem, you shouldn't intermittently lob advice across the room. This also applies to IRC discussions. This can lead to the "too many cooks" problem, but more important, it can be rude and disruptive to half-participate in a conversation. This isn't to say you shouldn't help, offer advice, or join conversations. On the contrary, we encourage all those things. Rather, it just means that when you want to help out or work with others, you should fully engage and not just butt in sporadically.
- No subtle -ismsEdit
A ban on subtle racism, sexism, homophobia, transphobia, and other kinds of bias. This one is different from the rest, because it covers a class of behaviors instead of one very specific pattern.
Subtle -isms are small things that make others feel unwelcome, things that we all sometimes do by mistake. For example, saying "It's so easy my grandmother could do it" is a subtle -ism. Like the other social norms, this one is often accidentally broken. Like the other three, it's not a big deal to mess up – you just apologize and move on.
If you see a subtle -ism, you can point it out to the relevant person, either publicly or privately, or you can ask your managers to say something. After this, we ask that all further discussion move off of public channels. If you are a third party, and you don't see what could be biased about the comment that was made, feel free to talk to a manager or admin. Please don't say, "Comment X wasn't homophobic!" Similarly, please don't pile on to someone who made a mistake. The "subtle" in "subtle -isms" means that it's probably not obvious to everyone right away what was wrong with the comment.
We want this team and surrounding work spaces to have as little bigotry as possible. Therefore, if you see sexism, racism, etc. outside of our spaces, please don't bring it in. So, for example, please don't start a discussion of the latest offensive comment from Random Tech Person Y. For many people, especially those who may have spent time in unpleasant environments, these conversations can be very distracting.
These norms were originally created and accepted by the Wikimedia Cloud Services team, primarily for themselves, but also as a demonstration of value to other teams. They were subsequently adopted by the Developer Advocacy team soon after its formation in 2018 and thus became the norms shared by the entire Wikimedia Technical Engagement team.
In order to improve our collective civility we have to create a common language of expectations and examine our assumptions about current behaviors. This is not a how-to guide on embodying the ideal of a perfect teammate. 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 Do's.
The point of explicitly recognizing these behaviors is to increase our awareness that these practices are important and require attention and intention from each of us individually.
Most of the content from the "No" avoidance section is borrowed from https://www.recurse.com/manual#sub-sec-social-rules
Code Of ConductEdit
The social norms don't cover harassment or discrimination. We have a Code of Conduct for that. These norms are also not all encompassing or complete.
- w:en:Cynefin framework
- Psychological safety
- Structure and clarity
- Listening to learn https://www.youtube.com/watch?v=Zrg_3KlAE6o
- "If no one has told you yet, as your career in tech progresses you will eventually become a 'custodian of culture.'"
- "Even seemingly small differences in language that we hear and use can determine whether we cooperate or compete."
- "There is no finish line; being a great engineer and a great teammate is a lifelong, daily practice."
- "There are myriad skills a Tech Lead must possess and cultivate, but the most important are sincere empathy, crystal clear communication, and technical excellence. These skills are equally weighted."
- "I think I like 'functional competencies and behavioral competencies' better than 'hard skills and soft skills'. I saw these recommended by Greg Geraci."
- "Abrasive members [of a team] will be the single biggest factor undermining your progressive security efforts."
- "The best advice we give programmers is to leave things better than how they started. We do it with code, why don’t we do it with communities? Why don’t we do it with people, colleagues, friends?"