Communicating Across Teams in High-Stakes Environments

A short, scenario-based Rise 360 course and one-page job aid that help field and operations staff recognize when to escalate an issue, choose a channel that matches its urgency, and confirm critical messages.

Independent portfolio project. Workplace scenarios, site references, and role-attributed quotations are illustrative, not actual employee testimonials. The course has not been implemented or evaluated by an employer.

Laptop showing the opening screen of the Communicating Across Teams Rise course

Try the course (about 10 to 15 minutes, estimated) or download the one-page job aid.

 

Project snapshot

Role: Sole designer and developer of the course and job aid

Audience (hypothetical): Field technicians, crew leads, and supervisors in operations-heavy work such as energy and utilities

Format: Self-paced Rise 360 microlearning, 5 lessons, about 10 to 15 minutes (estimated), plus a one-page job aid

Tools: Articulate Rise 360; Canva (visuals and job aid); ChatGPT (topic research and scenario development); Articulate AI image generation

Status: Self-initiated; not implemented or evaluated in a workplace

Inside the course

Four screens from the finished course: the opening scenario, the “say this, not that” flashcards, the escalation process, and the final knowledge check.

 

The challenge

In a high-stakes operational environment, an observation can become a larger problem when critical information is delayed, communicated vaguely, or sent through an inappropriate channel. A concern passed on as a casual heads-up, an instruction acknowledged without confirmation, or an urgent issue saved for the end-of-shift huddle can all lead to delays, rework, and avoidable safety risk.

I framed this project around a simulated workplace facing those risks. They are design assumptions, not problems measured at a real employer.

 

The performance need

Instead of a broad goal like “better communication”, I defined four workplace behaviours for the course to address:

  1. Recognize when an observation should be escalated

  2. Choose a channel that matches the urgency

  3. State critical information specifically: what is happening, why it matters, and what should happen next

  4. Confirm and follow up: repeat back critical instructions, and follow up after escalating

The course introduces all four. It gives the most practice to choosing a channel and deciding to escalate.

 

What training can and cannot fix

Training helps when people lack a skill. It does not fix a broken system. Communication failures often come from unclear roles, an undocumented escalation path, inconsistent supervisor responses, poor radio coverage, or a culture where raising concerns feels risky.

This project assumes an escalation process already exists and that the gap is applying it under pressure. In a real organization, I would test that assumption before designing anything, by asking:

  • Is the escalation protocol documented, and do workers know it?

  • Which incidents or near misses involved delayed or unclear communication?

  • Do supervisors respond to escalations consistently?

  • Do field conditions make real-time communication possible?

This is the analysis I would conduct for a real client. It was not part of this self-initiated project.

 

From business goal to learning objectives

Operational goal (hypothetical): Issues reach the right person in time to act, with fewer communication-related delays and less rework.

Workplace behaviour: Workers escalate concerns promptly, through an appropriate channel, in specific terms, and confirm critical instructions.

Learning objectives: Learners can identify common causes of communication breakdown, recognize closed-loop confirmation, choose a channel based on urgency, and choose an appropriate escalation response in a workplace scenario.

Evidence of learning: Knowledge checks and scenario-based decision questions in the course.

 

Key design decisions

Start with a failure, not a definition

The course opens at 7:15 a.m. on a remote site: an engineer reports a pressure anomaly, the foreman hears it as a heads-up, and operations halt hours later. Learners see communication as an operational risk before any rules appear.

Teach rules people can say out loud

Lesson 2 gives three rules: say the What, Why, and What Next; use closed-loop confirmation; be specific, not soft. “Say this, not that” flashcards show the exact wording difference, such as “Something seems weird with the system” versus “There’s a pressure spike, notify engineering.”

Practise decisions in context

Two scenario-based decision questions place learners in a workplace moment, possible overheating near a valve and an unexplained compressor vibration, and ask what they would do. Each is a single decision with feedback, which suits a short format better than a long simulation.

Keep each screen to one idea

Short text blocks, numbered rules, and a labelled graphic of five channels reduce reading load for people likely to take the course on a phone or between tasks.

Put the essentials on paper

The job aid repeats the escalation questions and four-step sequence, so the guidance is available outside the course.

 

Objectives, practice, and assessment

  • Identify causes of breakdown: an accordion of four causes, followed by a knowledge check (recall)

  • Recognize closed-loop confirmation: flashcards, followed by a question asking learners to pick the closed-loop response (recognition)

  • Choose a channel by urgency: a valve-overheating scenario and a final channel question (application and recall)

  • Respond to an escalation situation: a compressor-vibration scenario and a “reasons to escalate” question (application)

Practice is uneven, and I want to be clear about where. Learners see strong and weak messages but do not write their own, and the scenarios test the decision to escalate rather than the full four-step sequence.

 

Performance support

The one-page Quick Guide gives workers three questions for deciding whether to escalate, the same four-step escalation sequence taught in the course, and five communication tips. It is designed to print for a clipboard or save to a phone.

In a real rollout, I would add site-specific contacts, because “notify the right person” only works when people know who that is.

 

Proposed evaluation (not yet conducted)

This is the approach I would propose for a workplace implementation.

  • In the course: first-attempt accuracy on the two scenario questions, and the wrong answers learners choose most often

  • After training: supervisors review a sample of real escalations with a short checklist: Was the issue escalated? Through an appropriate channel? With a clear what, why, and next step?

  • Over 60 to 90 days: with operations, track indicators such as time from noticing an issue to escalating it, handoff completeness, and communication-related rework

Course results show understanding. Only workplace observation shows transfer, and any change in operational indicators would need a baseline or comparison group before it could be linked to the training.

Limitations and reflection

This project shows how I frame a performance problem, design around workplace decisions, and pair a short course with performance support. It does not show results: the course has not been tested with field workers or reviewed by an operations subject-matter expert.

The main trade-off was depth for brevity. A 10 to 15 minute course fits between tasks, but it limits how much practice learners get. With more scope, I would add message-writing practice, option-specific feedback on every question, alt text throughout, and expert review of the scenarios before any real use.

Interested in working together?

Whether you’re hiring a learning designer or developing a new learning experience, I’d love to hear what you’re working on.