Client & Stakeholder Communication

Introduction

A show goes wrong at eleven minutes past eight. Not because anybody lacked skill — the people in that room are good — but because one person said something, another person heard something slightly different, and nobody checked. That is the most common failure mode in this industry and it has nothing to do with equipment.

Communication gets taught badly because it gets taught as a personality. Some people are good with clients, the thinking goes, and some people are technical. This book takes the opposite view, and it is not a motivational position: it is the documented position of two industries where a dropped message kills somebody.

Aviation wrote it down after a run of accidents in which perfectly serviceable aircraft were flown into the ground by crews who could see the problem and did not say it clearly enough. The FAA's Advisory Circular on Crew Resource Management names the barriers — rank, age, gender, organisational culture — and names the skill that gets past them, which it calls inquiry, advocacy and assertion. Healthcare wrote it down after the same realisation about handovers, and the AHRQ's TeamSTEPPS curriculum names the tools: call-out, check-back, teach-back, handoff, SBAR.

None of that is soft. They are techniques, with names, that can be practised on a headset tonight, and this book teaches them in AV terms alongside the client-facing half: setting expectations, writing clearly, delivering bad news, and closing the loop. The claim is not that you should communicate better. It is that there is a specific thing to do, and here it is.

How to Use This Book

Read it in order the first time. It runs from why the subject matters, through who is actually in the room, into listening and expectations, then into the named tools and where each one belongs — on comms, in a brief, in a hard conversation, at a handover.

Then come back to four chapters as working documents. The named tools are something to practise one at a time. The brief and the debrief are templates. The chapter on saying the unwelcome thing is worth rereading before any conversation you are dreading. And the handover chapter is the one to read before your first shift changeover on a long show.

Keep a notebook

One record makes this subject concrete: every time a message went wrong, write down what was said, what was heard, and what it cost. Three lines, on the day, while you still remember the wording. A month of that will show you your own pattern — most people have one, and it is usually either assuming context the other person did not have, or failing to confirm that they understood. You cannot fix a pattern you have not seen.

A note on the words

"Stakeholder" is a word that makes technicians wince, and it is used here because there is no better one for the set of people who can affect or be affected by the job: the client who pays, the producer who runs it, the venue, the other vendors, the speaker on stage and the audience. "Client" in this book means the person who engaged you. "Brief" is a noun and a verb, and the book means the pre-show conversation both times. Where an aviation or healthcare term is used — call-out, check-back, teach-back, handoff, SBAR — the book says which source it came from, because the whole point is that these are named things with definitions rather than general advice.

A note on safety

Both of the industries this book borrows from wrote their communication rules in response to deaths. That is worth sitting with, because it is also the reason the techniques are precise rather than general. A check-back exists because a mishearing killed people.

Our industry has the same exposure in a smaller way and in specific places. A cue misheard on comms moves flown scenery, fires pyrotechnics, releases automation, or sends somebody onto a stage that is not ready. A rigging call that was acknowledged by somebody who did not actually hear it is the classic case, and it is why the call-out and the check-back in this book are not presented as communication style. On anything that moves, burns or carries load above people, the confirmation is part of the procedure, not a courtesy.

There is a second and quieter hazard, and it is the one the aviation material is really about. The barrier that stops a junior or freelance person saying "I do not think that is safe" is rank, and rank is listed in the FAA's own text as a communication barrier. If you take one thing from this book, take the chapter on saying the unwelcome thing, because being new, freelance or junior is exactly the position from which the unsaid thing goes unsaid.

Why Communication Wins

Clients cannot see your technical work. They can see every single thing about how you communicated, and that is what they are actually judging.

Technical skill gets you in the door. Communication decides whether you stay and grow.

The hidden skill of AV

In a field built on technology, the skill that most decides whether you keep working is the one nobody examined you on. Clients rarely judge the deep technical quality of a job — they cannot see it, and they have no way to assess it. What they can assess, with complete confidence, is whether they felt understood, whether they were kept informed, whether you were easy to deal with, and how you behaved when something went wrong.

The uncomfortable consequence is that a technically excellent job delivered with poor communication feels like a bad job to the person paying for it, and a merely solid job delivered with excellent communication feels like a great one. That is not clients being shallow. It is clients using the only evidence available to them.

The same holds across the crew, where it matters faster. Shows run on people coordinating under time pressure, and the person who gives instructions that can be acted on, asks the question rather than guessing, and says what they have actually done is the person who gets handed responsibility. Communication is not a thing alongside the technical work; it is the medium the technical work travels in.

