1
Set the Stage
Frame the problem. Identify concepts. Assign stakeholder roles.
10 min
2
ROUND 1 → 2
The Bridge Exercise
Two rounds: cold explanation, then structured. Score both.
35 min
3
?
Reflect Together
Three questions connecting the exercise to real stakeholder relationships.
15 min

Step 1: Set the Stage  10 min

Open with one question. Ask it out loud and do not answer it yet.

"Think of a time when a communication gap cost you or your team something: a decision that went the wrong direction, a project that lost support, a budget that got cut."

Give it 30 seconds. You will get silence, then two or three stories that sound remarkably similar. That shared recognition is the entire premise of the workshop. You do not need to do anything but let it land.

Then give the two-minute framing. Not a lecture, just this:

Technical professionals are trained to be precise. Precision is the right tool when you are talking to someone with the same vocabulary and context. It is the wrong tool when you are not. The problem is that precision reads as complexity to someone who does not share the vocabulary. Complexity creates friction. Friction creates distance. Distance is how good technical work gets deprioritized, underfunded, or overridden by decisions made without your input.

The goal today is not to talk to stakeholders like they are children. The goal is to translate: to take the same information and render it in a register that makes it actionable for someone operating in a different domain.

Choosing a Concept to Work With

Each participant needs a technical concept to use as raw material for the exercise. Give them three minutes to identify one: something they actually explain in their real work, to a real stakeholder they struggle to reach. Ask them to write it down as a one-sentence prompt: "I need to explain [X] to [type of stakeholder]."

Have six concept cards ready for anyone who goes blank. These are real examples that work well because the translation gap is immediately obvious:

API rate limiting
Explain to
VP of Sales
Database indexing
Explain to
CFO
Container orchestration
Explain to
Board Member
A/B testing methodology
Explain to
Marketing Director
Network segmentation
Explain to
COO
Technical debt
Explain to
VP of Product

Setting Up the Stakeholder Panel

Each group is 4–6 people. One person presents at a time; everyone else is the panel. The presenter names the stakeholder role ("I'm explaining this to a CFO") and the rest of the group adopts that role for the duration of their turn. Panel members are not trying to trip the presenter up. They are genuinely listening as that person would listen, with that person's priorities and blindspots.

If your workshop has more than 6 people, split into groups of 4–6 and run all groups simultaneously. Each group runs its own two rounds independently. Bring everyone back together for Step 3.

For remote sessions, assign panel roles in advance in a shared doc. For in-person, a quick role card works. The specific role matters: a VP of Sales asks "how does this affect close rates?" where a CFO asks "what does this cost us if we ignore it?" Naming the role forces the presenter to consider the audience's actual frame of reference.

Step 2: The Bridge Exercise  35 min

Two rounds. Everyone presents once per round, to the same panel, on the same concept. The only difference between rounds is a three-line framework you introduce between them.

Round 1: Cold Explanation (90 seconds per person)

Ground rules are simple. Project them or write them on a whiteboard before Round 1 starts:

Rotate through all participants in Round 1. Keep a running scoreboard. Do not debrief individual presentations yet. There will be a pattern in the data that you want the full round to reveal.

