Nobody Is Watching

Why remote simultaneous interpretation needs an RSI technician — a technical analysis of how unsupervised Zoom interpretation fails, and what supervision has to mean when the booth is a spare bedroom.

A video has been circulating among colleagues this week. I'm not going to link it, and I'd ask you not to go hunting for it, because the point of this article is not the interpreters in it. The point is that it could have been any of us — and on that setup, sooner or later, it will be.

Here is what happens in it, described generically because the pattern is what matters. A remote simultaneous interpretation assignment, run on a meeting platform, no technician. An interpreter lands in the wrong language channel —one mis-click, the kind you make forty times a day in every other application without consequence. Compounding it, the platform mic ends up muted. The booth mate doesn't catch it, because the "back channel" is a self-patched messaging thread, and the booth mate is — of course — interpreting. Minutes pass. An entire language group hears nothing, or the wrong thing, while two skilled professionals work on in good faith, each certain the other half of the system is fine.

Nobody in that story did anything unusual. That is precisely what should frighten us.

The question nobody can answer

Walk into any properly run on-site conference and look at the interpretation setup. Booths to standard. Consoles. And, without exception, a sound technician — not as a luxury, but as a requirement so settled that no one remembers it being negotiated. The standards assume one. The AV contract includes one. If the technician didn't show up, the event manager would treat it as an incident.

Now ask: what is that technician actually for?

Not the rack. The rack mostly runs itself. The technician is there because live audio systems fail in small, silent, human ways — a channel mis-set, a mic left open, a level drifting — and because the people using the system are, by the nature of their work, incapable of monitoring it while they do that work. The technician is institutionalised attention: a pair of ears and eyes with nothing else to do but watch the system, precisely because everyone else's attention is fully spoken for.

Then interpreting went remote, and something strange happened. The one sound system with its professional operator became five, eight, twelve improvised sound systems — a laptop, an operating system's audio settings, a headset, a meeting platform's interpretation feature, a domestic or office network — each operated by an interpreter, mid-performance, with nobody watching any of them.

The error surface multiplied. And the technician disappeared.

Nobody decided this. There was no meeting where the profession concluded that supervision was no longer necessary. It happened by default: there was no rack to plug in, so no technician was booked, and "no technician" quietly became the norm for remote work. We made oversight optional at theexact moment it became most necessary.

What the standards actually say

It is worth being precise here, because the current norm likes to present itself as the settled way of doing things. It isn't. It is a gap between frameworks.

The profession's own documents never endorsed unsupervised remote work. AIIC's Guidelines for Distance Interpreting set out minimum standards and best-practice working conditions for remote simultaneous interpreting —including the communication channels interpreters must have with the moderator and the relevant technicians.

Read that phrasing again: the guidelines simply assume technicians are in the loop. The platform side is governed by ISO24019, alongside equipment standards (ISO 20109) written for professionally operated systems. Everywhere the frameworks look, supervision is taken forgranted — the question they answer is how interpreters and technicianswork together, never whether the technician exists.

What actually happened during and after the pandemic fell outside all of it — not because interpreters started working from home, but because the supervising role was dropped on the way. Remote delivery is a legitimate, standards-compatible way to work, and a good one: it removed travel, opened rare language combinations, and cut the cost and carbon of multilingual events without anyone's quality suffering. What has no framework behind it is the unsupervised session: a live multilingual audio system with no one watching it. That is not a standard. It is what remained when the technician was quietly left off the list — tolerated in an emergency, then normalised by habit.

And let me close one tempting exit before someone opens it: the answer is not to march interpreters back into equipment-filled premises. The premises were never the point — the supervision was. Location is what remote work rightly made optional; oversight is what it wrongly made optional along the way. The two travelled together for so long that we stopped noticing they were separable. They are: supervision can travel down the same wire the interpretation does. Keep the savings. Restore the safeguard.

So when we ask "does a remote session really need a technician?", we have the question backwards. No professional framework ever contemplated live multilingual audio without one. The burden of proof sits with the unsupervised setup, and five years on, it has not met it.

Why the WhatsApp backchannel is placebo safety

The standard answer, when this comes up, is: "we keep a chat open."

I understand the instinct, and I've done it too. But let's be honest about what we learned — some of us the hard way, and all of us, in principle, from the research on attention that I wrote about a few weeks ago. A simultaneous interpreter's cognitive capacity is fully committed: comprehension, memory, reformulation, production, all at once, continuously. There is no spare channel for monitoring a silent text thread. A message that arrives without sound, while you are interpreting, functionally does not exist. And your booth mate — the other person supposedly watching — is in exactly the same state.

