Without any lengthy introductions - COVID-19 has sent plenty of people to work remotely. Companies that would never (or at least unlikely) consider such a scenario, have jumped (somehow reluctantly) straight onto remoteness bandwagon to secure their daily operations in the times of global pandemic.
I'm probably a bit more optimistic than Andrzej ...
so I believe that two groups will emerge after the dust has settled:
- companies that were not prepared for working remote, tried it and failed miserably (and as a result are now prejudiced against it & won't try it in foreseeable future)
- companies who were unconvinced, but tried it and found some pros that look encouraging enough to experiment with in in future (probably in a bit bolder way)
It's your chance then, a make-or-break moment - you won't have any better chance. If you're in a company that hasn't embraced remoteness yet, what can you do to help the experiment to succeed (and last)?
Well, I have some bad news. First of all, the most critical factors when introducing the remote work model are all about attitude, mindset & communication - vital elements of the organisation culture that are damn hard to (re-)shape "on demand". Tooling is also important (even necessary), but very far from being sufficient. If your organisation wasn't ready for remoteness "yesterday", making such a big mental shift overnight is very hard (but not impossible). Whether you have any chance or not depends on:
- the number of effective "change agents" - ones that are eager to serve as heralds of the revolution "in the trenches"
- overall willingness to try & openness for change (not an easy one)
OK, so what is the remote work REALLY about? How can we compensate the limited communication bandwidth & reduced number of direct social interactions? Here comes the shortest list that comes to my mind:
- Ball should never get dropped - OWNERSHIP - use RACI collaboration model, make sure each problem/risk has an owner (always!), sync frequently, learn to escalate
- Information should be radiated - TRANSPARENCY - be open with whoever's interested (pub-sub), pro-actively share information (using agreed media), raise risks/issues early (adjust form, volume & audience to the situation)
- Get into everyone else'es shoes - COMMUNICATION - don't wait to be asked, learn your stakeholders' views: what questions they want answered, what are their goals/metrics/concerns; AAAAND make sure that the mental & technical barriers to contact others are as low as possible
- Always look for frequent feedback - DIRECTION - continuous feedback is the only way to avoid waste & re-work, so learn to split work using business-oriented outlines & verify the hypotheses frequently - don't be afraid of (factual and substantive) criticism
- Fight indifference & ambiguity - CLARITY - don't leave questions w/o answers, problems w/o owners, team members w/o support (they need), decisions w/o rationale (behind them); drop (explicitly) topics of low/negligible importance and stick to rule of adherence ("I disagree & commit") when it comes to decisions made
- Be open, straightforward & honest - CANDOR - there are very few things as detrimental to remote collaboration as keeping several, parallel "versions of truth", asymmetrical knowledge distribution and internal politicking (which makes people feel insecure, always unsure whether they've got a full & real picture)
And what about tools?
- always aim for minimum friction - so they are easy to use & their complexity doesn't add up to the challenge of the change itself
- make sure they are as democratised as possible: avoid super-tight access policies (many organisations limits access to one team's stuff so other teams can't see it - for no apparent reason) and make sure that everyone willing can collaborate (one "creator" license per team wont' work ...)
- integration is a time (& gold) saviour - avoid any scenarios where you have to (re-)sync/match data manually across tools - it's tedious, error-prone & it creates substitute problems you don't want to waste your time on
- these days conciseness is the new black - that's why the visual tools that can help with proper knowledge organisation do make such a difference: maximum knowledge within minimum content (& effort) that is also the best way to make sure people's thinking is properly aligned (something the traditional, written free-form is very poor for)
My advice is to go for a minimum toolset:
- text-based, topic-oriented async collaboration tool with chat, DMs, persistent history, labeling and seamless voice/video integration (e.g. Slack, Flock)
- virtual board to visualise work, maintain backlog, grab work, etc. (whatever works for you - starting with something as simple as Trello, ending with behemoths like Jira)
- voice/video communication tool - the more versatile, the better - permanent audio/tele-presence is a nice "reality hack" that worked nicely for many teams (e.g. Zoom)
- flexible knowledge base - where people can draft, shape & fine-tune collective knowledge altogether, in a friction-less, easy way (e.g. any wiki, Notion, Airtable, Fibery, Infinity, Coda, Nuclino, ...)
- direct collaboration tools - depending on activities team members perform: e.g. LiveShare/Teletype for pair programming, Miro/Sketchboard for design or brainstorming sessions, etc.
Daily stand-up support tools, retrospective governance tools, internal "vibe" tools, virtual watercoolers, digital kudo boxes? Yes, they do exist but IMHO they are just shiny distractions - the same goals can be achieved with much simpler means.
And what about you? Do you have any recommended practices/tools that have made a substantial difference when working remotely?
Latency VS Throughput
Yesterday, just after writing the draft of the post above, I've read a great post on a slightly different aspect of remote work by Mark Seemann. I strongly recommend you to get familiar with it, but the idea I've found most interesting is the one in the title - you can optimize the work (of a team, not only a remote one) either for latency or throughput, not both.
What many remote work evangelists advocate is the "remote async" way, which goes for maximizing throughput. This works perfectly in some scenarios (e.g. big OSS projects mentioned by Mark), but the modern, high velocity software workshops (e.g. lean startups) frequently adhere to lean principles which favor minimizing latency (that's my way of thinking as well, tbh) - this means a very different collaboration model (especially when it comes to remote) expectations.
Why do I mentioned that (& find it important)? You should make a very conscious decision based on what kind of model does your organization (want/need to) implement. Remote may not be for you or at least not all kinds of remote.