search

dhis2 / notes

:memo: Memos, proposals, agendas and meeting minutes
19 stars 8 forks source link

Applied principles of Remote Work #92

Closed varl closed 3 years ago

varl commented 4 years ago

Background

Over time I have been asked multiple times to put down the principles Team Apps applies when it comes to making remote work, well, work. I wanted to get this documentation right and have postponed it time and time again because it's a journey not a destination. There is no way to apply these principles once and proclaim that we are now a remote-first environment.

Since I cannot get this entirely right the first pass, and keep postponing it, let's switch tactics to a more iterative approach.

I go on and on about iterative improvements all the time but I failed to heed my own advice in this regard. No more!

Principles

Links

There are many, many, articles on how different places have implemented remote work principles. Here are a few. Most of these are written from the perspective about what the company needs to do to enable remote work, so bear that in mind. There's a whole other topic about what the worker needs to do.

Short and high-level

Changing to remote first/friendly

Mega collections

varl commented 4 years ago

Why do we need principles for remote work?

At the heart of it, it is about consistent individual actions that are coordinated and aligned. We can use orchestration as the ideal:

Orchestration is the automated configuration, coordination, and management of computer systems and software.

Except, we want to automatically instill a culture and "the way we do things around here" into actual human beings -- which is infinitely harder than orchestrating systems. And while bit rot is a real thing in software, it is nothing compared to how fast a culture can decay.

I use "culture" and "how we do things" as positive terms, it is easy to twist these terms to something negative and overly corp-y. Before DHIS2 I worked as a software engineering consultant for about a decade in small and large consultancies, and I've been around many different companies and their identity culture. I am well aware of the brainwashing that goes on in the name of culture. However, culture is not a bad thing. It is a social bond between you and your peers, and it is built into us. That is an important component we need to work well together, to feel connected and in the loop.

When we work together in meat space, we negotiate that contract unconsciously and effortlessly, and we form a bond. This is not how it works in cyber space, yet our instincts crave that connection. We have to continuously work to accomplish that, and one way is to have some principles to guide us. The principles is a common anchor point, and much like having a code style, it gives everyone a free pass to call out "violations" without being rude. It is completely fair to say that something violates our code style, and it is completely fair to remind someone to, for example, turn on their webcam.

varl commented 4 years ago

Communication

Reach across teams

We are one Team, and from that we are split into different operational teams. It is easy to form a habit of talking to the nearest sub-team(s) and we have to exert consistent effort to counteract that. It is especially tricky, as the "sub-team" might not even be a formal team, it might be the five people you ordinarily talk to, or the ones that are closest to you.

It is important to be mindful of this, and that impactful work happens when different functional teams communicate regularly and freely.

Do

:heavy_plus_sign: Talk to people outside of your ordinary clique regularly.

Not

:heavy_minus_sign: Create a bubble of select few that you rely on to get your work done.

Choose your forum

As technologists we have many tools at our disposal to communicate. At DHIS2 we use: JIRA, GitHub, E-mail, and Slack ...

Thought that's it?

No, we also use Google Hangouts, Zoom, Google Meet, Google Docs, Developer Portal, Community of Practice, Facebook, and our main website dhis2.org.

These tools share some traits, and can be grouped as such. If the tools are synchronous or asynchronous is a very helpful rule of thumb to guide your choice of communication forum.

The real-time options (Slack, Google Hangouts, Google Meet, Zoom) are useful if used correctly, but the caveat is that they are actively destructive if not.

Slack especially is extremely easy to abuse as it masquerades under the pretense of an async communication channel. However, it is decisively not.

Slack should be treated as a pure chat tool, it is not the place to for decisions to be made.

The main reason is that only the people who were on Slack at the time had a chance to collaborate. Even worse, there is a high probability that the people not on Slack will never even be aware of the discussion. This is corrosive to the social contract briefly discussed earlier, and leads to a feeling of not being in the loop. Few things are so important that they cannot wait another day if it means including more people in it. If they opt out, that's fine too. Maybe they trust the team, but they still want to review it before it becomes a decision as a sanity check and to internalize it better.

It is great to quickly discuss things on Slack, but the discussion should end with someone drafting a proposal in another forum, where it can be read, referenced, and referred to consistently over time.

