11 ms·

Working asynchronously

266 points by marcelo_lebre 7y ago

omarhaneef 7y ago
I feel like there is an insight here about working by yourself, too, that I cannot quite put my finger on. Even if there is no team, you don't want to self-interrupt your own work. Well, we know that hence we invest in internet blockers etc. However, if you are interrupted, it is best if you recover quickly. That is to say, if you can set up your own work so that it is planned in bite size components, and you know exactly where to pick up, you are better off. This is like making an outline, and keeping track of where you are in the outline, except at the level of detail you need (say 5 min increments). Or perhaps you have a short hand of tracking where you are during an interruption. So, if someone says excuse me, you take 12 seconds to quickly note what you were about to do, and if you are about to self interrupt, you do something similar.
- epylar 7y ago
  I've learned to take a lot of notes, make frequent checkpoints (e.g., git commits), and break things down into small pieces, just to deal with interruption--minute to minute (people asking me questions), day to day (fire drills, bugs), and week to week (constantly changing priorities).
  - omarhaneef 7y ago
    Do you use a tool for this?
    - merlincorey 7y ago
      I'm not the person you asked, but I do the same using Emacs' org-mode[0], but there are many tools around such as the Leo Editor[1], or really, any editor with a decent markup language support will do. I store all my org files in git repositories and sync them across devices, allowing me to work on multiple devices and worry less about losing a particular device. [0] https://karl-voit.at/orgmode/ https://karl-voit.at/orgmode/ [1] https://leoeditor.com/ https://leoeditor.com/
      - omarhaneef 7y ago
        Tried this for a while, but unless I have the window open, I don't use it. I use Wunderlist to track the "projects" that I have in my head at any point in time.
    - jsharf 7y ago
      I'm not the same person, but I have a small notebook and pen. Any time I think "Shit, how am I going to remember this if I get interrupted right now?", I quickly scribble down as much as I can and continue working. This is invaluable when I do get interrupted. I do this basically any time I feel like my short-term memory is overwhelmed with facts, and as a result the notebook has effectively become NVRAM for my brain.
      - omarhaneef 7y ago
        This is the closest to what I do myself -- I always have pen and paper on my desk -- but the real issue is that I don't take a note when interrupted because of social pressures (its rude to ignore someone for a few seconds). I don't even do it for myself for self interruptions because I forget to.
        cbm-vic-20 7y ago
        It's rude to interrupt someone without giving them the time to put down whatever it is they're doing. Even if it takes more than a few seconds.
        kelnos 7y ago
        That problem is solved through humility and social graces. "Hold on a sec, I just wanna write down what I was doing so I don't lose my place." If you want to add more, after writing it down, you can follow up with, "sorry to keep you waiting, but when I get interrupted I often forget some useful details about what I was working on, and I want to get that down before it leaves my head". (The "when I get interrupted" is a bit of a cheeky way to point out "you are imposing on me, so the least you can do is allow me this".)
        idealstingray 7y ago
        For me, a quick "hang on" or "sorry, one sec" acknowledges people enough that they don't feel ignored while I make my notes, and is also scripted enough that it doesn't usually knock the thoughts out of my head.
    - epylar 7y ago
      Pen and engineering paper, chronological with bullet points. When the paper is full, I copy any items that are not already checked off or canceled to the next piece of paper (or to a note taking application--still looking for a good one, trying out cherrytree). Any item that gets copied gets a line through it. Canceling an item is putting an X in front of it instead of checking it off. Old pages go into a 3 ring binder. Items don't have to be tasks. They can be ideas or general notes.
    - xsmasher 7y ago
      Not the same person, but I keep a text file divided into two sections - "history" and "today" The "today" section is a bulleted list of the things I think I'm working on today. I add to it through the day as I get shoulder-tapped, or as I realize another important sub-task. As I finish tasks, or at the end of the day, I move them up into the "history" section under the current date. Thursday: A, B, C This is basically all of the "head state" in the infamous cartoon of how you ruin engineers lives by interrupting them. I feel that it allows me to be interrupted without losing import state, and it's also a ready-made "scrum status" of what I did yesterday, and an augment to my memory when someone asks me "did you change X?" for some micro-task that was too small to ticket. I feel this has helped me be a more effective developer, in spite of my decaying memory, than I was when I tried to keep everything in my head. :) Example contents: https://imgur.com/a/VI64Jx6 https://imgur.com/a/VI64Jx6
- hanniabu 7y ago
  I agree with this, but there's a pitfall. Lets say you want to get conversation done at either the start/end of day or both. This is efficient because then you can work interrupted throughout the day. However, when you're not available to answer every ping right away or your "online" status isn't green, then it puts you in a bad light because the managers think you aren't working and/or don't care/aren't a team player.
- OJFord 7y ago
  I find I do much better at coming back to solo/personal stuff if I use an issue tracker anyway, even in the early stages where I'm not so much managing bugs as chunking into bite-size pieces as you describe, so I always try to do that now. It makes me less likely to leave the repo with some staged changes, some unstagrd changes, and no idea what I was doing when I come back to it - but even if that does happen it makes it easier to work out.
