Patterns for Long-Term Remote Work
3/12/2020
Talking about remote work is en vogue right now, and rightfully so. Coronavirus poses a threat to workplaces around the world, some countries announcing full lockdowns.
Combined with the reality that most Americans don't even have enough saved to cover a $1000 emergency, it's untenable to expect people to stop working for an extended period.
For many, the answer will be remote work. More companies will adopt this practice, whether as a result of Coronavirus or not.
Most of the writing that's happening on the subject is tactical in nature: how do you survive a couple of weeks of remote work? This is important because it starts the conversation, but it's not enough.
We need to be thinking what this means in the long run - months, years down the road.
We know something as simple as desk dividers can cause major changes to our productivity and working culture. How much more will remote work affect your company?
That's why I decided to write a series of posts on this subject. In this first part, I'll talk about some often ignored or invisible realities about remote work. In the next few posts, I'll outline some playbooks for remote work that are built to last.
Some invisible realities of remote work
1. Everyone's working environment will be different (and that's okay)
Even the smallest changes to your environment can make a difference. We know, for example, that an open office environment has totally different dynamics (some good, some not so much) from private office spaces.
When you have everyone's environment changing simultaneously, these variables are different for every person. What's more, these variables interact. This has a network-level effect.
To make this more tangible, think back to the last time a coworker joined a remote meeting with a lot of noise in the background, or with a big lag on their computer.
Our individual environments have an effect not only on us, but also on our coworkers.
2. People are not wired for remote work by default; It's a learned skill
It's not that we are incapable of adapting, or that there's some sacred connection that we can't evolve past. But our biological processes haven't kept pace with our technological advancements.
In plain terms, we still have bodies and brains that are optimized for in-person communication and collaboration. When we try to apply our default communication models to our remote environments, we handicap the communication process.
We'll talk more about this in future posts, but the immediate heuristic to reach for: increase bandwidth. Whatever you can do to increase the amount of information that is communicated — and specifically, the number of modalities you use — the better.
Use video, audio, text, emojis, and anything else you can to increase your bandwidth.
3. We don't always know what we need
It might make intuitive sense to get out of bed and roll straight to your computer. After all, this is an easy way to conserve energy, and gives you extra time to get stuff done, right?
We think we know what we need to be productive, but we're often wrong.
We think we need more time, but we might actually do better with more rest.
We think we need to reduce our energy spent, but we might be better off if we spent more energy in different ways.
If remote work is new to you, you might think you know what you need to succeed, but be open to learning, both from others who have done it before you, and from your own experiences.
4. Your working equipment doesn't define your experience, but it can throttle it
This is a very tactical reality to consider. If your machine is making your life difficult, for remote workers the machine you use is essentially your direct conduit to work. For engineers, the machine is essentially your whole workplace.
If you are a manager, ask about the experience your remote workers have on their machines.
(The same goes for dev experience in the codebase, but your equipment is the top-level throttle; no matter how good the codebase experience is, if your machine sucks, that throttles everything else.)
Written by Jonathan Cutrell, Engineering Manager at Guild Education and podcast host at Developer Tea. You can follow him on Twitter at @jcutrell.