Communication is two-way

Most people picture communication as transmission: having a message and getting it out. The larger half is the other direction, and the AHRQ's TeamSTEPPS curriculum gives the idea a name — the transaction model of communication, in which two or more people continuously share information to co-create meaning. Meaning is not sent. It is built between two people, and either of them can wreck it.

That has a practical consequence that runs through this whole book. If meaning is co-created, then the only way to know a message arrived is to get something back. Not a nod, and not "yeah, got it" — something that demonstrates the content arrived. TeamSTEPPS calls the general practice closed-loop communication and names the specific moves inside it. They are in chapter six.

Skipping the listening half is how you end up confidently solving a problem nobody had. It is the most expensive error in this trade and the most invisible, because everything feels fine right up until the reveal.

How to do it

1. Say the thing, specifically, and to a named person rather than the room.
2. Ask for something back that contains the content, not an acknowledgement.
3. Listen to what comes back and compare it with what you meant.
4. Correct it there and then if it differs, without making it awkward.
5. Record anything that matters in writing afterwards, briefly.
6. Follow up when the thing is done, so the loop visibly closes.

What goes wrong

Practice it

On your next job, without telling anybody you are doing it.

Who Is Actually in the Room

"The client" is usually four people who want different things, and one of them is not in the meeting.

The six parties to an AV job

Almost every miscommunication that survives first contact is really a mis-identification: you communicated well, with the wrong person. Before a job, it is worth naming who is actually involved, because they have different information, different authority and different definitions of success.

• The client who pays. Holds the budget and the final say. Often the least technical person involved and the one most exposed if it goes wrong.
• The producer or project manager. Runs the event day to day, makes most real decisions, and is usually who you actually talk to. Not always the same person as the client.
• The venue. Owns the room, the rules, the power, the access times and the restrictions nobody mentioned. Has authority to stop you.
• The other vendors. Staging, lighting, scenic, catering, security. Your schedule is their schedule, and nobody has told them that.
• The presenter or performer. The person whose experience the whole thing exists for, who is usually consulted last and whose needs change everything.
• The audience. Never in the meeting, cannot complain until afterwards, and is the only measure that finally matters.

Two of those are the usual sources of a surprise: the venue, because its restrictions arrive late and are not negotiable, and the presenter, because what they actually want often contradicts what was specified months earlier.

Who decides, and who only influences

Of the people in a conversation, usually one can approve a change, one can veto it, and several have opinions. Working out which is which early saves an enormous amount of effort spent persuading somebody with no authority, and prevents the worse error of acting on an instruction from somebody who could not give it.

Ask directly and without apology, at the start: who signs off a change to this, and who needs to know when it changes? Those are two different lists, and both are short. Almost nobody minds being asked, and the question marks you out as somebody who has done this before.

The specific trap in AV is the enthusiastic stakeholder — a marketing lead, a speaker, somebody's assistant — who asks for a change on site, pleasantly and with apparent authority. It is not rudeness to say that you will check; it is the only way to avoid doing unpaid work that the person paying never approved and may not want.

What each one needs to hear, and when

Different parties need different information at different times, and sending everything to everybody is the same as sending nothing. The client needs to know about money, risk and anything that changes what the audience sees. The producer needs the schedule and anything affecting it. The venue needs access times, power, loads and anything touching the building. Other vendors need your schedule where it overlaps theirs.

Volume is its own failure. A technician who copies everybody into everything has not communicated well; they have distributed the work of filtering onto people who will not do it. Decide who needs each piece and send it to them.

Timing matters as much as content, and the rule is the same everywhere in this book: earlier is better, and bad news earliest of all. A risk flagged three weeks out is a planning conversation. The same risk flagged on the day is an emergency with your name on it.

How to do it

1. List every party: who pays, who runs it, the venue, the other vendors, the presenter, the audience.
2. Put a name and a contact against each one rather than a role.
3. Establish who can approve a change, and who merely needs to know.
4. Ask the venue directly for access times, power, load limits and restrictions, in writing.
5. Find out who is talking to the presenter, and whether anybody has asked them what they need.
6. Agree where updates go: one channel per party, not everything to everybody.

What goes wrong

Practice it

For a job you are working on now or did recently.

Listening & Understanding People

Listening is not waiting. It is a set of specific moves, and the last one is the only proof that any of it worked.

You cannot serve a need you do not understand. Listening is the first professional act.

Active listening

Active listening has a reputation as a soft phrase, which is a pity, because it describes four hard things: giving the person your actual attention, not composing your reply while they speak, asking the question that opens the thing up rather than closing it, and saying back what you understood so they can correct it.