Porthos9K 7y ago
I would love to, but my coworkers expect me to be synchronous. They do async, but I'm always supposed to be sync with five nines availability. Looks like it's time to go job-hunting again, but I hate job interviews. Dammit.
- marcelo_lebre 7y ago
  At the end of the day your mental health is worth a lot more than a few interviews ;)
  - GreenJelloShot 7y ago
    Interviewing generally has a significantly negative impact on your mental health... but at least it's temporary.
- zrail 7y ago
  If only job interviews could be async!
  - xxpor 7y ago
    Companies have actually done that, and it's worse: They're the "homework" interviews.
    - sergiotapia 7y ago
      I'm hiring for our team. All of the feedback I've gotten from candidate was that it's fantastic because of the take home interview. No need to sweat and tremble over whiteboard questions. Do you prefer those?
      - xxpor 7y ago
        As a practical matter, I'd probably prefer a take home assignment OVER an in person interview. However, doing both would be a non-starter, that's too much work.
milin 7y ago
Nope
PragmaticPulp 7y ago
I've managed multiple remote, asynchronous teams across multiple countries. When people work in opposite time zones, asynchronous communication is mandatory. When it works, it's a great experience. However, async communication isn't appropriate for every situation, as the article admits. Some times, the most efficient way forward is to schedule a call where all parties can work out the solution in 15 minutes of real-time conversation rather than 3 days of back-and-forth e-mails. If the team is willing to fall back to synchronous comms when necessary, then defaulting to async communication for the other 95% of communication can work. In my experience, the biggest pitfall is when developers try to force 100% asynchronous communication at all costs, no matter how slow and inefficient it becomes for everyone else. All team members must be willing to recognize when synchronous communication is necessary and carve out 15 minutes to an hour a couple times a week for those important, synchronous conversations. Efficient communication is everyone's responsibility, and asynchronous communication is only a win if it doesn't create unnecessary extra work for everyone else.
- lukethomas 7y ago
  Here's a helpful rule of thumb for when to use synchronous communication: Is the conversation ambiguous and is there a high likelihood that you will be misunderstood? An obvious tell for this is when you go back-and-forth over Slack/chat for a few minutes and people still feel like they are on another page. I strongly recommend checking out media richness theory. It presents a helpful way to think about what communication medium is most appropriate for a given scenario. https://en.wikipedia.org/wiki/Media_richness_theory https://en.wikipedia.org/wiki/Media_richness_theory
- hanniabu 7y ago
  This has 100% been my experience as well. All too often it's seen as an all or nothing thing, and it's the parts where discussions should be handled on calls that give it a bad image.
- marcelo_lebre 7y ago
  Agreed. Async communication doesn't belong in sync situations nor vice-versa. Trying to solve everything with one strategy is indeed an anti-pattern.
mlashcorp 7y ago
This sounds great, and in theory should work on a well integrated team of autonomous individuals. I guess as in most things, common sense is the key requirement to make this a reality. Alas, common sense isn't very common...
__s 7y ago
This is essentially the same problem schedulers run into. It's a latency vs throughput trade off. The article is underlining that blocking is bad, & lots of tasks may receive cancellation signals I've worked in low latency environments, but I prefer high throughput. The latter is more conducive to flow state. It also means people aren't relying on my consistency, where some days my brain turns on & some days it doesn't
gatherhunterer 7y ago
This is managerial nonsense. > An even, swift and nimble pipeline produces exactly the right quantity of output for its requirements, and all its stages are balanced in terms of efficiency and speed. Resulting in no waste of time or resources. Aside from containing neither a subject nor a verb, this last sentence is an impossible claim. Anyone who intends to hold the author to the quality of their reasoning would stop reading there. Only people who can say “upward revenue stream dynamics” with a straight face will read on. A single logical sentence has more value than a page full of poorly written false claims and regurgitated platitudes.
- marcelo_lebre 7y ago
  I've been a manager of different teams for a while now and I must admit that every form of management or productivity strategy is nothing but written nonsense in good form - or common sense in fancy terms.
z3ugma 7y ago
The way we've struck a balance at our company is to only allow meetings in the mornings. In the afternoon, everyone can be off Slack, heads-down, and programming or doing other deep work. This halves the number of timeslots that are available to have time stolen from you, but allows us to get the empathy and quick resolution that real-time communication enables.
- bwb 7y ago
  Ya that is a good one, we did something similar with meetings only on M/T/W, and any outside of that had to be directly product-related and engineer only.
- 0xffff2 7y ago
  I guess it's impossible to please everyone, but I would be miserable with this setup. I'm far more productive in the mornings and have managed to keep most of my meetings in the afternoon so they don't interfere with my productive time. Only allowing meetings in the mornings would probably cut my productivity in half or more.