Generally speaking it goes like this:

  1. An idea is shared on Slack, a few people enthusiastically discuss it in long threads.
  2. A proposal is drafted in dhis2/notes and a Google Meet session is arranged to discuss it in a more structured fashion.
  3. The discussion is captured in a document, that is committed to the notes repository under the decisions folder. SOP is followed and a PR is raised to the default branch.
  4. The PR is very important. Even if someone was not available for the meeting where the decision was reached, she has a chance to approve or object to the decision before it is final. Once enough approving reviews are gathered to form a rough consensus, it can be merged.
  5. Now there is a paper trail from inception to final decision, and since there were plenty of asynchronous steps, remote workers from all time zones has a chance to weigh in.

Going from a Slack discussion to immediately to a decision can and does happen, but the decision should always be captured outside of slack. Usually that means JIRA if it relates to tasks, or the notes repo if it is more of a discussion or if it is not in JIRA yet.

Information should be available when someone needs it, not only when it is given.

Do

:heavy_plus_sign: Consider your forum carefully. :heavy_plus_sign: Respect others work schedules by enabling them to take part of the discussion and/or outcome on their terms rather than your terms. 2 people can quickly hash out a proposal on Slack, then move the organized proposal to a different forum. :heavy_plus_sign: Most Slack discussions should have some form of output: a JIRA issue, a GitHub issue, a document, a PR, etc.

Not

:heavy_minus_sign: Do not make the mistake that a Slack discussion is enough documentation to be considered a decision. :heavy_minus_sign: Do not rely on Slack for getting things done FAST because you can directly interrupt someone with a direct message. It is just as rude as tapping them on the shoulder without regard for what they are doing.

Open channels should be preferred over closed

The benefits of talking out in the open over having closed discussions between select people should be easy to reason about. It allows for insights from sources that may not have been obvious at first glance.

For example, a backend developer might spot a simple fix or their end for problem two frontend developers are discussing how to solve on their end. Or an engineer spots a workaround for a functional problem in the field. Or vice versa.

This cross pollination of ideas and insight cannot happen if all discussions are protected by gatekeepers in private Slack chat rooms, e-mail threads, or face-to-face conversations.

So to allow this to happen, prefer open channels of communication by default. Closed channels are useful, but should not be seen as the default.

Often closed communication channels are used out of a sense of politeness. A dutiful sense that we do not wish to bother the many with a discussion around a topic only the few may be interested to partake in.

First, we are far into an Era of constant notifications and distractions, so everyone has a responsibility to manage their own attention.

You are not responsible for how someone else has configured their notification settings. If they get distracted from one of your notifications, that is a symptom of their own problem, and it is on them to solve, not you.

The benefits of open discussions are too valuable to be lost out of politeness to peoples' attention deficits.

Second, even if only two people are discussing back and forth, there may be twenty more that are following the discussion without chiming in. They can extract value from the discussion and apply it in their work depending on the outcome. At the very least, they are aware of that a subject is or has been discussed, and that it's not a "dead" subject.

Do

:heavy_plus_sign: Create an open channel for to discuss an issue on Slack :heavy_plus_sign: Discuss general issues in open-ended channels, e.g. frontend-talk is always welcome in #frontend. :heavy_plus_sign: Use JIRA comments to discuss a specific issue in JIRA.

Not

:heavy_minus_sign: Direct message 5+ people to discuss a topic. :heavy_minus_sign: Create a private channel to discuss something that is not sensitive.

Social calls

A.K.A watercooler conversations. These do not happen by accident in a remote environment, and even in physical offices they are underappreciated. The little social chit-chats that happen organically though may seem like wasted time to pencil pushers and spreadsheet managers, however they help establish and reinforce the social contracts between the people working together.

It is hard to schedule these things as they may seem less important than doing work, and are usually the first victims to stress, so it is up to leads to ensure that there is enough slack -- and that it is encouraged -- to call up a co-worker and talk to them every now and again over a remote coffee or tea.

Do

:heavy_plus_sign: Use virtual meeting rooms as a chance to chit-chat. :heavy_plus_sign: Take the time to video call your colleagues just to chat about "non-work stuff". :heavy_plus_sign: Get out of your comfort zone. :heavy_plus_sign: Use Slack channels like #random to get to know who you work with. :heavy_plus_sign: Set up a "9 am watercooler" meeting where whoever wants to can join when and if it fits their schedule.

Not

:heavy_minus_sign: Don't force it and don't overdo it.

varl commented 3 years ago

Consolidating to the Operations Handbook.