2026-05-29: Latency in Communications
Reply early, reply often.
Technology teams and businesses today are distributed. Very rare is it that you, and your whole team, sit in the same room together, and even rarer that a whole department does. This has also never been true in larger organizations, where even if you went to an office, the office might be multiple rooms, floors, or buildings on a campus, and even larger business had multiple offices or campuses.
The primary bottleneck in the development of software (and, indeed, most other aspect of the firm) is the speed at which communication can occur. Because software developers don't work in a bubble, they must communicate with product managers, who also don't work in a bubble, and who must communicate with stakeholders, developers, other product managers, scrum masters, customers, other business areas (e.g. legal) and all of these people are probably communicating together as well.
In the old days, you would have to communicate either in person, or via physical mail (I recommend "High Output Management" by Andy Grove to nearly everyone, and there's a fascinating case about physical mail back in the old days of intel). Phones came along, email came along, and chat came along, and all of these successive improvements occurred because people wanted and needed ways to communicate faster.
Reducing the latency in communications increases the overall throughput of the system, which in the case of software development means the delivery of valuable business product. This means that good communications tools are extremely valuable to organizations. Slack is surely the best option on the market today.
Many organizations, however, struggle with inferior communications solutions. If you are somewhat unlucky, you have been forced to use Teams. Despite Teams being free, it's a major point of friction for everyone involved and makes it significantly harder to communicate than necessary. Even then, at least you have real time communications available, often in a group setting. If you more unlucky, communication is limited to email, and if you are very, very unlucky, most communication occurs one-on-one, either in a phone call or over Zoom.
It might not be immediately obvious why these solutions are "unlucky". They transmit information instantaneously. But the propogation of this information to all the places it needs to reach happens slowly. Very rarely does a communication need to reach a single individual, or a small group of individuals, but it usually needs to reach a very large group of individuals, otherwise the information needs to be repeated. Repeating the information introduces additional latency.
In addition, the repetition subjects it to a degradation in signal (the classic game of telephone problem). This is especially problematic for information discussed verbally. One-on-one calls and group meetings rarely capture enough information in a format that is easily consumed, and so either transcriptions or (far worse) recordings are used to share the information contained within them. Needing to read a full transcription to get (usually) a much more succinct final message or watch an entire video where reading can be done likely hundreds of times faster, slows down (introduces latency) in communications.
Verbal discussions are important, however. Many discussions should happen one-on-one, especially when they are of a sensitive nature, or an uncertain nature, or when you're just trying to build rapport or a relationship. But these are not situations where low latency in communication adds value to the business. Imagine the wide dissemination of highly speculative information to the entire business. Unless it is known to be uncertain, it will be consumed as truth.
The best way to optimize communications for latency is making them 1) written and 2) broadcast relatively widely. Because written information can be consumed asynchronously, and because it can be consumed very quickly, even large amounts of information that are not relevant to participants can be consumed, and any necessary information can be easily captured. Written communications, as well, provide for more later discoverability, such that when someone needs to recall a discussion, it can be searched for and retrieved.
Many organizations are afraid of this particular point, claiming that it creates risks to the business. But risk is only to be understood in context. If your business operates twice as slowly, not communicating quickly has actually created an enormous risk (cost) to the business.
The other important point here is that the tools to make communications efficient and low latency are a necessary but not sufficient condition. If individuals are not themselves engaging in low latency communications by replying quickly, the value basically evaporates. In an in person setting, you can simply turn to the person next to you to ask a question. In a remote setting, sending a message to the channel (never DMs, which will be covered in some other, subsequent post) should receive a prompt reply. In fact, you should go so far as to evaluate promptness of reply for your team members, because unanswered messages cost the business tremendous time and money.
If a person is blocked from completing their task due to lack of response to their inquiry, they will usually need to wait until receiving a reply to continue progress. This is part of what makes teams working across many time zones so slow: the person with answer may be asleep. But it can manifest itself just as easily when someone fails to receive a timely reply because whoever is needed to answer is trapped in meetings, or off for the day.
In businesses where the operations are 24/7/365 (like one that I built) people often need responses to inquiries at all hours of the day and night. Being blocked may result in a minor issue becoming a major client incident, even if the answer to the inquiry was a simple "yes" or "no".
Low latency communications, broadcast widely, and with high fidelity, provide massive benefit businesses. Reply early, reply often.
Previous: 2026-05-25: Suffering Capital