laurex 7y ago
I work on a distributed team on an asynchronous video app (Marco Polo) which makes a lot of conversations easier (sharing bugs, non-urgent conversations, personal connection) but we still Zoom for many meetings. Asynch has virtues even for in person teams but it just isn't optimal for everything, especially discussions leading to decisions that can then be executed upon.
davidw 7y ago
Async communication makes a lot of sense. Their "async planning" bit doesn't mention context switching though, which is an important omission.
konschubert 7y ago
I think it’s armful to the idea of remote work that it’s being equated with async work.
- marcelo_lebre 7y ago
  Async work is but a tool, a methodology, remote is a way of life/work. I advocated async work when working office-based as well, the same principles still apply.
  - konschubert 7y ago
    Agree, it’s also harmful to async that it’s being equated with remote.
benatkin 7y ago
I get the idea that remote.com is trying to trademark the term "remote". F that. The best way to stop that is to prevent remote.com from getting a lot of brand recognition. I don't care how much they want to contribute to the remote worker community - there's no way it will make up for stealing the identity that we have for ourselves.
- xapata 7y ago
  I dunno, it's just clever company naming, like Meetup. I don't think it's stealing an identity. It's also a risk for the company, because the trademark isn't defensible. Google's legal team doesn't like the fact that people use to google as a verb. The extreme form of that would be Microsoft being able to say, "Now you can google better with Bing!"
  - benatkin 7y ago
    Being remote is a lifestyle, where as a meetup is an event, so I think it's worse than Meetup. The brand Meetup is problematic though. It makes it harder to talk about events without accidentally dropping the name of a company. Meetup may have gotten a pass because they've done pretty good, but they are now driving away their customer base (https://www.theverge.com/2019/10/15/20893343/meetup-users-furious-new-rsvp-payment-test https://www.theverge.com/2019/10/15/20893343/meetup-users-fu...). There are also other companies like https://remote.co/ https://remote.co/ that are already using the name remote, but remote.co is respectfully calling themselves remote.co instead of just remote. Having a .com shouldn't be a ticket to appropriate a common word and turn it into a brand.
    - xapata 7y ago
      > Having a .com shouldn't be a ticket to appropriate a common word and turn it into a brand It isn't. You've got to have a great marketing team, too. Remember when UPS tried to make "Brown" synonymous with UPS? Having the domain name isn't a prerequisite for that kind of effort.
- marcelo_lebre 7y ago
komali2 7y ago
Great now how do I convince my team this is a good idea, overcoming super ingrained and traditional working concepts?
- marcelo_lebre 7y ago
  One step at a time. And if that doesn't work, then you find another team ;)
alexandercrohde 7y ago
I want to call BS on the statement "Most meetings can be replaced with documentation." Maybe in an ideal world, but no. Have you tried reading the documentation the average engineer makes? It's like a freshman essay -- lacking in cohesion, vision, context. It's usually completely unstandardized across teams. And 9 times out of 10 the most fundamental questions aren't answered by the documentation e.g. "Why don't we just use existing tool X to solve this problem?" Communication is hard. Engineers use buzzwords. Product uses buzzwords. Companies use buzzwords. Combine all these and you get a soup of overloaded terms e.g. "service," "connect," "access," "resource," "platform" that have a wide range of potential meanings.
- thinkingkong 7y ago
  You might be right but you also dont seem to be making room for the possibility of improving, learning, and making it easier to write those docs. You dont need to have a blank piece of paper and average engineers shouldnt need to guess how to fill in a memo.
- tonyarkles 7y ago
  This is tongue firmly in cheek, but I think it really drives home your "Communication is hard" point. Have you tried reading the meeting agenda and minutes the average engineering manager makes? It's like a freshman essay -- lacking in cohesion, vision, context. It's usually completely unstandardized across teams. And 9 times out of 10 the most fundamental questions aren't answered in the meetings e.g. "Why don't we just use existing tool X to solve this problem?"
  - alexandercrohde 7y ago
    Yeah, but the point is, I can ask all of those questions in the meeting if I'm there in person.
    - wisty 7y ago
      You could also read documentation and ask questions about it. And unlike meetings, everyone won't just forget the answer and have to have the discussion next week.
3bodyProblem 7y ago
There are basically only a few things I agree with in this article, the rest is so shortsighted and heavily tunnel-visioning about some ideal world. The thing I agree with, yes being distracted takes time, focus and productivity. I'm all for being more into more deep work etc. Also the part of people need to be proactive rings true of course. But I fail to see how something that evident really needs a graph. But the issue I take with articles like this is that they think of humans as robots. That walk in, or sit in front of their computer at 9, type for 8 and then go home/stop working. But let's be honest here, If you can keep highly focused for more than 4 hours a day you are a superhuman. I know keeping this in mind doesn't take anything away from the article. Yes we should focus more on Async productivity, but work our work is definitely not single threaded. We are humans, If I hear my teammate 2 desks over signing for the 3rd time I can do 2 things. Ignore it, not getting out of my flow. Or stand up, talk to him/her and see whats up. Maybe it's only a complain about Entity Framework migrations being a b or perhaps just tired, and gets annoying by small things because something happened last night and its time to vent a bit. recently I've started listening to this podcast https://hurryslowly.co/ https://hurryslowly.co/ . Although I do not identify with everything discussed, I do think there is source of truth in a few episodes. It just makes me consider, are we optimizing the right things first? I really wonder, if all this no meetings, no distractions is really the key to making us more effective at our jobs. You can't really measure it, does the hour in a meeting really makes you an hour less productive? Is it more like 15 min? Or did the distraction actually helped instead of bashing your head against the wall for over on hour trying to figure out the solution? I wonder the same about all those gosu vim/emacs users, it sure looks fancy dancing with your fingers doing edits. But where does the real work happen? Is is the amount of lines written or the amount of quality information processed in my mind about the solution I'm looking for? In the end.. - Be human - Try to have clear borders about distractions in your team - Turn all slack notifications off - Don't have meetings that could have been an email. - Don't send emails about stuff that could have been a meeting I'm really curious about working in a distributed team though, sadly I didn't really had the chance yet. I think working remote has it own con's and pro's. I do applause the auther for thinking about this, I think reflecting on how to work better is always a good idea. But It could also easily be a recipe for a burnout.
- 7y ago
crtlaltdel 7y ago
imo think twice add a “bugs” channel to your slack/chat. it invariably gets used as a place to inject panicky statements, ask for status and features...just make sure whatever ticketing system you have is well understood by all stakeholders.
- mjevans 7y ago
  What you need is a form of moderation. An actual group of workers who's job is to collect data, validate a test case is reproducible, or at least that there's telemetry of a problem having happened. In edge cases they could at least collect some data and try to isolate where a problem might exist so that better tests / data collection can occur.
the-dude 7y ago
IIRC, remote.com is founded by a Gitlab alumni, funny to see this as #1 with all the Gitlab outrage going on.
- jobvandervoort 7y ago
  Yep me, together with the author of the post, Marcelo.
m0zg 7y ago
What I've discovered is your team needs to be fairly senior already for this to work at all. I once worked with a team where, shall we say, "talent" was extremely uneven, and it was pretty miserable. It was a very small team, only 3 people, and one of the 3 saw no issues with "synchronizing" threads with wait/sleep loops, paid no heed to coding standards, and just in general turned in shit code others had to waste their time to fix later. Worse yet, he was extremely defensive about any issues we brought up, to the point of not even hearing what we actually say. In his mind, any critique of his code was a personal attack and nothing else. Code reviews were multi-week affairs, leaving him extremely pissed off, and what got checked in was still below par compared to what the other 2 devs were producing. If that person were in the same office, it'd be much easier to browbeat him into compliance and teach/mentor him. But he was halfway across the globe, so we suffered through it for ~6 months and then let him go, further reinforcing his belief he was being personally attacked. Not a good parting of ways.
cpeterso 7y ago
People hate meetings because they're in bad meetings. We spend so much time in meetings without giving them much thought to designing them. I highly recommend the book "The Surprising Science of Meetings: How You Can Lead Your Team to Peak Performance". It covers different types of meetings, including remote meetings and when not to have a meeting. This podcast interview with the author is a good introduction to the book: https://www.gayleallen.net/cm-127-steven-rogelberg-on-making-meetings-great/ https://www.gayleallen.net/cm-127-steven-rogelberg-on-making...
bregma 7y ago
I spend several years managing an all-remote team that ranged from Perth WA to Seattle WA. We worked 90% pure asynchronously and 10% using video chat (or physical get-togethers from time to time). It was highly productive, and because it was all open source development any lack of productivity would have been obvious. I now commute to an office where we all work asynchronously but are expected to appear to work synchronously, as is traditionally expected. It is less enjoyable, frequently subject to context switches (you need to synchronize with the dominant worker) and certainly no more productive -- although that's hard to tell since everything is secret and need-to-know. I would say working asynchronously is better for intellectual workers. Most intellectual work places that claim to working syncronously are either working under an illusion or under a bad manager with a "my synchrony" attitude.
jahbrewski 7y ago
Not directly related to the post, but something I've been thinking about a lot: My life satisfaction and work productivity increased significantly when I stopped working from home and began working 8-5 at an office. There were so many things I took for granted: - Face-to-face interaction with co-workers. - Casual conversations to break up the day. - The rhythm of a commute. - Not struggling to find a spot in a crowded coffee shop. - The productivity boost of working alongside other people who are working. - The consistency and routine of normal working hours. - The ability to pair program, in person. - The ability to be productive with my team even if the internet is slow (or out completely). I worked from home for six years, and I don't think I'd ever go back. I'm not saying remote doesn't have its place, but I've found that I greatly prefer working in-person with other people.
nikisweeting 7y ago
I find using an asynchronous-first chat platform like Zulip (as opposed to Slack) is crucial to my ability to work asynchronously. Without compartmentalization of topics into mutable sub-topics, it becomes a huge mental burden to log onto chat every day.

266 points by marcelo_lebre 7y ago

I feel like there is an insight here about working by yourself, too, that I cannot quite put my finger on. Even if there is no team, you don't want to self-interrupt your own work. Well, we know that hence we invest in internet blockers etc. However, if you are interrupted, it is best if you recover quickly. That is to say, if you can set up your own work so that it is planned in bite size components, and you know exactly where to pick up, you are better off. This is like making an outline, and keeping track of where you are in the outline, except at the level of detail you need (say 5 min increments). Or perhaps you have a short hand of tracking where you are during an interruption. So, if someone says excuse me, you take 12 seconds to quickly note what you were about to do, and if you are about to self interrupt, you do something similar.

epylar 7y ago
I've learned to take a lot of notes, make frequent checkpoints (e.g., git commits), and break things down into small pieces, just to deal with interruption--minute to minute (people asking me questions), day to day (fire drills, bugs), and week to week (constantly changing priorities).
- omarhaneef 7y ago
  Do you use a tool for this?
  - merlincorey 7y ago
    I'm not the person you asked, but I do the same using Emacs' org-mode[0], but there are many tools around such as the Leo Editor[1], or really, any editor with a decent markup language support will do. I store all my org files in git repositories and sync them across devices, allowing me to work on multiple devices and worry less about losing a particular device. [0] https://karl-voit.at/orgmode/ https://karl-voit.at/orgmode/ [1] https://leoeditor.com/ https://leoeditor.com/
    - omarhaneef 7y ago
      Tried this for a while, but unless I have the window open, I don't use it. I use Wunderlist to track the "projects" that I have in my head at any point in time.
  - jsharf 7y ago
    I'm not the same person, but I have a small notebook and pen. Any time I think "Shit, how am I going to remember this if I get interrupted right now?", I quickly scribble down as much as I can and continue working. This is invaluable when I do get interrupted. I do this basically any time I feel like my short-term memory is overwhelmed with facts, and as a result the notebook has effectively become NVRAM for my brain.
    - omarhaneef 7y ago
      This is the closest to what I do myself -- I always have pen and paper on my desk -- but the real issue is that I don't take a note when interrupted because of social pressures (its rude to ignore someone for a few seconds). I don't even do it for myself for self interruptions because I forget to.
      - cbm-vic-20 7y ago
        It's rude to interrupt someone without giving them the time to put down whatever it is they're doing. Even if it takes more than a few seconds.
      - kelnos 7y ago
        That problem is solved through humility and social graces. "Hold on a sec, I just wanna write down what I was doing so I don't lose my place." If you want to add more, after writing it down, you can follow up with, "sorry to keep you waiting, but when I get interrupted I often forget some useful details about what I was working on, and I want to get that down before it leaves my head". (The "when I get interrupted" is a bit of a cheeky way to point out "you are imposing on me, so the least you can do is allow me this".)
      - idealstingray 7y ago
        For me, a quick "hang on" or "sorry, one sec" acknowledges people enough that they don't feel ignored while I make my notes, and is also scripted enough that it doesn't usually knock the thoughts out of my head.
  - epylar 7y ago
    Pen and engineering paper, chronological with bullet points. When the paper is full, I copy any items that are not already checked off or canceled to the next piece of paper (or to a note taking application--still looking for a good one, trying out cherrytree). Any item that gets copied gets a line through it. Canceling an item is putting an X in front of it instead of checking it off. Old pages go into a 3 ring binder. Items don't have to be tasks. They can be ideas or general notes.
  - xsmasher 7y ago
    Not the same person, but I keep a text file divided into two sections - "history" and "today" The "today" section is a bulleted list of the things I think I'm working on today. I add to it through the day as I get shoulder-tapped, or as I realize another important sub-task. As I finish tasks, or at the end of the day, I move them up into the "history" section under the current date. Thursday: A, B, C This is basically all of the "head state" in the infamous cartoon of how you ruin engineers lives by interrupting them. I feel that it allows me to be interrupted without losing import state, and it's also a ready-made "scrum status" of what I did yesterday, and an augment to my memory when someone asks me "did you change X?" for some micro-task that was too small to ticket. I feel this has helped me be a more effective developer, in spite of my decaying memory, than I was when I tried to keep everything in my head. :) Example contents: https://imgur.com/a/VI64Jx6 https://imgur.com/a/VI64Jx6
