9 Ways Async Teams Accidentally Become Surveillance Cultures

Async work was supposed to free engineers from the performative attendance of synchronous offices. In practice, many async teams have drifted toward a different and more insidious failure mode: surveillance. The same tools that enable async coordination — activity tracking, status monitoring, productivity dashboards — make it tempting to substitute observation for trust. The result is teams where engineers work in a fog of being watched, never quite sure what's being measured, and the autonomy that async was supposed to deliver evaporates.

Surveillance cultures rarely announce themselves. They accumulate through small choices that each seem reasonable in isolation. Here are nine of the most common patterns. If your team is doing several of these, you've built a surveillance culture without intending to — and your async productivity gains are quietly being eaten by the anxiety they generate.

1. Slack green-dot monitoring

Managers (and increasingly, peers) check who's online and when, treating the Slack presence indicator as a proxy for productivity. Engineers learn to keep Slack open during their entire workday whether or not they're actually working, and to wiggle the mouse periodically to prevent the dot from going gray. The signal is now contaminated — the green dot indicates "performing presence" rather than "doing work." The team has accidentally taught itself to fake the metric it's being measured on.

2. Calendar transparency that becomes calendar policing

The team adopts default-public calendars to make scheduling easier. Within months, the calendar becomes a surveillance instrument: managers note who's not in enough meetings, peers infer who's slacking based on visible free time, engineers add fake "focus time" blocks to defend against the implicit judgment. The calendar was supposed to be a coordination tool; it's become a productivity court where everyone is constantly being assessed on their schedule.

3. Activity dashboards that nobody asked for

Engineering metrics tools surface dashboards showing commit counts, PR throughput, review latency, and code churn per engineer. The intent is "visibility into team health." The effect is a leaderboard. Engineers respond by optimizing for the visible metrics: smaller PRs, more commits, faster but shallower reviews. The dashboard succeeds at producing the appearance of productivity and fails at producing actual productivity.

4. Asking engineers to explain low-activity days

An engineer has a day with no commits and few Slack messages. A manager pings them: "Just checking in — quiet day yesterday?" The intent is concern. The message received is "I'm watching your activity." After two of these interactions, the engineer learns to manufacture visible activity — small commits, contrived Slack contributions — on days when they're doing deep work that doesn't generate signal. The manager has accidentally trained the team to prioritize observability of work over the work itself.

5. Treating shift-end wraps as performance reports

The team adopts shift-end records as a context infrastructure habit. Then a manager starts using them as a performance signal: "I noticed your records have been thin this week." The records were supposed to be a tool for transferring context to teammates. The moment they become an evaluation artifact, engineers start writing them for the manager rather than the next shift — embellishing accomplishments, padding the "completed" section, hiding struggles. The context infrastructure has been compromised.

6. Mandatory work-hour windows

"Async" gets defined as "you can work async, as long as you're online during these specific hours." The implicit message is that the team doesn't trust engineers to manage their own schedules. The effect is the same as a synchronous office without the in-person benefits: engineers perform attendance during the mandatory hours and do their real work outside them, where they're free from observation. The team has the worst of both models.

7. Required real-time response in DMs

The norm establishes that DMs from managers (or senior engineers) require response within a defined window — usually fifteen to thirty minutes. Engineers can't take a long lunch, can't focus deeply for an hour, can't take a walk to think — without the anxiety that a DM is accumulating. The team has reinvented the open-office tap-on-shoulder dynamic in a worse form, because now the interruption is asynchronous and untimed.

8. Productivity tracking software

The most explicit form: tools that take screenshots, log keystrokes, or track active window time. Some companies adopt these openly; some adopt them quietly. Both produce the same effect — engineers operate in a state of constant low-grade anxiety, knowing that their activity is being recorded. The relationship has been redefined as adversarial. Senior engineers leave; the engineers who stay are the ones willing to tolerate being watched, which is a different talent profile than the one you started with.

9. Asking for status updates that the records already answer

The team has shift-end records, decision logs, and Linear boards. Despite all of this, managers and stakeholders ping engineers asking for status: "What's the latest on X?" The records already answer the question. The ping signals that the asker doesn't trust the records or hasn't read them — either of which undermines the entire async system. Engineers learn that the records are theater; the real status reporting still happens in DMs to whoever is asking.

The pattern underneath all nine

Each of these patterns substitutes observation for trust. The team has tools to monitor; it uses them instead of building the trust that would make monitoring unnecessary. The fix is not to eliminate the tools — visibility is genuinely useful — but to clarify what they're for. Shift-end records are for the next shift, not the manager. Activity dashboards are for surfacing patterns in retrospectives, not evaluating individuals. Calendars are for scheduling, not assessing.

The clearest test: would you be comfortable showing every engineer exactly what their manager sees about their activity? If yes, the visibility is healthy. If no, you've built surveillance, and you're paying for it in trust and retention even if the dashboards say things look fine.

Frequently asked questions

How do you give managers visibility without creating surveillance?

The principle is symmetric visibility: managers see what teammates see, no more. Shift-end records are visible to the whole team. Activity dashboards are visible to the engineer themselves, not just managers. Decision logs are open. The asymmetric visibility — where managers see things engineers don't — is the pattern that creates surveillance dynamics. Equalize the access and the same data becomes coordination rather than monitoring.

What's the right response when leadership asks for productivity dashboards?

Offer outcome metrics instead of activity metrics. Velocity of shipped work, incident rate, customer-reported issues, cycle time — these measure what matters and don't reduce to individual surveillance. If leadership insists on activity metrics for individuals, that's a culture signal worth raising explicitly. The downstream effects on hiring, retention, and engineer behavior are predictable and worth flagging before the dashboards exist rather than after.

How do you reverse a surveillance culture once it's taken hold?

Start by removing the most visible surveillance instruments — screen tracking, calendar policing, mandatory online hours — and explicitly explaining why. Replace them with declared-state instruments (shift-end records, decision logs) that the team controls. Make the leadership pledge to read what's declared rather than watching what's tracked. The trust rebuilds over months, not weeks, and the engineers who were burned by the prior dynamic will be slow to believe the change is real. That's earned, not unfair.