Asking a quick question that only takes a few minutes is a nice bonus for you, but for the person you asked it was an interruption that cost them 20 minutes or more of focus. That might be ok if the person you asked has a job that is designed to be interrupt–driven (aka a manager), but if this was another engineer then this wasn’t a net benefit.

But the other side of the coin is that if you do need to ask a question and get an answer, then what is wrong with a text chat mechanism like IRC or Slack or whatever? These tools also work for real collaboration between engineers too.

Asking a question in slack is exactly what I’m referring to. It is async but if we’re on the same schedule then chances are you’ll reply within a couple minutes if not an hour. I massively prefer this style as opposed to walking over to somebody’s desk. However OP is suggesting async also implies you can be working on different schedules with no downside but it’s the differing schedule that is causing the problem.

I agree, we have a sister team which resides half-way around the world (we’re west coast of US, they are in Germany). Over the years, we’ve found the asynchronous communication between us to be a point of friction that has slowed down progress. Waiting for a peer review from them introduces days of lag on what should be faster iterative development cycle.

As a result, we’ve factored this into new architecture plans which further decouple the two teams to operate more independently. We may not have cared as much if we all were operating in approximately the same time zone but asynchronous work will undoubtedly slow development progress on any interface boundaries or when working with dependencies. In a micro-services oriented organization this will almost always be the case. For some areas I can see IC’s being sufficiently isolated in a way that asynchronous could work well but for my organization it would be a nightmare.

Seems like there are two very different modes of development being mentioned here. You seem to be describing a mode where you just need to concentrate and bang out your lines of code for the day. The previous comment seems to be referring to creative, collaborative development. The industry probably needs both, but I’m much more personally interested in the latter, and I’m worried that async/remote is disastrous for that mode in ways that might not be realized for years. To use a crude example, if you’re in a rock band composing songs together, you would never consider that suggesting a change to the riff the bass player is playing would be “an interruption that cost them 20 minutes of focus.”

Your not the bass player you are the record label worrying about if a single exists.

If you interrupt the songwriter every 20 minutes because you have a question around lighting you end up without a song.

Many rock bands create their parts separately or one person creates it all and everyone else learns the material.

Surely it would be managers or executives that would be analogous to the record label executives. We’re talking about ICs on a collaborative team.

> To use a crude example, if you’re in a rock band composing songs together, you would never consider that interrupting the bass player to suggest a slightly different riff would be “an interruption that cost them 20 minutes of focus

Bad analogies are not very persuasive

If you think software development can be a collaborative creative process, it’s really not a terrible analogy.

This analogy sucks because a rock band cannot make songs without actually playing together over and over again. You can however build software in modules or independent parts as long as you have clear specs about what each part should do and proper testing. Thats why you can outsource some software dev but you cannot outsource a rock band.

Terrible analogy.

If you want to pick something that makes more sense to compare, it would be something that is engineering related.

> You can however build software in modules or independent parts as long as you have clear specs about what each part should do and proper testing.

Where do these clear specs come from? That’s the creative process I’m talking about.

I’m a CTO and startup founder. We ship faster and more often than any team I’ve worked on or observed (multiple times per week). I think your assumption are bad.

Without being dismissive of your opinion, being the CTO of a startup doesn’t really say much. I can be the CTO of a startup after I finish an undergrad in computer science or I can be the CTO of a multiple rounds of funding unicorn. So qualifying your opinion with the generic “I’m a CTO and founder” perhaps isn’t a sufficient credence to suggest your experience holds clout.

The reason I mentioned my title is that I don’t think many would consider a CTO an IC. Saying remote and async only works as an IC is wrong.

I agree with you, there are absolutely pros and cons to async work, and sometimes the cons outweigh the pros.

I would point out though that not everyone operates at the scale where everyone can come into the same office every day and meet face to face. I work closely with engineers on both us coasts, in india, and in western europe. whether I work out of my apartment or the nearest office does not really affect the speed or quality of communication with my colleagues.

Yes, but synchronous communication can and should be the exception. In loco working policy basically requires entire teams to live by and commute just so some manager doesn’t have to have the discipline of scheduling meetings in advance and ask things across the desk.

You recognize yourself that async working means more latency. Latency and throughput are often sitting on the opposite ends of a spectrum. With async you can have less interruptions for ICs and increase their throughput.

Remote doesn't mean asynchronous, unless timezones/working hours are very different.