hanniabu 7y ago
I agree with this, but there's a pitfall. Lets say you want to get conversation done at either the start/end of day or both. This is efficient because then you can work interrupted throughout the day. However, when you're not available to answer every ping right away or your "online" status isn't green, then it puts you in a bad light because the managers think you aren't working and/or don't care/aren't a team player.
OJFord 7y ago
I find I do much better at coming back to solo/personal stuff if I use an issue tracker anyway, even in the early stages where I'm not so much managing bugs as chunking into bite-size pieces as you describe, so I always try to do that now. It makes me less likely to leave the repo with some staged changes, some unstagrd changes, and no idea what I was doing when I come back to it - but even if that does happen it makes it easier to work out.

Porthos9K 7y ago

I would love to, but my coworkers expect me to be synchronous. They do async, but I'm always supposed to be sync with five nines availability. Looks like it's time to go job-hunting again, but I hate job interviews. Dammit.

marcelo_lebre 7y ago
At the end of the day your mental health is worth a lot more than a few interviews ;)
- GreenJelloShot 7y ago
  Interviewing generally has a significantly negative impact on your mental health... but at least it's temporary.
zrail 7y ago
If only job interviews could be async!
- xxpor 7y ago
  Companies have actually done that, and it's worse: They're the "homework" interviews.
  - sergiotapia 7y ago
    I'm hiring for our team. All of the feedback I've gotten from candidate was that it's fantastic because of the take home interview. No need to sweat and tremble over whiteboard questions. Do you prefer those?
    - xxpor 7y ago
      As a practical matter, I'd probably prefer a take home assignment OVER an in person interview. However, doing both would be a non-starter, that's too much work.

