There’s a particular kind of frustration that every engineer knows. You’re deep in flow — three mental stack frames deep into a complicated debug — when a notification blinks into existence:
“Hey”
That’s it. Just: Hey.
You now have a choice. Be nice, context-switch, lose your train of thought and reply… and then wait. Maybe immediately, maybe in a few minutes, maybe tomorrow they will follow up and you’ll know what they want. Or, you could ignore it – be a bad team-mate, not there for your colleagues when they need you.
Either way, you lose. And so do they.
This isn’t a personality problem. It’s an architectural one. Your colleague has just initiated a synchronous handshake in an asynchronous environment — and the entire team will pay the latency penalty for it.
The Protocol Mismatch
Engineers who work with distributed systems understand this intuitively at a technical level. You don’t design a microservice that opens a socket, sends SYN, and then waits indefinitely for SYN-ACK before transmitting its actual payload. If it were TCP/IP, with its three-way handshake synchronous protocol, you’d have safeguards like retries with exponential backoff and timeouts with a clear error message. These do not exist here. The naked “Hello” is not a communication pattern — it’s a bottleneck disguised as a protocol. That’s shooting your service in the foot.
And yet, in the very same companies where we carefully design non-blocking, event-driven, async-first architectures, we routinely communicate like it’s 1995 and we’re on a telephone.
The modern DevOps workplace — distributed teams, remote workers, overlapping time zones, deep-focus work — is inherently asynchronous. But even if everyone is sitting in the same building, the communication we use for work (Slack, Teams, WhatsApp, email) is inherently asynchronous.
Treating those communications as if they were synchronous doesn’t just create friction; it also creates confusion. It taxes the productivity of everyone involved and transfers the cost of your communication style onto the recipient.
Anti-Pattern #1: The Naked Hello
The website nohello.net puts it plainly: sending just “Hello” or “Hey, got a minute?” before stating your actual request is the communication equivalent of a connection that never sends its payload.
The sender feels polite. They’re warming up the conversation, the way you might in person. But in an async medium, what they’ve actually done is force the recipient into a synchronous wait state — held open, unable to fully context-switch away, until the real question arrives.
The fix is simple: send the hello and the question in the same message. Better yet, skip the social preamble entirely and open with context.
Compare:
❌ “Hey, you around?”
✅ “Hi Yoav — quick question about the Terraform state locking config in the staging environment. We’re seeing intermittent failures in acquiring locks during concurrent plan runs. Is this a known issue or should I open a ticket?”
The second message can be acted on immediately, forwarded, triaged, or delegated — even if the sender is offline by the time it’s read. The first message cannot.
Anti-Pattern #2: Asking to Ask
Closely related, and equally corrosive, is the meta-question:
“Does anyone know about Kubernetes ingress controllers?” “Can I ask you something about the pipeline?” “Who should I talk to about the monitoring setup?”
These are questions about questions. They consume a round-trip — attention, response, acknowledgment — before a single useful bit of information is exchanged. dontasktoask.com documents this pattern well: just ask the actual question, to the actual person or channel, with the actual context.
If you don’t know who to ask, that’s fine — say so, and include the question itself so that whoever does know can simply answer it, rather than first volunteering themselves and then waiting for the follow-up.
❌ “Does anyone know about cert-manager?”
✅ “I’m getting a CertificateRequest stuck in Pending after upgrading cert-manager to 1.14 — ClusterIssuer is Ready, DNS is resolving correctly, ACME challenge isn’t being created. Anyone run into this? Using Let’s Encrypt HTTP01.”
The second message is searchable. It can be answered asynchronously. It also helps, in multi-person channels or forums – people don’t have to respond to you to get clarification to know if they can help. They can read your first message and know. Remember: if you want help, make it easier for others to help you, not harder.
The Core Principle: Front-Load Your Payload
Both anti-patterns share a root cause: the sender is optimizing for their own comfort (easing into the conversation) rather than for the recipient’s ability to act.
The corrective principle is to front-load your payload — put the most actionable, most important information first, before the pleasantries, before the background, before the caveats.
This means:
- State what you need in the first sentence.
- Include what you’ve already tried, what you expected, and what actually happened.
- Link to the relevant ticket, PR, log, or document — don’t paraphrase it.
- Specify the urgency honestly. “No rush” and “blocking me” are both useful signals. Leaving it implicit is not.
This isn’t disrespectful. It’s respect for the recipient’s time, their focus, and their autonomy to respond on their own schedule.
This Is a Skill, Not a Personality
The bottom line is: async communication is a learnable skill, not a personality trait.
Teams that communicate well asynchronously didn’t get there because they hired “better” people. They got there because they established shared norms, made those norms explicit, and treated communication patterns the same way they treat code quality — something worth reviewing and improving over time. But even if your team doesn’t do that from the top down, you can try to influence the team from the bottom up. And at the very least, YOU can stop using these antipatterns.
Remember, acting according to the “No Hello” rule isn’t “being unfriendly”. The “don’t ask to ask” norm isn’t about skipping human connection. They’re about recognizing that in a distributed, async-first environment, the medium shapes the message — and a message that can’t be acted on independently isn’t communication. It’s just latency.
So when using async communication systems – like Slack, Teams, WhatsAppand email, to name a few – design your communication the way you’d design your systems: non-blocking, self-describing, and optimized for the environment it actually runs in.
The author works as a DevOps engineer and writes about the human side of technical work.
