Making the rules explicit becomes more critical shifting from co-located to remote
“No unwritten rules” is Gitlab’s simpler expression of what the Kanban community would call “make process policies explicit”. Being explicit about “how things are done here” is worthwhile whether co-located or not. It levels the playing field for people who don’t necessarily have exposure to hidden interactions. Remote makes this more critical because it can be more difficult to see how people are behaving.
Distribute decision-making with context and decision rules
Distributing decision-making makes organisations more responsive. This is true whether the organisation is co-located or remote. Centralised decision-making in a remote context is slower and more difficult to monitor. This does not mean that shifting to remote automatically makes effective distributed decision-making the default. To get trustworthy distributed decision-making, all the distributed decision-makers need to be supported with both context and guidance (aka decision rules, “guard rails”, etc.).
Make the product development lifecycle explicit
“Poorly defined roles increase the need for communications and increase the time spent in meetings.”
Donald G. Reinertsen, The Principles of Product Development Flow
When it’s unclear how a product development lifecycle works, especially who does what activities when, there ends up being a lot of energy spent in communications and meetings to address the resulting problems. This cost is higher in a remote context.
Making a product development lifecycle explicit should include workflow, information flow, rhythm or regularly scheduled events, and who should be involved when. Simulations or walkthroughs are useful, as well as something to read or look at.
