In this blog post I'll describe why remote work != remote work, what's wrong about satellites and isles, why differences in communication bandwidth are worse than overall low bandwidth and what does it have in common with osmosis & water cooler.
No, I'm not going to describe pros & cons of a remote work in depth. This is well covered in many sources & in a way I couldn't have matched in a blog post (or even series). My intention is to address a very simple & well isolated issue: plenty of people, encouraged by some commonly known successful examples of remote-oriented teams & companies preach the idea of remote work as an unconditionally flawless solution to all industry's troubles & deficiencies.
I do not agree with them.
What they do is a narrow-perspective simplification. Remote work may seem a simple concept, but it can be applied in several, drastically different models with very different characteristics (& strongly varying success rate ...), e.g.:
- remote-first: everyone works remotely, there's no "office"
- satellite model: there are hubs (with people working locally) & individuals contributing remotely
- isles model: each team works from a different location, so they are remote in correspondence to other teams (but not to each other within 1 team)
I do agree that the 1st model mentioned above (remote-first) can work tremendously well (if people are carefully chosen & trained - not everyone will fit into this model!) - it has several pros, including:
- it's "democratic" - everyone has the same constraints & limitations, there are no "simplified" communication routes, communication "bandwidth" is limited, but in the same way for everyone involved
- it's global - you're not limited to your local talent
- it's flexible & comfy - you can work wherever you want - in the park, on a trip, in home or co-working space
Advocates of remote work focus on the last two points, somehow not paying that much attention to the first one ... And this is the one that becomes a pain-point in ALL the other remote work models ("satellite" or "isles") ...
Simply speaking, all models with varying communication bandwidth (& inertia) are prone to mapping communication deficiencies straight into architecture of the whole solution. Boundaries of the system (& of knowledge silos) will reflect boundaries of better-communicated groups. Unfortunate outcast units ("satellites") will be marginalised, "islands" will drift apart - you may like it or not but:
- communication is easier, faster, "richer" when there are more sense involved
- even small latencies are very tiresome even short-term
- even an "effort" of coming to the next room (not mentioning different floor) usually results in postponing immediate communication to scheduled meeting (hereby slowing down the interaction in an "anti-Lean" way)
- some knowledge spreads "by osmosis", just because it's being mentioned "in the open" - this effect is hard to achieve in remote scenarios
- humans aren't the best in "filling other ones' shoes" - if we covered something in informal chitchats near the water dispenser we somehow (automatically) assume everyone's aware of that ...
In some cases all these points are not much of an issue as it happens when the system architecture is already prepared for team distribution - e.g. application landscape is modularized into coherent & loosely coupled parts. But if it's not (and it's not always easy), it takes a very high level of maturity & awareness from all the participants (just having the state-of-art remote work tools is NOT enough!) to maintain a healthy, balanced cooperation in non-remote-first distributed work cooperation model.
Remote? Sure, but use with caution.