The last of those is the one that does the work and the one people skip. "So the awards run from eight, and you want the walk-on music under the host rather than the VT" is a sentence that takes four seconds and prevents a whole category of expensive error. It is also, in TeamSTEPPS terms, a check-back — the same move the named-tools chapter teaches for comms.

The hardest part is silence. Most people fill a pause within a second or two, and most clients need three or four seconds to say the second, truer half of what they were telling you. The technician who can sit in that pause hears things nobody else on the job hears.

Understanding different people

The people you work with differ in what they know, what they fear and what they need from you, and matching your communication to that is not manipulation — it is the difference between being understood and being technically correct at somebody.

• The non-technical client. Needs outcomes and consequences, not components. "You will not be able to see the lower third from the back three rows" lands; a conversation about pixel pitch does not.
• The technical peer. Wants the detail and is insulted by simplification. Give them the specifics and the actual constraint.
• The anxious client. Usually somebody personally exposed if the event fails. Needs frequency more than depth: short, regular, unprompted updates reduce anxiety far more than one thorough briefing.
• The absent decision-maker. Communicates through somebody else. Write for the person who will forward it, not the person reading it.

The underlying move is the same in every case: work out what this person is afraid of, and address that. A producer is afraid of the schedule, a client is afraid of being embarrassed in front of their own leadership, a venue is afraid of damage and overrun, and a presenter is afraid of looking foolish. Say the thing that answers the fear.

Hearing what was not said

Clients routinely describe a solution instead of a problem. "We need two big screens" is a solution. The problem underneath might be that half the room could not see last year, which may or may not be solved by two big screens and may be solved better by moving the stage.

The question that gets underneath it is some version of what are we trying to achieve, asked without making the person feel second-guessed. "What went wrong last time?" is often the single most productive question in a scoping conversation, because almost every specification is a reaction to a previous failure nobody mentioned.

The commercial reason to do this, rather than simply quoting what was asked for, is that the person who understood the actual problem gets asked back. Supplying exactly what was specified is a service anybody can provide. Working out what they needed is the thing that makes you difficult to replace.

How to do it

1. Put the phone down and take notes by hand or in a document they can see you writing in.
2. Let them finish, including the pause they will leave in the middle.
3. Ask what the event is for and what went wrong last time, before asking anything technical.
4. Ask the questions that open it up, not the ones that confirm what you already assumed.
5. Say back what you understood, in their language, and let them correct it.
6. Write it up afterwards and send it, so the understanding is on record.

What goes wrong

Practice it

In your next scoping conversation.

Setting & Managing Expectations

Almost every unhappy client is a client whose expectation was never stated out loud, by either side.

Most conflict is not about what happened — it is about what people expected to happen.

Setting expectations

An expectation is what someone believes will happen. It exists whether or not you created it, and if you do not set it, they will set it themselves out of a previous job, a photograph, or something a salesperson implied. Expectation management is not dampening enthusiasm; it is making sure one shared picture exists before anybody commits money to it.

Four things are worth stating explicitly at the start, because all four are routinely assumed differently by the two sides. What exactly will be delivered, in terms of what the audience will experience. When each part happens, including when you need the room. What you need from them, which is almost always more than they expect — content deadlines, access, decisions, a contact on the day. And what is not included, which is the one nobody writes down.

Say the constraints while they are still abstract. A limitation explained during planning is a design decision the client participates in. The identical limitation discovered on site is a failure they blame you for, and nothing about the limitation changed in between.

Managing expectations as things change

Events change continuously, and the expectation set in week one will not survive to the show unless it is actively maintained. The failure is not that things changed; it is that one party updated their picture and the other did not.

When something changes, say so immediately, say what it means in terms they care about, and say what you propose. The sequence matters: the change, the consequence, the recommendation. A change delivered without a consequence makes the client do work they cannot do, and a change delivered without a recommendation makes you look like you have no plan.

The specific hazard is the accumulating small change. Each individually trivial addition — one more microphone, a second camera position, a longer rehearsal — is easy to absorb, and four of them together are a different job at the same price. Note each one as it happens, in writing, with its consequence in time or money, even when you intend to absorb it. Then absorbing it is a visible gift rather than an invisible loss.

The expectation nobody states

Underneath the deliverable there is always an unstated expectation about how the thing will feel, and in corporate AV it is almost always the same one: the client expects not to be embarrassed in front of their own senior people. That is the actual product.