An alert system that only works when nobody is busy is not an alert system. It is a decoration on the risk.

And there's a quieter cost that a colleague pointed out when I raised this: the booth mate who is supposed to be watching is also the booth mate who is supposed to be resting. The off-turn half hour is not a break from the job; it is where the quality of the next turn comes from. When we appoint the partner as the safety net, we are paying for that net out of their recovery —and then out of the afternoon's accuracy. A colleague stepping away for a cup of tea is not negligence. It is the system working exactly as designed. The design is the problem.

The same logic condemns self-monitoring. "I would notice if my mic was muted" — would you? The video says otherwise, and so does everything we know about attention under load. The interpreter is the least able person in the entire event to notice their own channel state, for the same reason a surgeon doesn't monitor the anaesthesia: their attention is the procedure.

This is why the on-site technician was never optional. Not because racks are complicated — because performers cannot supervise themselves. That truth didn't change when the booth became a spare bedroom. Only the staffingdid.

They bought a component and thought they'd bought a capability

There is a second version of this failure, and a colleague described it after I first raised the subject. She and her boothmate arrived at a venue to discover that someone on the client side had decided to live-stream the interpretation through an app — and that this was as far as the decision-makinghad gone. No audio feed. No booth. No technician. Not even microphones, or any device for the interpreters to connect to the app with. When they explained what was actually required, it emerged that the client believed buying the app was the arrangement. It had not occurred to anyone that a person would have to operate it and orchestrate the whole thing.

I want to resist the easy reading of that story, which is that the client was careless. I don't think they were. Every platform in our industry is soldon some version of "no equipment needed, works from any browser, set up in minutes." A reasonable person hears that and concludes the rest was never necessary — the feed, the microphones, the working conditions, the person making them meet. The marketing wasn't lying. It described the software accurately, while the buyer heard a description of the event.

So they bought a component and believed they had bought a capability. And the gap between those two things is exactly where the technician used to stand.

That story and the video are the same failure seen from two sides. Bothare cases of a system missing the person whose job is to make its parts work together — one because nobody was booked, the other because nobody knew the role existed. The difference is only in when you find out. In person, the omission is visible the moment the interpreters walk in, and can sometimes still be rescued by improvisation and goodwill. Remotely, it stays invisible until an entire language group has been silent for four minutes.

Which means the mindset change is not only ours to make. Clients need apicture of what a complete interpretation setup actually contains — and we may be the only people positioned to give them one, because we are the only ones inthe room who have seen it whole.

What the stakes actually are

Let's price the failure, because "it usually works" is doing alot of load-bearing in the current norm.

A wrong channel or a dead mic doesn't degrade the service; it deletes it,for one entire language group, for as long as nobody notices — and the whole point is that nobody is positioned to notice. In a training webinar, that's embarrassing. In a board meeting, a court proceeding, a medical briefing, a diplomatic exchange, it is the kind of failure that ends client relationships —and the reputational bill is presented not to "the setup," but to the interpreters by name. We carry the professional liability for a system nobody is watching.

And here is the bitter economics of it: the cost of the missing safeguard is borne by us, while the saving was pocketed by whoever decided a remote technician was an unnecessary line item — usually by never thinking about it at all.

Deriving the requirements: what remote supervision must be able to do

Suppose we accept the argument so far. What follows for the shape of the solution? Not a product question — an engineering one. Take the failure modes we've actually seen and ask, for each, what a supervisor would need inorder to catch and correct it. Four requirements fall out, and each is forced by a specific failure:

Failure: silent faults across many booths at once. A fault announces itself to no one, and it can occur in any booth at any moment. So the supervisor must be able to hear every channel simultaneously — the way a console operator hears the matrix, not joining and sampling one channel at atime. This is also precisely the ability no working interpreter can contribute, which is why the role cannot be absorbed by the team.

Failure: errors occur at two different layers. The video's wrong channel and muted mic were platform-layer errors; the equally common wrong-microphone and broken-audio-setting faults live at the interpreter's operating system. A supervisor who can see the state of both layers —the platform's interpretation settings and each interpreter's own computer — is watching where errors actually happen. A supervisor who can seeonly one layer will be watching the wrong one on the day it matters.

