In this paper the authors talk about the primary coordination tool that mission control for the Space Shuttle missions used, “voice loops”. This is a set up where you would wear a headset that you can talk into and listen on. You can speak on only one channel at a time, but you are able to listen to multiple channels at a time. You can change how much attention you want to pay to a channel that you’re listening to by lowering its volume.
Mission control is organized in a hierarchy headed up by the Flight Director (“Flight”), who is responsible for shuttle operational decisions and making mission goal trade offs. The voice loops system maps to this structure by allowing all 16 mission controllers under them to speak on a loop with them. Each of those controllers, who are experts in their area, have their own more specialized support staff in the “back room” that are experts in individual subsystems and communicate with the controller on a different loop.
Because of this structure, there is no need for controllers to go out of their way to update other controllers, since they are already listening to the controller to Flight loop.
The voice loop system has rules and a structure. These constraints are not due to technical limitations, but are shaped by the needs and hierarchy of the organization. Loops are established beforehand and are standardized. If instead, anyone could create a new loop at anytime, each time a team might create one with slightly different shapes, requiring each person interested in it to continually re-learn what the loop was used for. Having the loops already in place and standardized saves controllers the burden of this re-learning and creation when they may not have the time or capacity. Another example is that controllers do not speak directly to other controllers on their loop, but instead to the Flight Director, where other controllers are also listening.
Each of the voice loops have their own level of abstraction. For example, the Flight Director loop, due to its importance, is reserved for only high significance updates in clear and concise language. Where as a loop between the controller in the “front room” and their support in the “back room” may be more granular and technical. This allows controllers to pass event level data to other groups instead of just raw data.
Additionally all controllers monitor the air to ground loop, but only one person, designated CAPCOM (derived originally from Capsule Communicator), can speak with the astronauts. CAPCOM is themself an astronaut who sits right next to the Flight Director. Even though these two could speak face to face, most of their communication is on a public loop so others can be involved.
The system, while not having extreme flexibility, does have capacity in reserve in the form of conference loops. These loops are setup before hand and remain empty until they’re needed for specific situations as they arise for controllers to coordinate with each other, perhaps when addressing a specific problem or incident.
Voice loops also allow controllers to gauge the interruptibility of others by tuning into their front to back loop. This lets them calibrate how important and relevant their communication is at the time. The system also has rules that help the operators even when they make mistakes. Should they make a mistake and interrupt and an inopportune time, the receiving party can simply say standby and then resume their previous discussion. Like radio, there are verbal indications for when something needs to be overridden, they can use “break, break, break”.
Through the monitoring of multiple loops in parallel (typically a minimum of 4), controllers have the ability keep an awareness of what’s going on without actively having to spend their attention in each channel. Controllers are able to join a voice loop and listen in without alerting others. This puts the burden on the person needing the information and doesn’t disturb the team being listened to. Also, the ability to listen in can allow different groups to anticipate what questions they might be asked as a result of other events and have more time to prepare.
The lesson here is not that everyone need go out and implement their own voice loop system, but instead that communication and coordination systems can be designed with some of the same features in mind:
- It allows people to listen without disturbing others
- It allows for anticipation
- It maps to the shape of the organization
- It allows individual users to determine how they spend their attention by changing volume
- It uses a channel that isn’t already overloaded (audio vs visual)
Many of these are missing in the typical communication tools used by software teams. For example, you can “eavesdrop” on slack channel, but it can be difficult to follow along since you must have that screen up in front of you. Telephone conference bridges require each person to queue and wait to talk.
Most of the systems I’ve worked in that have used radio or telephone lack many of these features. In the case of radio, when multiple are available, I have tuned in to other channels to allow me to stay up to date without actively spending my attention. I’ve found, similar to what the controllers experienced, that with time I could detect some unexpected communication, without previously have been noticing each thing said.
Do your communication and coordination system offer some these features?