Panelist Scoring Rubric: share with the panel before Round 1
A
I understood what this is.
Score based on how clearly you understood it from inside your assigned role.
5
You could repeat the definition back in your own words without prompting. No unexplained terms. The concept was self-contained.
4
You got the core idea. One fuzzy edge or one term you were not sure of, but you have a working mental model.
3
You understood the shape but not the substance. You know roughly what category of thing this is, but could not explain it to someone else.
2
Mostly lost. A word or phrase landed but not enough to form a coherent picture. Multiple unexplained terms compounded the confusion.
1
No meaningful understanding formed. The explanation was in a vocabulary you do not share and no translation was offered.
Reminder: stay in your role
You are not a technical colleague who can fill in the gaps. If the presenter uses a word or phrase the person you are playing would not encounter in their normal work, score as if you did not understand it, because in that role, you would not. Do not give credit for clarity that depended on knowledge your role does not have.
B
I understood why this matters to me.
Score independently from A. A clear explanation of what something is does not automatically make it relevant.
5
The stakes were stated explicitly in terms that belong to your role: revenue, risk, cost, customer experience, timeline. You know what happens if nothing changes, and you know what you are being asked to do.
4
Relevance was implied and you could probably connect the dots, but the presenter did not state the consequence directly. You are interested but would need to follow up to know what action to take.
3
You understood that something matters to someone, but not specifically why it matters to you in your role. The stakes were described in general terms, not your domain.
2
The consequence was named in technical terms rather than business terms: "increased latency" instead of "customers wait 3 extra seconds and abandon the page." You know something is bad, not why you should act.
1
No connection to your role or domain was established. The explanation ended without a consequence, a risk, or an ask. You have no idea whether this requires anything from you.
What raises Score B
Using a word the stakeholder owns: revenue, cost, risk, timeline, customer satisfaction, headcount. Naming a specific consequence: "this will cause X" or "without this, Y happens by [date]." Ending with a clear ask rather than a presentation. Framing the stakes inside the stakeholder's priorities, not the presenter's.
What you will notice in Round 1
Question A scores tend to run 3–4. Question B scores tend to run 1–2. Almost everyone scores reasonably well on "what this is" and almost no one scores well on "why it matters to me." This is not because the presenters are unclear. It is because they answered the wrong question. They explained their domain. They did not explain the stakeholder's problem.

The Bridge Framework (3-minute interlude)

Before Round 2, give everyone the framework. Write it on a whiteboard or share it on screen. This is the entire thing:

The Bridge Framework: use this in Round 2
1
What it is: one sentence, their language
Plain English. No jargon. If you cannot say it without an acronym or a discipline-specific term, try again.
"We're talking about the limit on how many times our software can ask another service for data in a given minute."
2
What's at stake: their domain, not yours
Risk, cost, or opportunity in the language of whoever you are talking to. Sales speaks in revenue. Finance speaks in cost. Executives speak in risk and time.
"If we hit that limit during a product demo or a high-traffic campaign, the integration fails silently. Customers see errors, not your pitch."
3
What I need: one clear ask
A specific decision or action, not an open-ended handoff. "What do you think?" is not an ask. "I need 15 minutes on the next sprint planning agenda" is an ask.
"I need you to flag this campaign to the team 48 hours in advance so we can raise the limit before launch."

Give participants two minutes to restructure their concept using this framework before Round 2 starts. Two minutes, not ten. The constraint is the point. If the framework requires an hour of preparation, it is not useful in the real world.

Round 2: Structured Explanation (90 seconds per person)

Same concept, same stakeholder role, same panel, same time limit. Score again on the same two questions.

In Person
Post the scores on a whiteboard
Write Round 1 scores in one column and Round 2 scores in another, per presenter. The visual comparison is more powerful than any debrief commentary you can provide. Let people look at it for a moment before you say anything.
The biggest jumps in Score B (why it matters to me) are your best debrief material. Ask those people specifically what changed in how they framed it.
Remote / Virtual
Use a shared doc or whiteboard tool
Have panel members drop their scores in the video call chat as each presenter finishes. Paste them into a visible shared doc or Miro board as you go. Aggregate and display the comparison before moving to Step 3.
If you have 8 or more participants in different time zones or with variable connection quality, consider async Round 1 via a short Loom recording, then live Round 2 for the structured version.
10 min
Set the Stage
framing + concept selection
35 min
Bridge Exercise
two rounds + scoring
15 min
Reflect Together
three structured questions
Total: 60 min  ·  For groups larger than 6, split into parallel teams of 4–6

Step 3: Reflect Together  15 min

The scores from Round 1 versus Round 2 are already doing most of the work. These three questions move participants from what they just observed about themselves to what they plan to do differently on Monday morning.