Knowing that changes what you tell them. It explains why they care disproportionately about the start — the first two minutes are when their leadership forms its view — and why a technical problem in a rehearsal upsets them more than the same problem fixed quietly on the day.

It also explains the single highest-value habit in client communication: telling them a problem has been solved before they knew there was one. "The second camera had a fault this morning, it is swapped and tested, nothing to do" buys more trust than a flawless day they never heard about, because it shows them the thing they are actually buying, which is somebody who is on top of it.

How to do it

1. State what the audience will experience, not what equipment is involved.
2. Give the schedule, including what you need from the venue and when.
3. List what you need from them, with dates: content, decisions, access, a contact on the day.
4. Say plainly what is not included.
5. Say the constraints now, while they are abstract and can still be designed around.
6. Put it in writing and get a reply, so one shared picture exists on the record.
7. Note every change as it arrives, with its consequence, even when you absorb it.

What goes wrong

Practice it

On a current job.

Clear, Professional Communication

Clarity is not politeness and it is not formality. It is whether the reader can act on it without asking you a question.

Say the right thing, to the right person, clearly, and confirm it landed.

Being clear

The test for a message is simple and unforgiving: can the person act on this without replying to ask something? If they have to come back, it was not clear, however well written it was.

• Put the point first. The ask or the news goes in the first line, not after the context. People read the first line and skim the rest.
• One subject per message. Two questions in one email reliably get one answer, and it will be to whichever was easier.
• Name the person who must act. A request addressed to a group is a request addressed to nobody; this is exactly why TeamSTEPPS specifies that a call-out directs responsibility to a named individual.
• Say when. "As soon as possible" is not a deadline. A date is a deadline.
• Translate the technical into the consequence. Not the specification, but what it means for what they will see, pay or have to decide.

Length is not the enemy; density is. A long message that is well structured, with the ask at the top and the detail beneath, works perfectly. A short message that assumes context the reader does not have produces three more messages.

Professionalism and tone

Professional tone is calm, direct and warm, and the three are not in tension. Calm means the writing does not escalate when the situation does. Direct means saying the thing rather than circling it. Warm means a human wrote it, because the people who are easiest to work with are the ones who get rebooked.

Formality matters less than most people think and consistency matters more. Match the register of the person you are writing to and keep it steady. Where tone most often goes wrong is under pressure: a message written angry reads angrier than it felt, and it is permanent. The rule that has saved more relationships than any other is to write it, not send it, and look again in twenty minutes.

Two specifics for this trade. Never criticise another vendor to a client, however deserved — it reads as deflection and the industry is far smaller than it looks. And never put in writing anything you would not want forwarded, because everything is forwarded eventually, usually to the person it was about.

Writing the message that gets acted on

Most AV communication is now written, asynchronous, and read on a phone between meetings. That changes what good looks like. The reader is skimming, interrupted, and deciding in the first line whether to deal with it now or later, and later usually means never.

A message that survives that has a shape: a subject line that says what it is and whether action is needed, the ask in the first line with the deadline, the context underneath for anyone who wants it, and anything long as an attachment rather than in the body.

Match the channel to the urgency and the permanence. Anything that must be acted on in minutes is a phone call, and anything that matters later must end up in writing even if it happened on a call. The pattern that covers both is to phone and then confirm by message: "as discussed, we are moving the rehearsal to two, and you are confirming the room." That one habit removes most of the disputes in this book.

How to do it

1. Decide the single thing you want to happen and who has to do it.
2. Write a subject line that says what it concerns and whether action is needed.
3. Put the ask and the deadline in the first line.
4. Put the context underneath, for whoever wants it.
5. Keep it to one subject; start a second message for the second thing.
6. Read it once as the recipient, on a phone, in a hurry. Cut what they do not need.
7. If it was urgent, phone first and send this as the confirmation.

What goes wrong

Practice it

With the last ten messages you sent about work.

The Named Tools

Four techniques with names and definitions, taken from a curriculum written because people died of mishearing. All four work on a headset tonight.

Closed-loop communication

The AHRQ's TeamSTEPPS curriculum defines closed-loop communication as using verbal feedback, including call-outs, check-backs and teach-backs, to ensure that recipients correctly understand messages. That is the whole idea, and the value is in the three named moves rather than the principle.

What makes it a loop is that the message comes back. Not an acknowledgement — the content. "Copy" closes nothing, because it is equally available to somebody who heard correctly and somebody who heard nothing at all.

In AV the loop usually breaks in one of two places: a noisy load-in where acknowledgement is assumed, or a client conversation where politeness substitutes for comprehension. The tools below address both.