milin 7y ago

Nope

PragmaticPulp 7y ago

I've managed multiple remote, asynchronous teams across multiple countries. When people work in opposite time zones, asynchronous communication is mandatory. When it works, it's a great experience. However, async communication isn't appropriate for every situation, as the article admits. Some times, the most efficient way forward is to schedule a call where all parties can work out the solution in 15 minutes of real-time conversation rather than 3 days of back-and-forth e-mails. If the team is willing to fall back to synchronous comms when necessary, then defaulting to async communication for the other 95% of communication can work. In my experience, the biggest pitfall is when developers try to force 100% asynchronous communication at all costs, no matter how slow and inefficient it becomes for everyone else. All team members must be willing to recognize when synchronous communication is necessary and carve out 15 minutes to an hour a couple times a week for those important, synchronous conversations. Efficient communication is everyone's responsibility, and asynchronous communication is only a win if it doesn't create unnecessary extra work for everyone else.

lukethomas 7y ago
Here's a helpful rule of thumb for when to use synchronous communication: Is the conversation ambiguous and is there a high likelihood that you will be misunderstood? An obvious tell for this is when you go back-and-forth over Slack/chat for a few minutes and people still feel like they are on another page. I strongly recommend checking out media richness theory. It presents a helpful way to think about what communication medium is most appropriate for a given scenario. https://en.wikipedia.org/wiki/Media_richness_theory https://en.wikipedia.org/wiki/Media_richness_theory
hanniabu 7y ago
This has 100% been my experience as well. All too often it's seen as an all or nothing thing, and it's the parts where discussions should be handled on calls that give it a bad image.
marcelo_lebre 7y ago
Agreed. Async communication doesn't belong in sync situations nor vice-versa. Trying to solve everything with one strategy is indeed an anti-pattern.

