Topic on Talk:Wikimedia Technical Engagement/Team Social Norms

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.

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.

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.

Make me a bit sad that none of the above made it to the team social norms.