> allowing the system to optimize for throughput and flow. Sometimes you need lots of small synchronous communications and sometimes you need and fewer large a

> allowing the system to optimize for throughput and flow. Sometimes you need lots of small synchronous communications and sometimes you need and fewer large asynchronous communications. Large asynchronous communications work when everyone already knows what they're doing. They work at a company which has already figured out its business model, built out its necessary expertise, and saturated its market, where everyone's a senior engineer. Like, I don't know, GitHub, where the OP works as a Director of Engineering. Frequent synchronous communications allow for tight coordination in the face of business risk. This is the startup world, the "we're-still-figuring-out-what-we're-doing", "maybe-this-will-work-maybe-not" area of the company stability spectrum. Also this is the area where junior devs are with their careers, so this model is best for them, too. This reminds me of parameters that can be used to tune garbage collection. Collectors can either be tuned for throughput, or availability, but not both. Throughput optimization translates to long stop-the-world GC pauses, where availability translates to more frequent, but smaller pauses so the application is available to take traffic. It also reminds me of a soccer player trying to control a soccer ball. Getting the ball down the field (throughput) is often via a single really hard kick. It's fine if control is reduced, it's throughput that is needed when the ball is too far away from the goal. Conversely, controlling the ball downfield requires lots and lots of tiny touches of the foot. One final comment: asynchronous works great for open source, so why not business? In short: business has a deadline, (hobbyist-run) open source often does not. This being the case, it's fine if the communication takes a little longer. But in a time-critical project, synchronous communication is still our friend.