mlashcorp 7y ago

This sounds great, and in theory should work on a well integrated team of autonomous individuals. I guess as in most things, common sense is the key requirement to make this a reality. Alas, common sense isn't very common...

__s 7y ago

This is essentially the same problem schedulers run into. It's a latency vs throughput trade off. The article is underlining that blocking is bad, & lots of tasks may receive cancellation signals I've worked in low latency environments, but I prefer high throughput. The latter is more conducive to flow state. It also means people aren't relying on my consistency, where some days my brain turns on & some days it doesn't

gatherhunterer 7y ago

This is managerial nonsense. > An even, swift and nimble pipeline produces exactly the right quantity of output for its requirements, and all its stages are balanced in terms of efficiency and speed. Resulting in no waste of time or resources. Aside from containing neither a subject nor a verb, this last sentence is an impossible claim. Anyone who intends to hold the author to the quality of their reasoning would stop reading there. Only people who can say “upward revenue stream dynamics” with a straight face will read on. A single logical sentence has more value than a page full of poorly written false claims and regurgitated platitudes.

marcelo_lebre 7y ago
I've been a manager of different teams for a while now and I must admit that every form of management or productivity strategy is nothing but written nonsense in good form - or common sense in fancy terms.

z3ugma 7y ago

The way we've struck a balance at our company is to only allow meetings in the mornings. In the afternoon, everyone can be off Slack, heads-down, and programming or doing other deep work. This halves the number of timeslots that are available to have time stolen from you, but allows us to get the empathy and quick resolution that real-time communication enables.

bwb 7y ago
Ya that is a good one, we did something similar with meetings only on M/T/W, and any outside of that had to be directly product-related and engineer only.
0xffff2 7y ago
I guess it's impossible to please everyone, but I would be miserable with this setup. I'm far more productive in the mornings and have managed to keep most of my meetings in the afternoon so they don't interfere with my productive time. Only allowing meetings in the mornings would probably cut my productivity in half or more.

laurex 7y ago

