Shouting in the Digital Office

Picture an open-plan office where someone suddenly shouts loud enough for the whole floor to hear. Not because the building is on fire, but because they want a hand with something small. Thirty people lose their train of thought. Flow is broken. Work gets harder.

That is what most chat platforms have become. Every ping is a tap on the shoulder. Every @channel or @everyone is a shout across the room. The intention is usually good. The outcome is not.

Notes and Shoulder Taps

Async is leaving a note for someone to pick up when they are ready. Sync is asking them to stop now. The difference is not small. It is the difference between protecting deep work and breaking it.

Meetings are the ultimate sync. Everyone has to down tools, whether or not they are needed in the room. Many of those meetings exist because someone did not want to write an email. If they had, the point would have been clearer and fewer people would have had to stop.

Chat feels lighter but is often just sync in disguise. Notifications and the pressure to be “seen” as responsive mean people drop what they are doing. Group threads are mini meetings without the discipline of an agenda.

Email is the purest form of async. It forces the sender to think, structure their thoughts, and commit them to writing. That discipline matters. If you cannot explain something in writing, it often means you do not understand it well enough yet. And because email carries no red dot on the taskbar, it lets the recipient reply when they have space, not when they are interrupted.

Sometimes, though, the right answer is neither chat nor email but a phone call. Ten minutes of direct conversation can save a week of emails bouncing back and forth. The point is not to banish sync. It is to use it deliberately, knowing that every interruption is stealing minutes from the deep work developers crave.

A simple spectrum emerges. If it demands immediate action, chat or a quick call is right. If a decision truly needs collective discussion, call a meeting. If it can wait, write it down.

Pulling the Fire Alarm

Nothing breaks flow faster than an @everyone. It is the digital equivalent of pulling the fire alarm. One shout that forces the whole office to stop, whether they needed to hear it or not.

There are moments when it is right to use it: a live incident, or a blocker holding up an entire squad. Outside those cases, it is costly.

The numbers make the point. Thirty engineers. One minute to read the message. Three minutes to get back into flow. Four minutes each, two hours lost in total. And that is the best case.

Now scale it. In a pillar of around 250 engineers, if each one is pulled into just two irrelevant @everyones a day, the cost is more than 30 engineer-hours lost daily. Over a week that is close to an engineer-month. Over a year it is dozens of engineer-years gone to noise.

Across a wider organisation of 2,000 engineers, the numbers multiply again. Even if each one loses only 15 minutes a day to irrelevant @everyones, that is 500 hours gone daily. The equivalent of more than ten full squads doing nothing but recovering from interruption.

But not every distraction is as loud as an @everyone. Some are quieter, tucked into private messages. They feel harmless, even polite, but can drain deep work just as effectively.

Behind Closed Doors

Private messages feel polite. They feel efficient. In reality they shrink the room. The same questions get asked again and again, usually to the same people, who quietly become bottlenecks. Those bottlenecks are often the very engineers whose deep work is already in shortest supply.

Take a new joiner who asks in private, “How do I get this service running locally?” A senior stops, answers, and loses their flow. The next day another new joiner asks the same thing. The cost repeats. If the question had been asked in public, the answer would have been there for all to see.

Public channels change the economics. Questions become shared knowledge. Answers become a record. Others can help. The load spreads. The organisation learns in the open. And crucially, the few people capable of answering the hardest questions get more time back for deep work.

Death by a Thousand Pings

Flow is fragile. It takes time to build and seconds to lose. Developers talk about “deep work” for a reason. At the company I work at, when we ask developers what gets in the way of their best work, lack of deep work always comes back as a top complaint. Too many meetings. Too many pings. Too many @everyones. Not a refusal to collaborate. A plea to be given the chance to do the work they were hired to do.

That is why a quick message is rarely quick. The sender saves five minutes. The receiver loses thirty. Multiply that across a team and the costs pile up silently. Each interruption might feel small, but every one steals a slice of flow. The organisation pays, invisibly, every single day.

The Empty Hello

One of the simplest examples is the empty greeting. A message that says only “Hello” or “How are you?” with no follow-up. It forces an unnecessary loop: the other person replies “Hey, what’s up?” or “I’m fine, can I help you?” before the real question arrives.

Nobody does this with bad intent. It comes from politeness, or habit, or a desire not to be abrupt. But in a working context it slows the exchange for no benefit. It delays the answer and breaks flow twice instead of once.

The fix is simple. Do not ask if you can ask. Just ask. Start with “Hi” if you want, but include the question in the same message. Efficiency is not rudeness. It is respect for the other person’s time and their ability to stay in deep work.

The same applies when asking for technical help. Most requests come with good intent, but without enough detail they create more interruption than progress. A little extra care up front saves a lot of time later.

Bring the Clues with You

Another costly habit is asking someone to debug with no information. A colleague calls in a “tech person” but provides nothing to go on: no error logs, no screenshots, no steps to reproduce. The expert is forced to drag the detail out one question at a time. Both people lose focus.

Again, the intent is not bad. People are often in a hurry or unsure what matters. But arriving empty-handed puts the burden of discovery onto someone else. It breaks their flow and steals more time from the deep work everyone wants to protect.

A better pattern is to bring as much evidence as you can. Show the steps you took, the message you saw, the change that triggered it. Even if you are not sure what is relevant, include it. It is faster to ignore unneeded detail than to guess at missing pieces.

Good bug reports save time. They show respect for the expertise you are asking for. And they keep more of that scarce deep work time where it belongs.

None of this is about adding friction. It is about making intent clearer, so people can respond without guessing. Even small signals help protect deep work.

Say What You Mean

One practical step is to mark intent directly. A simple tag at the start of a message changes how it lands.

• [Async] Sharing early thoughts on the new API contract. Please take a look this week and comment when you have time.
• [Info] Rollout complete for the new payments flow. No action needed.
• [Urgent] Production issue affecting logins. Need help now.

These small signals give others permission. Permission not to break their flow. Permission to wait until they are ready. Permission to focus. Every signal that protects deep work is a productivity win.

Better Than Mindful

Being thoughtful in communication is important. But even better is reducing the need to communicate in the first place. That sounds counter-intuitive, almost inhuman, but the reality is the more context people have, the less they need to ask.

A monorepo helps here. Engineers can see what others are doing, how they are doing it, and build up context without having to interrupt. Observability does the same. When systems expose their own state clearly, engineers can help themselves. Add consistent, predictable tooling across the organisation and the effect compounds. You no longer have pockets of custom scripts or hidden knowledge. You have one way of doing things, discoverable by anyone.

Documentation, shared records, and clear processes sit alongside these. Together they mean fewer interruptions, because the answers are already visible.

The goal is not silence. It is to make communication the exception rather than the constant, so when we do reach out it matters. Protecting deep work sometimes means fewer pings. Sometimes it means none at all.

The Cost of Good Intent

Nobody sends an @everyone, drops a “Hello”, or pings a senior engineer to debug without details in order to waste time. The intent is almost always good. But intent does not cancel out effect. At scale, habits compound. A few lost minutes here and there add up to days. Days add up to weeks.

Ask developers what gets in the way of doing their best work and deep work is always near the top. Meetings, noise, pings, interruptions. None of these are trivial. They are the biggest productivity cost we face.

Habits are choices. As leaders and as colleagues, we decide whether to protect deep work or to chip away at it. If we care about productivity, the way we communicate is one of the biggest levers we have.