Call-out, check-back, teach-back

• Call-out. TeamSTEPPS describes it as a strategy for communicating important or critical information, which informs all team members simultaneously, helps them anticipate next steps, and directs responsibility to the specific individual by name. On a show that is "Sam, house lights to half on my mark" rather than "can someone get the house lights".
• Check-back. A closed-loop strategy to ensure information shared by one team member is correctly understood by another. The receiver says the content back. "House lights to half, standing by." Three seconds, and it catches the mishearing before it becomes an event.
• Teach-back. A method to confirm you explained something clearly, by asking the other person to explain it in their own words. This is the one nobody in AV uses and the one with the most value with clients, because a client nodding is not a client understanding.
• SBAR. A technique for communicating critical information that requires immediate attention and action: the situation, the background, your assessment, your recommendation. It is how to raise a problem to somebody senior in fifteen seconds without rambling.

Teach-back deserves a note, because asking a paying client to explain something back can feel like a test. The trick is to put the burden on yourself rather than them: "I have thrown a lot at you — can you tell me how you would describe the rehearsal plan to your director, so I can check I have been clear?" Nobody minds that, and it routinely surfaces a misunderstanding that would have arrived on the day.

SBAR, for the problem you have to escalate

Most technicians raise a problem badly under pressure. They start with the history, or they lead with the technical cause, and the person listening cannot tell how bad it is or what is being asked of them. SBAR fixes the order.

• Situation. What is happening, in one sentence. "We have lost the feed to the overflow room."
• Background. The relevant context only. "It went down when the switcher was repatched at lunch."
• Assessment. What you think it means. "I think it is the fiber run, not the switcher."
• Recommendation. What you want. "I need ten minutes and somebody to hold the start, or we run overflow on the backup feed at lower quality."

Four sentences, and the person on the other end knows the severity, the cause, and the decision they have to make. The reason to practise it is that under pressure you will default to whatever shape you have practised, and most people's default shape begins with the history.

How to do it

1. Pick one tool and use it deliberately for a whole show, rather than trying all four.
2. Start with the check-back, because it is invisible to anyone who is not listening for it.
3. Add the call-out next: name the person and give the action, every time.
4. Use teach-back once with a client, framed as checking your own clarity rather than theirs.
5. Write your SBAR for the most likely failure on this job, before the show, while you are calm.
6. Debrief yourself afterwards: where did the loop stay open, and what did it cost?

What goes wrong

Practice it

On your next show, one tool at a time.

Talking on Comms

A headset is a shared, interruptible, permanent-feeling channel with no tone of voice to spare. It has its own discipline.

The discipline of a shared channel

Comms is the one place where every rule in this book has to operate in under three seconds, in noise, in front of everyone. The conventions exist for that reason and they are worth knowing explicitly rather than absorbing by osmosis.

• Name first, then the message. The listener needs to know the message is for them before they need to know what it is.
• One transmission, one idea. The channel is shared; a monologue blocks everyone who needs it.
• Standby before go. A warning, then the execute. The standby is what lets somebody say they are not ready.
• Confirm the content. The check-back, in its natural habitat.
• Say when you are leaving and when you are back. An unanswered call to somebody who stepped out costs more than the ten seconds of telling people.

Keep the channel clear for the people who need it. Chatter is part of what makes a long show bearable and it belongs on the channel where it does not sit on top of a cue.

Tone, pressure and the open mic

Comms strips tone. Brevity that feels efficient to you can read as anger to somebody who cannot see your face, and under pressure the stripping gets worse at exactly the moment it matters most.

The practical defence is to stay level and say the thing rather than the feeling. "Camera two, I have lost you, standing by" works. Sighing into an open mic does not, and everybody hears it.

Assume the mic is open and assume the client is listening. Both are true often enough to be the safe assumption, and a comment about a client, a presenter or another vendor is the single most expensive thing a technician can say on a headset. It reaches the wrong ears more often than anybody expects, and the industry is small.

When the loop has to be fastest

In the moments that matter — a cue sequence, a live transition, anything moving above people — the full discipline is not optional and there is no time for it either. That tension is resolved by having practised it, which is why the tools in the last chapter are worth drilling on ordinary shows.

If something is going wrong, say it immediately and plainly. The instinct to wait until you are certain is the one that turns a recoverable problem into a visible one. "I think I am losing the main feed, standing by" costs nothing if you are wrong and saves the show if you are right.

And if you did not hear a call, say so. The most expensive two words on a headset are an uncertain "copy" from somebody who caught half of it. "Say again" is the professional response, and nobody has ever been thought less of for it.