I work on a distributed team on an asynchronous video app (Marco Polo) which makes a lot of conversations easier (sharing bugs, non-urgent conversations, personal connection) but we still Zoom for many meetings. Asynch has virtues even for in person teams but it just isn't optimal for everything, especially discussions leading to decisions that can then be executed upon.

davidw 7y ago

Async communication makes a lot of sense. Their "async planning" bit doesn't mention context switching though, which is an important omission.

konschubert 7y ago

I think it’s armful to the idea of remote work that it’s being equated with async work.

marcelo_lebre 7y ago
Async work is but a tool, a methodology, remote is a way of life/work. I advocated async work when working office-based as well, the same principles still apply.
- konschubert 7y ago
  Agree, it’s also harmful to async that it’s being equated with remote.

benatkin 7y ago

I get the idea that remote.com is trying to trademark the term "remote". F that. The best way to stop that is to prevent remote.com from getting a lot of brand recognition. I don't care how much they want to contribute to the remote worker community - there's no way it will make up for stealing the identity that we have for ourselves.

xapata 7y ago
I dunno, it's just clever company naming, like Meetup. I don't think it's stealing an identity. It's also a risk for the company, because the trademark isn't defensible. Google's legal team doesn't like the fact that people use to google as a verb. The extreme form of that would be Microsoft being able to say, "Now you can google better with Bing!"
- benatkin 7y ago
  Being remote is a lifestyle, where as a meetup is an event, so I think it's worse than Meetup. The brand Meetup is problematic though. It makes it harder to talk about events without accidentally dropping the name of a company. Meetup may have gotten a pass because they've done pretty good, but they are now driving away their customer base (https://www.theverge.com/2019/10/15/20893343/meetup-users-furious-new-rsvp-payment-test https://www.theverge.com/2019/10/15/20893343/meetup-users-fu...). There are also other companies like https://remote.co/ https://remote.co/ that are already using the name remote, but remote.co is respectfully calling themselves remote.co instead of just remote. Having a .com shouldn't be a ticket to appropriate a common word and turn it into a brand.
  - xapata 7y ago
    > Having a .com shouldn't be a ticket to appropriate a common word and turn it into a brand It isn't. You've got to have a great marketing team, too. Remember when UPS tried to make "Brown" synonymous with UPS? Having the domain name isn't a prerequisite for that kind of effort.
marcelo_lebre 7y ago

komali2 7y ago

Great now how do I convince my team this is a good idea, overcoming super ingrained and traditional working concepts?

marcelo_lebre 7y ago
One step at a time. And if that doesn't work, then you find another team ;)

alexandercrohde 7y ago

I want to call BS on the statement "Most meetings can be replaced with documentation." Maybe in an ideal world, but no. Have you tried reading the documentation the average engineer makes? It's like a freshman essay -- lacking in cohesion, vision, context. It's usually completely unstandardized across teams. And 9 times out of 10 the most fundamental questions aren't answered by the documentation e.g. "Why don't we just use existing tool X to solve this problem?" Communication is hard. Engineers use buzzwords. Product uses buzzwords. Companies use buzzwords. Combine all these and you get a soup of overloaded terms e.g. "service," "connect," "access," "resource," "platform" that have a wide range of potential meanings.

thinkingkong 7y ago
You might be right but you also dont seem to be making room for the possibility of improving, learning, and making it easier to write those docs. You dont need to have a blank piece of paper and average engineers shouldnt need to guess how to fill in a memo.
tonyarkles 7y ago
This is tongue firmly in cheek, but I think it really drives home your "Communication is hard" point. Have you tried reading the meeting agenda and minutes the average engineering manager makes? It's like a freshman essay -- lacking in cohesion, vision, context. It's usually completely unstandardized across teams. And 9 times out of 10 the most fundamental questions aren't answered in the meetings e.g. "Why don't we just use existing tool X to solve this problem?"
- alexandercrohde 7y ago
  Yeah, but the point is, I can ask all of those questions in the meeting if I'm there in person.
  - wisty 7y ago
    You could also read documentation and ask questions about it. And unlike meetings, everyone won't just forget the answer and have to have the discussion next week.

3bodyProblem 7y ago

There are basically only a few things I agree with in this article, the rest is so shortsighted and heavily tunnel-visioning about some ideal world. The thing I agree with, yes being distracted takes time, focus and productivity. I'm all for being more into more deep work etc. Also the part of people need to be proactive rings true of course. But I fail to see how something that evident really needs a graph. But the issue I take with articles like this is that they think of humans as robots. That walk in, or sit in front of their computer at 9, type for 8 and then go home/stop working. But let's be honest here, If you can keep highly focused for more than 4 hours a day you are a superhuman. I know keeping this in mind doesn't take anything away from the article. Yes we should focus more on Async productivity, but work our work is definitely not single threaded. We are humans, If I hear my teammate 2 desks over signing for the 3rd time I can do 2 things. Ignore it, not getting out of my flow. Or stand up, talk to him/her and see whats up. Maybe it's only a complain about Entity Framework migrations being a b or perhaps just tired, and gets annoying by small things because something happened last night and its time to vent a bit. recently I've started listening to this podcast https://hurryslowly.co/ https://hurryslowly.co/ . Although I do not identify with everything discussed, I do think there is source of truth in a few episodes. It just makes me consider, are we optimizing the right things first? I really wonder, if all this no meetings, no distractions is really the key to making us more effective at our jobs. You can't really measure it, does the hour in a meeting really makes you an hour less productive? Is it more like 15 min? Or did the distraction actually helped instead of bashing your head against the wall for over on hour trying to figure out the solution? I wonder the same about all those gosu vim/emacs users, it sure looks fancy dancing with your fingers doing edits. But where does the real work happen? Is is the amount of lines written or the amount of quality information processed in my mind about the solution I'm looking for? In the end.. - Be human - Try to have clear borders about distractions in your team - Turn all slack notifications off - Don't have meetings that could have been an email. - Don't send emails about stuff that could have been a meeting I'm really curious about working in a distributed team though, sadly I didn't really had the chance yet. I think working remote has it own con's and pro's. I do applause the auther for thinking about this, I think reflecting on how to work better is always a good idea. But It could also easily be a recipe for a burnout.

7y ago

crtlaltdel 7y ago

imo think twice add a “bugs” channel to your slack/chat. it invariably gets used as a place to inject panicky statements, ask for status and features...just make sure whatever ticketing system you have is well understood by all stakeholders.

mjevans 7y ago
What you need is a form of moderation. An actual group of workers who's job is to collect data, validate a test case is reproducible, or at least that there's telemetry of a problem having happened. In edge cases they could at least collect some data and try to isolate where a problem might exist so that better tests / data collection can occur.

the-dude 7y ago

IIRC, remote.com is founded by a Gitlab alumni, funny to see this as #1 with all the Gitlab outrage going on.

jobvandervoort 7y ago
Yep me, together with the author of the post, Marcelo.

m0zg 7y ago

What I've discovered is your team needs to be fairly senior already for this to work at all. I once worked with a team where, shall we say, "talent" was extremely uneven, and it was pretty miserable. It was a very small team, only 3 people, and one of the 3 saw no issues with "synchronizing" threads with wait/sleep loops, paid no heed to coding standards, and just in general turned in shit code others had to waste their time to fix later. Worse yet, he was extremely defensive about any issues we brought up, to the point of not even hearing what we actually say. In his mind, any critique of his code was a personal attack and nothing else. Code reviews were multi-week affairs, leaving him extremely pissed off, and what got checked in was still below par compared to what the other 2 devs were producing. If that person were in the same office, it'd be much easier to browbeat him into compliance and teach/mentor him. But he was halfway across the globe, so we suffered through it for ~6 months and then let him go, further reinforcing his belief he was being personally attacked. Not a good parting of ways.

cpeterso 7y ago

People hate meetings because they're in bad meetings. We spend so much time in meetings without giving them much thought to designing them. I highly recommend the book "The Surprising Science of Meetings: How You Can Lead Your Team to Peak Performance". It covers different types of meetings, including remote meetings and when not to have a meeting. This podcast interview with the author is a good introduction to the book: https://www.gayleallen.net/cm-127-steven-rogelberg-on-making-meetings-great/ https://www.gayleallen.net/cm-127-steven-rogelberg-on-making...

bregma 7y ago

I spend several years managing an all-remote team that ranged from Perth WA to Seattle WA. We worked 90% pure asynchronously and 10% using video chat (or physical get-togethers from time to time). It was highly productive, and because it was all open source development any lack of productivity would have been obvious. I now commute to an office where we all work asynchronously but are expected to appear to work synchronously, as is traditionally expected. It is less enjoyable, frequently subject to context switches (you need to synchronize with the dominant worker) and certainly no more productive -- although that's hard to tell since everything is secret and need-to-know. I would say working asynchronously is better for intellectual workers. Most intellectual work places that claim to working syncronously are either working under an illusion or under a bad manager with a "my synchrony" attitude.

jahbrewski 7y ago

Not directly related to the post, but something I've been thinking about a lot: My life satisfaction and work productivity increased significantly when I stopped working from home and began working 8-5 at an office. There were so many things I took for granted: - Face-to-face interaction with co-workers. - Casual conversations to break up the day. - The rhythm of a commute. - Not struggling to find a spot in a crowded coffee shop. - The productivity boost of working alongside other people who are working. - The consistency and routine of normal working hours. - The ability to pair program, in person. - The ability to be productive with my team even if the internet is slow (or out completely). I worked from home for six years, and I don't think I'd ever go back. I'm not saying remote doesn't have its place, but I've found that I greatly prefer working in-person with other people.

nikisweeting 7y ago

I find using an asynchronous-first chat platform like Zulip (as opposed to Slack) is crucial to my ability to work asynchronously. Without compartmentalization of topics into mutable sub-topics, it becomes a huge mental burden to log onto chat every day.