Failure: the correction itself interrupts the work. Spotting a fault isworth little if the only remedy is typing "CHECK YOUR CHANNEL" into achat the interpreter cannot afford to read — or worse, speaking over the floorfeed mid-sentence. The correction must therefore be executable from the supervisor's side, silently, without the interpreter breaking stride and ideally without the audience ever knowing there was a fault.

Failure: the interpreter is mid-sentence when the fault appears. Spotting a wrong channel is worth little if the remedy is typing "CHECK YOUR CHANNEL" into a chat they cannot afford to read, or speaking over their floor feed and derailing them. So the correction must be executable from the supervisor's side — the channel switched, the microphone opened, silently, without the interpreter breaking stride and ideally without the audience ever knowing there was a fault. Notification then matters only where the interpreter's own console changed and they need to know it: an audible cue for that, and text for anything genuinely requiring words. Note what falls out of this: a supervisor who can act on the system almost never needs to speak to anyone. Talkback that interrupts the floor feed is what you build when you can see the fault but cannot touch it.

That is the specification. Hear everything at once; see both layers; correct silently from outside; interrupt only when the interpreter's own action is genuinely required. A setup that meets all four is a remote technician's station in the meaningful sense. A setup that meets feweris a spectator with a job title — and "someone on standby in the meeting," the most common gesture at supervision, meets none of them.

‍

This specification is deliberately vendor-neutral. Whoever provides your remote sessions — a platform, an LSP, an independent RSI technician — these four capabilities are the questions to ask, and any provider should be prepared to demonstrate them, not describe them.

The ask

So here is the position I think our profession should adopt, and start saying to clients in so many words: a remote simultaneous interpretation session without qualified technical supervision is an unsupervised live audio system, and no professional framework endorses unsupervised live audio for high-stakes use. On-site, we never accepted it. Remote, we should stop accepting it — the way we treat booth standards and team strength: as a working condition that protects the client at least as much as it protects us.

Asking is easier than we fear. Clients accept safety line items far more readily than fee increases — nobody argues with the sentence "for a meeting of this importance, we include remote technical supervision so that any audio issue is corrected within seconds, silently." Consultant interpreters and LSPs assembling remote teams: this belongs on the quote as itsown line. It costs little, it prices honestly, and one prevented incident pays for a year of it.

And on your next remote assignment, one question to whoever is organising: "Who is supervising the audio, and can they correct a channel or mic fault without interrupting the interpreters?" If the answer is a blank look, you have just found the most dangerous line item in the budget — the one that isn't there.

The volume control was part one. The console was part two. The technician is part three — the person the remote booth forgot.

Frequently asked questions

Do you need a technician for remote simultaneous interpretation? Yes, for anysession where a failure has real consequences. On-site simultaneous interpretation has always required a sound technician; remote delivery multiplied the number of separately operated audio setups while the supervising role was dropped along the way. The issue is not where interpreters work —remote interpreting is standards-compatible and works well — but whether anyone is watching the system: no professional framework, from AIIC's distance interpreting guidelines to the ISO standards governing platforms and equipment, contemplates unsupervised live multilingual audio.

Why do Zoom interpretation channels fail during meetings? Common causes are human and silent: an interpreter selecting the wrong language channel, the platform microphone left muted, the wrong microphone chosen at operating-system level, or audio settings changed by an update. Zoom provides no technician role, so these faults broadcast until a listener complains — no one inside the meeting can see another interpreter's channel state or correct it.

Can anyone fix an interpreter's wrong channel or muted mic during a live session? Not in a plain Zoom setup — there is no supervisory role and no remote access to an interpreter's channel selection or computer audio. Effective remote supervision requires an RSI technician setup that monitors all channels simultaneously, sees both the platform layer and each interpreter's system layer, and can correct faults silently from the supervisor's side. Such setups exist; "someone on standby in the meeting" is not one.

Where my interest lies

Disclosure, as always in this newsletter: my company, Green Terp, provides remote technical supervision meeting the four requirements above —across both the interpreters' computers and the meeting-platform layer — as aservice called GT iTech, including for plain Zoom sessions that use nothing else of ours. Below is the supervising side of it, suitably redacted; I show it to demonstrate that the specification in this article is meetable, not hypothetical. If you'd rather hold a competitor to the same four questions, please do — that outcome would also make remote interpreting safer, which isthe point of the piece.

Details: https://www.gtmeeting.com/solutions/gt-itech.

‍

‍

‍