How to do it

1. Open with the name of the person you want, then the message.
2. Keep each transmission to a single idea.
3. Give a standby before a go, so people can say they are not ready.
4. Confirm the content back, not just that you heard something.
5. Say when you leave the channel and when you return.
6. Say "say again" rather than guessing.
7. Keep chatter off the channel that is carrying cues.

What goes wrong

Practice it

On your next show with comms.

The Brief, and the Debrief

Aviation briefs every single flight. Our industry briefs almost nothing, and then wonders why everybody had a different plan.

What a brief is for

A brief is not a schedule read aloud. Its purpose is to get one shared picture into several heads and to give everybody a licence to speak. The FAA's Crew Resource Management guidance treats briefings as a curriculum topic in their own right, and the reason is that a crew that has been briefed together behaves differently from a crew of individuals who each read the same document.

A good AV brief is short and covers five things: what the show is and what matters about it, who is doing what, the timings and the hard deadlines, what is different or risky about this one, and what to do when something goes wrong — including who to call and on which channel.

The fifth is the one most often skipped and the one the brief exists for. A crew that has heard out loud what happens if the main feed fails behaves calmly when it does. A crew that has not will improvise, in parallel, in different directions.

Giving a brief people remember

Keep it short enough that people listen to all of it. Five minutes well structured beats twenty that lose the room in the third. Say the thing that is different about today early, because that is what people will actually retain.

Finish by inviting questions and then waiting. The pause has to be genuinely uncomfortable before anybody will use it, and the question that comes out of it is usually the one that would otherwise have become the problem. A brief that ends with "any questions?" and a two-second pause has not invited anything.

Brief the client too, in their own version: what will happen, when you need them, what you need from them, and what you will do if something goes wrong. Clients who have heard the contingency out loud panic measurably less when it is used.

The debrief, which almost nobody does

The FAA's guidance lists crew self-critique — review, feedback and critique focusing on the process and the people involved — as a curriculum topic, and calls careful debriefing one of the best techniques for reinforcing good practice. Our industry strikes the set and goes home.

A debrief does not need to be a meeting. Five minutes at the end, or a short message the next morning, covering three questions: what worked, what nearly went wrong, and what we would do differently. The middle question is the valuable one, because near-misses are free information and they are forgotten within a day.

Keep it about the process rather than the people, which is what the FAA's wording specifies, and is also the only way anybody will tell you anything true. A debrief that becomes an accounting of who erred will be the last honest one you get.

How to do it

1. Say what the show is and what matters most about it, in two sentences.
2. Say who is doing what, by name.
3. Give the timings and the hard deadlines.
4. Say what is different or risky about this one.
5. Say what happens when it goes wrong: who calls it, who to contact, on which channel.
6. Invite questions and wait long enough to be uncomfortable.
7. Afterwards, debrief in five minutes: what worked, what nearly went wrong, what we would change.

What goes wrong

Practice it

On your next show, whatever your role.

Saying the Unwelcome Thing

The FAA lists rank as a barrier to communication. Freelance, junior and new are all forms of rank, and all three produce the same silence.

Why the unsaid thing goes unsaid

Crew resource management exists because of accidents in which somebody in the cockpit could see the problem and did not say it loudly enough or soon enough. The FAA's Advisory Circular is explicit about the external barriers involved: rank, age, gender and organisational culture. Those are not soft factors in that document; they are listed as the things that stop information reaching the person who needs it.

Every one of them operates in AV. The freelancer who was booked yesterday, the youngest person on the crew, the one person who is not part of the regular team, and the technician talking to a client who is paying — all are in the structurally weaker position, and all will hesitate before contradicting somebody.

The important move is to stop treating that hesitation as a personality flaw. It is a predictable response to a power gradient, and the fix is a technique rather than more courage.

Inquiry, advocacy, assertion

The FAA's curriculum names the skill directly: inquiry/advocacy/assertion, described as training in the potential benefits of crewmembers advocating the course of action they feel is best, even though it may involve conflict with others. Three escalating steps, and the escalation is the point.

• Inquiry. Ask the question that surfaces the concern without accusing anybody. "What is holding the upstage leg?" This is the cheapest step and it resolves most situations, because often the other person has an answer you did not know.
• Advocacy. State your view and your reason. "I do not think that clamp is rated for it, and I would want a second point." You have now put a position on the record.
• Assertion. Say it plainly, say what you want, and keep saying it until you get a real answer. "I am not happy flying that until it has a second point. Can we stop and look at it?"

