The rules by which we communicate have a big impact on our ability to do useful work. Too often we just accept whatever seems standard or easy in the moment. It’s nice to remind ourselves that not everyone accepts this fate.
Many of us have been thrown into remote work haphazardly as global emergencies happened in the past year. That forced change created pretty drastic overnight disruptions across companies and now what was once unthinkable is normal. Many companies are now deciding to become remote entirely or hybrid (part-time) remote, leaving the office, or part of it, behind after being proved it wasn’t an absolute necessity. One problem in this situation is that going remote creates new challenges, which we didn’t figure out before pulling the trigger. To be thriving in a remote setting, you cannot just “port” over the regular office-based communications and processes.
It can and has worked for a time in an extraordinary situation, but I don’t believe it’s sustainable as things go back to normal and we start to move forward. As teams start to grow and people get hired as remote first, some previously working processes and understanding break down, and problems happen. Communication, in particular, is one of the critical places where this is most dangerous and damaging in a remote setting. Good, clear, and precise communication is even more crucial in a remote team because it’s at the core of all work. At the same time, it’s often a lot harder to do remotely if the structure and processes were design and thought out for an office-based environment.
Questions
Absent guidance, people reasonably default to the most convenient form of communication. That convenience is typically with respect to the sender, not the recipient, which allows asymmetrically convenient mediums like chat to flourish — and frustrate.
As I’ve argued in the past, over here, questions are an essential part of knowledge work, but in a remote setting, things get even complicated. One of the main problems in this context is the asymmetry in effort between the sender and receiver. For example, the sender only needs to take two minutes to write down a “small” three-line question and then hit enter. That message then pings the receiver, who’s immediately distracted from their current work. From there, the person needs to look at the question and analyze it to see how to answer or ask for more details if required. In the meantime, the sender has started to work on something else. Then they get pinged back with questions or the answer. It then takes another three minutes to look up the answer then hit enter. This loops for another two times, and before anyone knows it, half an hour has gone by. All of this for a “small” question that “takes” two minutes.
To make matters worst during that exchange, both parties accumulated a lot of context switching residue. It’s been shown that switching context from one task to a very different one, like going from code to answering a question, not only reduces productivity by 20-80%, but it also wholly breaks your focus. On top of that, evolution did not evolve our brain to do quick switching, so while it might “feel” instantaneous, it takes our brain time to switch. That’s the core of the context switching issue, each time, it taxes our brain and takes time to recover more than it takes to switch. That’s also why we’re unable to multitask; what so many people call multitasking is a rapid successive shift of attention between two or more things. But, as you probably know from experience, that just means more energy drained, more overwhelming, and less focus on all of those tasks.
The third problem with this type of workflow is that it creates knowledge silos in the team over time. Questions asked in direct messages or spread across apps can’t be used by people outside the conversation. One of the benefits of asking questions is that it allows sharing knowledge between people, but if you want to share it outside of the corespondents or across time, you need to save it and make it usable. For this to be true, context and information need to be preserved with the question and answer themselves so others can know if it’s applicable for them or how to use it. You cannot do that sort of preservation when the context is spread everywhere, in emails, chats, and people’s minds.
Solution
Solutions that make remote work sustainable–more structure and clarity, less haphazardness–may also help fix these other long-standing problems in knowledge work. Work that is remote-friendly for some may be better work for all.
So what’s the solution to all this? First of all, asking good questions solves a lot of those pain points. As defined in my previous article, a good question is a question with context, clarity, and weight, and it’s not too narrow or open-ended. Doing this makes it straightforward for the other person what they need to do with that question. That, in turn, reduces most of the back and forth and context switching since there’s no exchange between the person asking and answering or, in some cases, maybe once or twice. Even with one or two different exchanges, we’re still a far cry from the 30 minutes back and forth from earlier. That type of question also enables the two other solutions that can push this reduction even further.
Have a central dedicated spot for all questions asking. It can be in time, a specific time of the day or week, or in an app; it simply needs to be agreed upon and used. This central repository also makes it easy to see the current queue for questions and then modulate expectations. That main queue also makes it easy to schedule dedicated time to answer questions instead of them being thrown randomly at you during the day. That way, you can focus solely on giving the best answer possible to the person asking, and it doesn’t impact other work since there’s no interruption. Finally, a repository-like setup is necessary for working asynchronously; the question doesn’t need an answer now because it’s safe in the queue and will get answered in time. That, in turn, reduces the stress and pressure from trying to do everything synchronously in a remote setting.
The final aspect that’s enabled by all of this is the knowledge base. Have a central public known place where people can gather their knowledge on the various topics related to the team. When you have good questions asked and answer, most of the work is already done. Most of the time, you will only need to copy-paste those into a wiki or a tool for that purpose. Doing this also reduces communication and questions positively; instead of defaulting to asking people who are supposed to know, you can look at the knowledge vault first. That way, if something has an answer in there, you got your answer or a place to start; if not, then ask the question and go back with the answer to add to the knowledge base. That process will help spread the knowledge evenly across the team instead of between the person who asked and answered.
Asynchronicity
What we found is that the single biggest barrier to being productive when you work from home is a lack of clear policies and expectations-especially around availability
One of the greatest strengths and advantages of remote work is its flexibility in terms of schedule and workforce. You can work how and where you want, given the company rules and constraints. However, the problem is that those rules and conditions are often either not defined or come from “porting” the existing in-person office ways. Heavy reliance on synchronous communication is often one of the signs and also a problem in those situations. If all communications need to happen in “real-time,” that means you need to be checking all communication channels in real-time too or be left out. That, in turn, creates tons of context switching, which reduces your work, makes overwhelms, creates fear of missing out, and the information (critical or not) won’t spread evenly across the teams. In a situation like this, you either have to accept the overwhelm and constant context switching as a cost or live with the fear of missing information that could have been critical or taking part in a decision and have your voice heard.
In the same vein, when everyone is working synchronously in “real-time,” it becomes hard to hire outside the given timezone. When you expect everyone to be available 9 to 5 in a given timezone, you can’t hire someone who lives, for example, eight hours away, even though they might be a better candidate for the job. If you do it anyway, that person will be left out of their work or living place. To be available 9 to 5, they would need to work night shifts, which might be fine for some, but not everyone, and often not for a long time. In the same way, if a current employee needs to move to a farther away place, they would need to quit or adapt to night shifts. Those situations are a given in an in-person office company, but they don’t have to be in a remote setting; that’s the power of remote and the internet.
Finally, synchronous communications are often used because they’re fast, flexible, and the default. When no other default or guidelines are given, everyone defaults to what they know, in-person communication face to face as we’ve done for millions of years. However, the thing to remember is that default doesn’t mean it’s the best practice or the best way forward. While synchronous in-person communication has its place and can be very useful and powerful, that doesn’t mean it’s the only way, or you should use it all the time for everything. Using the right tool for the right situation at the right time is a lot more potent than defaulting to what we knew worked in the past and trying to fit it in a new context.
Solution
If you don’t define the expectation you become trapped in the default which is “instant”
You can fix most of those problems pretty quickly by changing or setting expectations around team communication. Processes around communication in a remote team should be explicit, written in black and white in a central, visible spot, and everyone should be aware of them. Instead of defaulting to implicit knowledge, which often defaults to synchronous chat communication, things need to be more structured and defined. A simple guide that tells how, what, and when communication happens, the form it takes, and the reasons behind that decision can go a long way to solves many of those issues. Doing this sets the foundation upon which everyone in the team can build their schedule and work methods. That foundation also makes sure everyone is respecting what the company and others require and needs.
Planning around asynchronicity also helps immensely. When things are not real-time, there could be moments where you’re stuck and need to wait some time to get an answer to a question. You could always try to find the solution for yourself in those moments, but there should be some fallback tasks or projects you can work on when another project is on pause due to waiting. Teams shouldn’t do planning in a way where one person is working on one task or project only, and if that task is stuck, everything stops. On the other hand, if it’s impossible to have multiple projects at once or have fallback tasks, the team should put more time upfront to try and address those roadblocks before they become show stoppers. The secret is that, just like communication, projects don’t have to be linear and synchronous.
The final solution for this is to use the right tool for the proper context and message. Not everything requires real-time back and forth and fast iteration; some things are better slowed down when peoples have more time to think things thru. In emergencies and critical situations, chat or video conversations are great tools; they were designed to be fast-paced and allow quick status checks and responses. When you’re losing money every second during an accident, real-time chat is perfect. On the other hand, not everything requires this kind of speed or even makes sense in that type of exchange. Planning, ideas, product design, architecture, tasks, processes, etc., have no benefit being instantaneous with constant back and forth across multiple peoples. Those things are a lot better when put down in writing or audio form, then shared and iterated upon over time as people reflect and think about them. If the planning takes an extra day because someone took more time to think about it, no one will notice or care. People will see a change in the quality of the result. That type of quality takes time; you cannot do it between 2 other conversations in a chat room with three other people who are themselves in the middle of four other discussions.
