I still find it hard to believe that fully-async working style is more productive in the long run. My experience with it was that the pace of synchronous collaboration and decision making is about 5X faster than async. A group of engineers or a product team standing around a whiteboard in physical space is going to win the day every time IMO.
Perhaps if a company has reached series A and developed a lot of in-person trust and communion, they could successfully start expanding to a remote situation.
I really think it just depends on the work that's getting done, and the nature of the collaboration and decision making that's required.
I think the major assumption is that collaboration is synonymous with productivity.
Candidly, in my experience, the results of collaboration, a lightweight version of "design by committee," have always come back to bite in the long-run. Primarily the issues are: diffusion of responsibility and accountability (i.e., since we all came up with it, then if it goes wrong it was bound to happen and someone else is responsible for fixing it vs. if I came up with it and it goes wrong, it's all on me) and lack of cohesive vision (i.e., the designs and decisions made are incongruous and lack cohesive vision; they're the result of slapping together everyone's, one could argue what would be in isolation, good ideas, but without the necessary steps taken to connect them altogether in a proper fashion).
If we assume the latter, rather than the former, then all that's increased is the speed of sub-optimal processes. One could even go so far as to say it's mostly theater similar to having everyone in the office: the appearance of work is more important than the actual outcomes of the work.
When everyone's together it's very difficult to get a quiet moment to yourself to really think things through and plan things out thoroughly. Instead you default to a more social, collaborative process.
From my own career, I've found I don't need collaboration often. I trust my ability to gather all the information I need, deferring to and asking for the help of experts that know more than I do, while still having the good judgement to synthesize it together into a cohesive and practical plan. In other words the buck stops with me.
Collaboration is absolutely required when the product is undefined. You as an engineer would not be able to do your job correctly unless you could communicate with a designer, a UX-researcher, a product manager, etc (unless of course you are talented enough to fulfill all of those roles by yourself).
Quite typically, communication between all of the above parties is required quite often, as snags are discovered along the way and they constantly require re-working and tweaking the original concept.
The teams I've loved working on make the best use of what people are good at doing.
The people that need to "get together" to share untested ideas so they can make a decision, or share analysis to provide evidence of the validity of a plan will do so without the engineers that do the work. There has to be someone there that has an idea of engineering or architecture, but not the whole team.
In other words, even just a product manager and a CTO or architect can figure out what needs done while not knowing the details of how it will be done, but then they'll pass that information on to the implementation team. Individuals are paid to figure out how and to execute on that.
That's an old outdated way of viewing the world. Everyone sitting around a whiteboard trying to brainstorm an idea is wasteful. Someone comes up with an idea and then everyone takes some credit and you've spent $10,000 and wasted the day but feel productive but deep down you know you didn't need most people in the room.
I disagree. My best ideas come in the presence of others. Something about the collective energy evokes new perspectives I did not have alone.
I think its a waste to get 10 engineers in the room to decide how to build a single module. That would be stupid.
But it likely makes sense to get a designer, an architect, and a product manager in a room. It might also make sense to get an embedded systems engineer, a cloud engineer, and a web engineer in a room to architect something.
I prefer fully async for the simple reason that programming is all text.
A programmer is first and foremost a textsmith. They create increasingly complex textual creations, and develop a deeply refined, idiosyncratic toolkit over the years for doing so. No reason to strip them of their best toolset if you don't have to.
If a job as a developer was 100% coding you might be right, but collaboration, problem solving and brainstorming work far better in person, at least in my experience.
Perhaps if a company has reached series A and developed a lot of in-person trust and communion, they could successfully start expanding to a remote situation.
I really think it just depends on the work that's getting done, and the nature of the collaboration and decision making that's required.