Coordination needs awareness of what other operators are doing, not just one's own display

What it is

Team activity awareness is knowing what colleagues are looking at, deciding, and about to do, and how that will change the shared task state. It extends situation awareness — perception, comprehension, projection — from an individual holding their own screen to a team: what an operator should do next often depends on what a colleague is about to do, not only on how the process itself is changing. A private view alone leads to duplicated work on the same object, conflicting commands, or waiting on an action nobody is actually performing.

Why it happens

Coordination runs on predicting what a colleague will do next, not on logging what they already did. Visible selection, control authority, task phase, and brief status updates give the minimum cues needed for that prediction; mirroring every mouse movement and screen change instead adds surveillance load and exposes detail nobody needs. What should surface is the subset of activity that would change what a colleague decides to do next — the filter is not "what happened" but "would this change their next move." This is the same idea as a team maintaining minimal common ground and updating it incrementally rather than broadcasting full state.

There is a flip condition worth stating precisely: once an activity indicator is shown, colleagues treat it as trustworthy. If its update latency is slower than the task's own decision cadence — say, a "handling valve A" indicator that still shows the previous target seconds after the operator has moved on — a colleague will act on stale information with more confidence than they would have acted on no information at all, because absent information invites verification while stale information gets taken at face value. So whether showing activity state helps or hurts hinges on whether its update latency stays under the task's decision cadence; once that condition fails, the same feature turns from an aid into a source of error.

Studying it

Manipulate the presence or absence of an activity feed in a team simulation and compare duplicate actions, conflicting commands, clarification requests, and completion time. A finer-grained check reconstructs perception lag from the logs: align the timestamp of a state change with the timestamp at which the other operator's action first references it, and see how often that lag exceeds the decision window the task actually allows — if it routinely does, the bottleneck is the speed of the awareness feed itself, not operator attentiveness.

Interviews should also test whether members grasp the intent behind an action, not merely that a cursor moved or a light came on — visibility of an action and understanding what it is for are two different things, and the latter is the actual target of activity awareness.

Where it stops holding

• Visible state does not guarantee clear intent: an indicator saying a colleague is working on a valve does not tell you what they plan to do with it, especially once their action departs from routine.
• Automatically inferred busy/idle status depends on polling or heartbeats; once its latency exceeds the task cadence (see the flip condition above), it gets treated as more certain than the fact that it is simply out of date.
• Privacy, access control, and network delay bound how much raw activity can be shared; teams spanning security domains or company boundaries typically cannot mirror raw screens and must exchange an abstracted status summary instead.
• Once a team is large enough that everyone's relevant activity cannot fit within one person's attention budget, broadcasting more does not help — the "would this change a decision" filter must tighten further, or activity awareness becomes its own source of interruption.
• Remote or off-site operators see a different asset context, so a raw mirror of another site's screen carries little meaning without translating it into their local context first.
• Genuinely novel or emergency actions still need verbal confirmation; an activity indicator is not a substitute for a radio call in those cases.

Applying it

• Show actor, target object, task phase, current authority, and last-update time, prioritizing the actions that would change another role's next decision rather than mirroring everything.
• Preview intent before a high-consequence command executes: flag the target and direction on the shared display before the command fires, giving colleagues a window to intervene or object.
• Mark the freshness of activity state explicitly — a timestamp, or a fade to grey past a cutoff — so a stale indicator is never mistaken for a current one.
• How to check: record two linked workstations handling a correlated fault and step through the recording to confirm that, before every command was issued, the other display already showed adequate lead-time intent preview. Cross-check the log to compute how long activity-state updates lagged behind conflicting commands, and prioritize the scenarios with the longest lag for redesign.

Related

• Same group: Y1.09.1 Diffusion of responsibility in operations · Y1.09.3 Separating who acts from who checks reduces single-point omissions · Y1.09.4 Gaps at overlapping responsibilities are the likeliest place for something to go unhandled
• Nearby: Y1.01 Three levels of situation awareness · Y1.08 Information roles of wall and workstation displays
• Search terms: team situation awareness · workspace awareness · common ground