Most people can do the first step and stall before the third, which is precisely the gap the aviation training was built to close. Knowing the three steps have names, and that stepping up through them is the expected professional behaviour rather than making a scene, is most of what it takes.

Disagreeing with a client, and the two-challenge habit

With a client the gradient is commercial rather than hierarchical, and the fear is losing the work. The approach that holds the relationship is to separate the person from the problem and to arrive with an alternative: not "that will not work", but "that will not give you what you want for this reason, and here is what will".

Put the consequence in their terms rather than yours. A client does not care that a run is too long; they care that the picture will break up during the keynote. Technical objections translated into audience experience get acted on; the same objection in technical language gets overruled by somebody who could not evaluate it.

And if the client still chooses differently, say your position once more, clearly, then do it their way and write down what was decided. That is not capitulation: a professional who has stated a concern in writing has done their job. The exception is the one the safety note opened with. Where it is a question of safety rather than quality, "they overruled me" is not a defence, and the answer is to stop and escalate rather than proceed and record.

How to do it

1. Start with inquiry: ask the question that surfaces it without accusing anybody.
2. Listen to the answer; it may be the one you did not have.
3. If it does not resolve, advocate: state your view and your reason in one sentence.
4. If it still does not resolve, assert: say what you want, plainly, and ask for a decision.
5. Translate the consequence into what the audience or the client will experience.
6. Offer the alternative, so the conversation is about two options rather than your refusal.
7. Where it is quality, state it once more and record the decision. Where it is safety, stop and escalate.

What goes wrong

Practice it

Think of the last time you did not say something you should have.

Hard Conversations & Closing the Loop

Problems are certain. How you communicate them is the part that is actually under your control, and it is what people remember.

Anyone can communicate when things go well. Trust is built in how you handle the hard moments.

Delivering bad news and handling problems

The instinct to delay bad news is exactly wrong, and it is worth understanding why rather than just being told. Delay removes the other person's ability to respond while there is still time, and it converts a problem into a betrayal at the moment they find out you knew.

The professional sequence is early, honest and with options. Tell them as soon as you know, rather than when you have a solution. Give the real picture without spin, including what you do not yet know. And arrive with a proposed path rather than only a problem — even a bad option and a worse one is something they can decide between.

This is SBAR again, in client language: the situation, the relevant background, what you think it means, and what you recommend. Bad news delivered in that shape frequently increases trust, because it demonstrates the thing the client is actually buying, which is somebody who is on top of it.

Complaints follow the same spirit. Listen to the whole thing without defending, acknowledge it genuinely, and move to the fix. People rarely expect perfection; they expect to be heard and to see it made right. A calm, accountable recovery often leaves a client more loyal than if the problem had never happened.

Closing the loop

Closing the loop means going back to the person and confirming the thing is done. It is a different loop from the closed-loop communication of chapter six, which confirms that a message arrived; this one confirms that the work it asked for is finished. It is the least glamorous habit in this book and the one that most reliably separates people who get rebooked from people who do not.

Most people close about half their loops. They fix the problem and move on, because to them it is finished — but the client is still carrying it, because nobody told them. The cost of that silence is paid in the client's anxiety and in the chasing message they now have to send.

Keep a visible list of what you owe people: questions you have not answered, things you said you would check, problems being fixed. Clear it at the end of each day with a line each. "The second camera is swapped and tested" takes ten seconds and removes an item from somebody else's worry list.

After it goes wrong

When something actually failed in front of an audience, the conversation afterwards decides whether you work for them again, and it is almost entirely about accountability rather than cause.

Say what happened plainly, without technical fog. Say what you have changed so it does not recur. Do not blame another vendor even where another vendor was the cause — say what you will do differently, because that is the only part within your control and the only part they can act on.

Then actually change it, and tell them you did. A follow-up a week later saying what is now different is rare enough to be remembered, and it converts the worst day of a working relationship into the reason it continued.

How to do it

1. Tell them as soon as you know, not when you have a solution.
2. Lead with the situation in one sentence, then only the relevant background.
3. Say what you think it means, including what you do not yet know.
4. Bring at least two options, even if both are imperfect, and recommend one.
5. Say what you need from them and by when.
6. Confirm in writing afterwards.
7. Close the loop when it is resolved, without being asked.

What goes wrong

Practice it

Using a real problem from a recent job.

The Handover

A handover is not telling somebody what happened. It is giving them responsibility, and the difference is where shows break.

What a handover actually transfers

