The Communication Asymmetry
This is the first post in a miniseries: The best pieces of advice I have received. I’ll add to it as more advice that has shaped how I work comes to mind.
In a meeting in Ghent, sometime in 2019, our CTO Ben Schrauwen gave us a piece of advice that I’ve carried into every job since:
When you’re looking at communication problems in an organisation, there are only two kinds: too little, or too much. Too much is easy to fix. Too little is much harder.
The advice sounds trivial, but I reach for it often, and it has shaped how I operate in every team since.
Why the asymmetry matters
The asymmetry is the non-obvious part. Both failure modes feel symmetric in the abstract: you have miscalibrated in one direction or the other, so turn the dial. In practice they behave differently.
Too much communication produces visible signals. People complain. Meetings feel pointless. You start muting Slack threads. Someone asks, “do we really need this stand-up?” When you over-communicate, people push back, and you dial it down.
Too little communication produces absence, and absence is invisible. No one walks into your office to complain about the conversation that did not happen, the context they did not get, the decision they did not know someone was making. The first signal arrives as a downstream failure: duplicated work, a missed dependency, a surprised stakeholder, a project that drifts for a quarter before anyone notices. By the time you see the problem, you are paying for it.
That is the asymmetry. Over-communication is noisy and self-correcting. Under-communication is silent and compounds.
Oqton, briefly
Some context. Oqton was a software startup bridging design to manufacturing, with strength in metal additive manufacturing for dental applications. We had a small Copenhagen office in Lyngby, the main European office in Ghent, and people across three continents. 3D Systems acquired the company in 2020, and the dental workflow piece lives on at oqcam.com. The team was excellent: leading experts in topology optimisation, sharp engineers from the big tech companies, and an ambitious technical vision under Samir Hanna and Ben.
(I will come back to a separate piece of advice from my Oqton interview about engineering culture and code review in a later post.)
Oqton’s leadership treated communication as infrastructure. They built systems for it. Some of those existed before I joined:
- A stand-up bot in Slack where people posted what they were working on. The posts produced unplanned conversations between people working on adjacent problems. Half the value lived in the posts; the other half in the threads underneath.
- A git repository of personal stories. New hires wrote one when they joined, a rite of passage. You learned a colleague’s history and interests in ways email and a one-off intro call cannot match.
- A monthly all-hands that celebrated the work. Obvious advice that most companies skip.
None of this was accidental. With three continents, you cannot rely on hallway conversations and proximity to do the work for you. You build the channels.
How I’ve used it since
I started applying the advice right away. The biggest payoff came from a choice I made when I joined deCODE Genetics: I joined both the CNS group and the statistics department. It was more work upfront, but the network effects were large. I got to know twice as many people in the same window of time, and I started seeing connections between the two groups’ work that helped us put the right people on shared projects. During my PhD I had supervisors from two different departments for the same reason. It gave me broader oversight faster and a wider pool of advice to draw from.
Team of Teams makes the same argument. Ben pointed me to the book; I recommend it. It describes how the US military restructured its intelligence operation. They embedded analysts who used to sit apart from operational teams, and the embedded analysts cut the time from intelligence to action. The setting is extreme, special operations under time pressure, but the claim generalises. Most organisations would benefit from faster execution, and the bottleneck is how fast information moves between the people who have it and the people who need it.
The principle scales down. I am building an iOS app in my spare time, and even there, on a project of one, I rely on TestFlight to talk with a small group of beta testers rather than batching feedback into rare formal rounds. More signal, more often. The cost of an extra build sits below the cost of building the wrong thing for two weeks.
The heuristic
This is a coarse tool. Real communication problems have many dimensions: channel, audience, timing, register, what speakers say versus what listeners hear. Ben’s framing skips that nuance.
It does something more useful. It hands you a question you can ask in any situation and act on: Are we under- or over-communicating right now?
If the answer is “over,” you will know. People tell you, the signals show up across channels, and you can dial it back. If the answer is “under,” you will not know unless you go looking. If you are uncertain, err toward more: more stand-ups, more cross-team time, more written context, more shared channels. The cost of over-shooting is annoyance. The cost of under-shooting is invisible and large.
That asymmetry is the whole lesson.