So you've started working from home.
There are a multitude of recent articles giving advice on setting up your work environment, making sure you take breaks, and making sure you eat. This isn't one of them.
I've spent the last several years working remotely as a contract software developer, and now as a full-time senior engineer. I thought I'd share some things I've learned about benefits you may not have expected to find in this brave new temporally-syncopated world.
If you're feeling a little out of touch with your colleagues, here's my perspectives on why some asynchronicity can actually be beneficial to your work-from-home life.
Asynchronous teams work when they're at their best
It's common for remote-working folks to feel compelled to be 100% available during work hours. Chat-style work tools mostly encourage this compulsion. If you work with a team that actually states, in writing somewhere, that you must instantly respond to any chat messages, I suggest that the team could stand to re-evaluate some priorities. Remote work offers the immense advantage of working asynchronously.
It makes sense for a team to keep a schedule that allows for a few hours of overlap. This facilitates speedy decision-making and necessary team bonding over voice chat or video calls. A team that fully embraces asynchronous work, however, will mostly tell you to work when you are at your best.
Some people are at their best and most ready to work at 05:00, just after they've finished their morning exercise. Other people are most productive between 20:00 and 01:00 each day. Working when you're at your best can mean a consecutive eight-hour day, or chunks of hours with a siesta or two in-between. Working asynchronously allows each person on your team to perform when they are most ready to perform, and thus most productive, instead of when they are required to conform to a schedule. This is an especially pragmatic strategy in stressful or uncertain times.
Teams transitioning to remote work from 09:00 to 17:00 onsite days sometimes have concerns about asynchronous schedules, usually along the lines of, "How do I know my employees are actually working, and not goofing off?" To that, I humbly suggest: if you've hired a team that you would not trust to care enough about the business to want to get things done without you looking over their shoulder, you may first benefit from rectifying that issue. In other words: hire people that you're willing to trust with the future of your business. Look at what they do, not when they do it. I don't mean to imply that's a simple task; but that's another article.
Asynchronous work necessitates conscientious habits
If you're new to working on your own schedule, one of the first things you'll likely discover is the necessity of taking good notes. Write down thoughts, ideas, and questions when they occur - this won't always be when the person you'd like to share them with is available. With people on different schedules, progress happens out of sync. This can take some getting used to, but it also helps to build useful conscientious habits.
If part of your livelihood depends on having ideas, you may be familiar with the brilliant, world-changing app concept you came up with that one time and carefully recorded in a one-word scribble. You're probably familiar with it because you woke up the next morning, looked at your notepad, and had absolutely no idea what "" was intended to remind you of doing, and then spent the morning metaphorically kicking yourself. If you haven't yet had this experience - trust me, any day now.
Thankfully, these metaphorical bruises can be mitigated by building conscientious habits. Take useful notes by giving them some context. What were you doing when you had this thought? Who do you intend to mention it to? What pain point or question do you think it will address?
Not only will context like this help you to remember what "" means, it will help you further consider the thought itself. Is this idea relevant to the problem? Am I thinking of bringing it to the right person? How should I frame it? How might it be received?
Questions like these encourage you to develop your ideas, examine them, and bring more well-rounded ideas to your work.
You can provide interaction value over interaction volume
Working asynchronously offers the opportunity to increase the quality of your interactions with your team.
A team embracing asynchronous work is not expecting you to respond instantly to their messages. If ten minutes on reflection or Google would enable you to provide a more thoughtful, useful, kind, or relevant response, you can spend the ten minutes. Heck, spend twenty just to be sure. Every question or request is an opportunity to reflect or research, choose the right words, and provide high value to your teammates. It's a chance to eliminate any knee-jerk reactions and foot-in-mouth moments, and present your most conscientious self every time. It's okay to take your time to do it. It's better to take your time to do it, both for yourself and for the collective benefit of your team.
No one remembers that you took seventeen minutes and thirty-four seconds to respond. Everyone will take note of what you responded with.
Since it's not going anywhere, anytime soon
If you have the good fortune of now working from home - many don't, and they deserve our kudos and respect - you can expect that remote work is generally here to stay. Though it may feel a little strange at first, taking advantage of being a little out of sync can offer some unexpected benefits in your career.
Top comments (6)
All good points! How would you go about mitigating situations in which a question or task must be responded to right away? Seems like a lot of roadblocks could occur if people are dependent on one another's speed of response.
I've worked from home extensively myself and find that these situations are rare. If they occur frequently, perhaps there is an underlying issue present.
Nevertheless, when they do occur, you essentially have an typical computer architecture design problem in a human setting, so we can use solutions from that field.
Essentially we are waiting for a communication operation to finish so our computational unit (the programmer in the human setting) is idle. Common solutions are branch prediction and hyperthreading.
For branch prediction in the human model we simply send the question through a slow channel (e.g. email), but rather than waiting for the response, we try to predict the response value. If it turns out we were wrong, we have luckily been using clean git strategies and can easily delete out work. Even with random responses, in the common case of 2-option choices, this is a .5 production modifier, probably less than what we would get when dealing with constant interrupts.
For hyperthreading, we stop working on the current problem, and work on a different one while waiting for an answer. The cost of this strategy is dependent on context-switching cost and granularity of the tasks. It also requires making some modifications to popular teamwork strategies like scrum, but that should be a given when working remotely and asynchronously.
This answer is amazing.
Awesome piece!
Thank you Jukka!
My favorite one: