Should remote teams turn off presence by default?

I’m increasingly convinced remote teams should disable presence indicators and read signals by default. The green dot, “active now” label, and whatever read state a tool exposes encourage availability theater: people watch one another, interrupt asynchronous work, and treat visible activity as collaboration. Being online is not the same as being useful.

I’d rather run a small policy experiment: hide presence for a month, publish response-time agreements for normal and urgent messages, use clear urgency labels, and offer optional office hours for conversations that benefit from real-time contact. That seems more honest than asking everyone to perform constant availability.

The tradeoff is real. New hires may feel more isolated, and teammates may lose a useful cue about whether a question is welcome. Would privacy and deep work improve when presence becomes less observable, or would we lose too much social context?

The green dot is a terrible abstraction for “can respond.” It collapses app-open, keyboard activity, willingness, and context into one bit. I’d keep an explicit incident channel and delete the implication that every other channel is interruptible.

I agree with the experiment, but I’d measure more than message volume. Track response-time misses, onboarding questions, escalation frequency, and a short monthly survey. Otherwise “deep work improved” becomes another impression based on how quiet the channel felt.

Less observability is a privacy improvement even if productivity is unchanged. Presence data creates a record of routines and attention patterns. It is not a security solution by itself, but removing unnecessary metadata is still a sensible default.

I’d worry about customers more than engineers here. If support or sales cannot tell whether the technical person is reachable, they invent their own escalation paths. The answer may be hidden presence internally, with a separately owned on-call schedule.

There’s a danger in treating all visibility as surveillance. A teammate seeing that I’m around can be a lightweight social invitation, not a demand. I’d make presence opt-in or coarse-grained rather than insisting the only humane setting is total opacity.

Response-time agreements need an owner and an exception path. “Usually within one business day” is fine until a deployment is blocked and nobody knows who can break the rule. Office hours help, but they do not replace named duty coverage.

As someone who does better work at odd hours, I’d happily lose the green dot. People see activity at midnight and assume enthusiasm, crisis, or both. Put availability in the calendar if it matters; don’t infer it from a process heartbeat.

The product question is whether the signal solves a real coordination problem or merely satisfies anxiety. Users will recreate the signal with “quick?” messages if the underlying expectations are unclear. Policy has to explain how to ask, not just what to hide.

Read state is especially tricky because it changes sender behavior: now the sender knows not only that a message arrived, but that attention may be judged. I’d default to no sender-facing read signal, while retaining auditability for genuinely operational workflows.

We managed conversations before tiny colored circles became workplace instrumentation. Publish when people can reasonably expect an answer, then let everyone get on with the work. Revolutionary stuff.

In larger organizations, defaults are rarely uniform. Some departments need presence for live operations; others need protected focus. Governance should permit different channel policies instead of forcing one philosophical answer across the whole tenant.

A useful distinction is state versus event. “I am available” is an explicit event I can publish. “The client noticed keyboard input” is an inferred state. The former is consent-based coordination; the latter is mostly accidental telemetry.

I’d keep optional office hours visible on a shared calendar and make everything else asynchronous by default. That gives newer teammates a safe doorway without making every green dot look like an open door.

Run the trial, but define failure before starting: blocked tasks, missed handoffs, and urgent-message latency. If those stay acceptable, the indicators were probably compensating for weak process. If they worsen, restore only the narrow signal that actually helped.