The AHRQ's TeamSTEPPS curriculum defines a handoff as a standardised method for transferring information along with authority and responsibility during transitions in care, and specifies that a proper handoff includes the transfer of responsibility and accountability. That last phrase is the whole subject.

Most AV handovers transfer information and nothing else. The outgoing operator says what has been happening, the incoming one nods, and for a period neither of them is clearly in charge. That ambiguous period is when the thing that was nobody's job stops being done.

The fix is to make the transfer explicit and verbal. Somebody says they have it, and somebody says they no longer do. It sounds stilted and it takes four seconds, and it is the difference between a handover and two people standing near each other.

What to hand over

• The current state. What is running right now, and what is about to happen.
• What has changed today. Anything that differs from the paperwork, because the paperwork is what they have read.
• What is broken or suspect. Including the thing you have been working around. This is the item most often omitted and most often costly.
• What is outstanding. What you promised somebody and have not yet delivered, with who is waiting.
• Who to contact. Which client, which producer, which channel, and who is awake.
• The explicit transfer. "You have it." "I have it."

Write the first five down rather than saying them. On a long show or a multi-day event, a running handover note that each shift adds to is worth more than anybody's memory at the end of a fourteen-hour day, which is precisely when handovers happen.

Handing a client over

The same applies to client relationships, and it is done worse. When a job moves from a salesperson to a project manager to an onsite crew, the client re-explains their event at each boundary, and each re-explanation erodes their confidence that anybody is holding it.

What transfers is not just the specification but the things that are not written down: what they are anxious about, what went wrong last year, who actually decides, and the one thing they have asked for twice. Those are the items that make a client feel known, and they are exactly what falls out of a handover based on documents.

Tell the client the handover is happening, by name, and introduce the two people where you can. A client who has been told who has them next, and who hears that person already knows the history, does not have to start again — and starting again is the experience that makes clients believe a supplier is disorganised even when the work is excellent.

How to do it

1. Say the current state and what is about to happen.
2. Say what has changed today from what is on paper.
3. Say what is broken or suspect, including anything you are working around.
4. Say what is outstanding and who is waiting for it.
5. Say who to contact, on which channel.
6. Make the transfer explicit out loud: "you have it" answered by "I have it".
7. On long or multi-day shows, keep a running written handover note each shift adds to.

What goes wrong

Practice it

At your next shift change, or on your next job that changes hands.

Where to Go Next

The tools in this book are general, and the next books apply them to specific relationships. Account Management is about the long relationship rather than the single job. Technical Sales Fundamentals is the same skills pointed at winning work rather than delivering it. And Freelance Business Fundamentals covers the commercial half: what to agree in writing before any of these conversations start.

If the crew half interested you more than the client half, the original sources are both free and both short enough to read in an evening: the FAA's Advisory Circular 120-51E on crew resource management, and the communication module of the AHRQ's TeamSTEPPS 3.0 curriculum. Everything named in chapter six comes from the second, and everything in chapter nine from the first.

The first ninety days

Four things, each small. Use a check-back for one whole shift and count what it catches. Give a five-point brief on one show, even if nobody asked you to. Try one teach-back with a client, framed as checking your own clarity. And at one shift change, say "you have it" out loud and hear how different it feels from nodding.

Then start the notebook: every time a message went wrong, what was said, what was heard, and what it cost. A month of that shows you your own pattern, and the pattern is nearly always either assumed context or an unclosed loop.

Where this leads

The technicians who end up running things are rarely the best technicians. They are the ones other people can rely on to say the true thing early, to be understood the first time, and to hand over cleanly. That is a learnable set of techniques rather than a personality, which is the one claim this whole book has been making.

Glossary

What the gear actually looks like

Every device named in this book, in one place. Recognition is the whole point of Chapter 4 — use this page to attach a picture to each name before you meet it on a dock at six in the morning.

Audio

Dynamic microphone

Condenser microphone

Wireless handheld

Radio rack

Mixing console

Stage box / snake

Power amplifier

Main loudspeaker

Subwoofer

Stage monitor wedge

In-ear monitors

DI box

Video

Camera

Video switcher

Scaler / processor

Projector

LED wall panel

Confidence monitor

Lighting & control

Conventional fixture

Moving-head fixture

Lighting console

Dimmer

Show controller

Media server

Networking & infrastructure

Network switch

Patch bay

Equipment rack

Power distribution

Cable tester

A properly coiled cable

Connectors, close up

XLR

TRS / TS ¼-inch

SDI on BNC

HDMI

Cat5e / Cat6 (RJ45)

Fiber optic

DMX (5-pin XLR)

AC power — not signal