1
What changed between Round 1 and Round 2, and why did the framework help even with only two minutes of preparation?
Strong Answer Shows the key insight
"Round 1 answered the question I was comfortable answering: what this is. Round 2 answered the question the stakeholder was actually asking: why should I care and what do you need from me? The framework did not change the information; it changed the order. It forced me to start with their domain instead of mine. Non-technical stakeholders are not bad at understanding technical concepts. They are busy people who have no reason to engage with the details until the relevance has been established. The framework establishes relevance in the first two sentences, before they can tune out."
Common Misunderstanding What you might hear
"Round 2 was better because I simplified it. I left out a lot of the important technical detail."
How to respond
You did not lose the detail; you saved it for the questions. A stakeholder who understands why something matters will ask the follow-up questions that invite the detail. A stakeholder who is lost in the first 30 seconds will not. A 90-second bridge that earns a 10-minute follow-up conversation carries more total information than a 10-minute explanation that ends with a polite nod and no action. The goal is not to compress your knowledge. It is to clear the runway for it.
2
Name one specific stakeholder relationship in your current work where you feel chronically misunderstood or deprioritized. What is actually missing from that conversation?
What to listen for Signs the insight is landing
There is no wrong answer here, but there is a meaningful difference in specificity. A participant who says "my manager doesn't understand what we do" is not yet there. A participant who says "I've been trying to get the VP of Product to prioritize the authentication refactor for three sprints and she keeps moving it down the backlog" is ready to apply the framework in the next week. Push gently toward the concrete: who is the person, what is the concept, what happens every time you try to explain it. The more specific the situation, the more actionable the takeaway.
Common Pattern What often comes up
Most technical professionals identify a gap in step 3 of the framework: the ask. They explain what it is (step 1 is usually solid after this workshop). They often provide some context about stakes (step 2 is improving). But they rarely end with a specific decision or action. They present the situation and stop. The implicit ask is "please care about this," which is not an ask a stakeholder knows how to fulfill.
How to use this in the debrief
If this pattern surfaces, give the group a challenge: go back to the stakeholder relationship they named, identify the specific ask they have been leaving implicit, and write it down as one sentence before the day is over. A clear ask is often the only thing between a technical professional's expertise and organizational action on it.
3
If the decision-makers in your organization genuinely understood what your team does, what would be different about your day-to-day?
Strong Answer What this question is designed to surface
Better resourcing decisions. Faster approvals. More autonomy and less firefighting driven by uninformed direction from above. Fewer "can you just do it this way?" requests that require three days of rework. The specific answers will vary by role and organization, but the shape of the answer is always the same: technical professionals who are well understood operate with more leverage and less friction. This question makes that visible and makes the case that communication is not a polish layer on top of technical work, it is the mechanism by which technical work gets funding, trust, and room to do its job.
Common Misunderstanding What you might hear
"Not much, honestly. Good work eventually gets recognized."
How to respond
"Eventually" is doing a lot of work in that sentence. The most impactful technical professionals tend not to be the deepest experts in the room. They are the people who can make the experts' work legible to the people who control resources and direction. Work does not speak for itself. It gets filtered through whoever explains it most clearly. If that person is not you, someone else is shaping how your contribution is understood and valued. Recognition does not precede legibility. It follows it.
Your Challenge
Now do it for real.
Everyone in this room just explained their concept to someone playing a stakeholder role. That role is not fictional. Before the end of this week, find five minutes with the actual person your panelist was standing in for. Use your Round 2 version. Not a rehearsal this time. The outcome is real.
The practice only transfers when something is actually at stake.

A Note on Facilitation

You do not need to be a communication expert to run this workshop. You need to be willing to hold the structure and resist the temptation to fill silence. The most common mistake facilitators make in a session like this is over-coaching between rounds, giving people specific feedback on their Round 1 before the framework has a chance to do its work. Hold the debrief until Step 3.

The second most common mistake is softening the scoring. When panel members see low scores for someone they like, there is social pressure to bump them up. Brief the panel before Round 1: low scores are not criticism, they are data. A score of 2 on "I understood why this matters to me" means the exercise worked. The participant now knows exactly where the gap is, and Round 2 is the opportunity to close it.

The exercise is repeatable. Teams that run it once a quarter, using real current projects as the concepts, build the habit faster than any amount of reading about communication frameworks. The stakes are low in the workshop. The practice transfers to the conversations where the stakes are not.

Want to Go Deeper?

Pair this workshop with the Bridge career framework that underpins it, or extend the session by having teams practice with the same tech concepts they explain in your Tech CoLab game debrief.

Read: Be the Bridge Bring This to Your Team