We have already covered how to detect trust issues on remote teams and the leader's playbook for building trust from scratch. This article is the tactical companion: 10 specific exercises you can run this week, ranked by the effort they require.
The research case for trust is overwhelming. Paul Zak's neuroscience studies found that compared with low-trust companies, high-trust companies see 76% more engagement, 50% higher productivity, and 40% less burnout (Harvard Business Review, 2017). Google's Project Aristotle, which analyzed over 250 attributes across 180 teams, found that psychological safety is the single most critical factor in team success (Psych Safety). BetterUp's research adds that workplace belonging drives a 56% increase in job performance and a 50% reduction in turnover risk (BetterUp).
The problem is not a lack of evidence for trust's importance. The problem is that most "trust exercises" are either too vague ("be vulnerable!"), too cringe-inducing (trust falls over Zoom), or too infrequent to build anything lasting.
Amy Edmondson's research on remote teams is direct: distributed work inhibits candor and psychological safety, so leaders need to "go overboard on structure" by systematically hearing from everyone and using names to make speaking up easier (UNSW Business Think). Structure is the key word. These 10 exercises provide it.
Each exercise is rated on three dimensions: Effort (how much time and preparation it requires), Team Size (where it works best), and Async Compatible (whether it works for distributed teams across time zones).
1. Vulnerability Loops: "What I Got Wrong This Week"
Effort: 5 minutes per standup | Team Size: 3-10 | Async: Yes (written variant)
Once per week during standup, each team member shares one thing they got wrong, changed their mind about, or struggled with. The format is simple: "This week I got wrong [X] and here is what I learned." The leader goes first. Every time.
This works because it creates what researchers call a "vulnerability loop." Zak's work on oxytocin shows that when one person models vulnerability, it triggers reciprocal trust in others (HBR). Edmondson's research confirms: the highest-performing nursing teams reported the most mistakes, because psychological safety let them talk about errors, which led to learning and improved outcomes (Edmondson, 1999).
Async version: A weekly Slack thread titled "What I got wrong this week" where team members post their own vulnerability shares. Leader posts first, every Monday morning.
2. Async Gratitude Channel
Effort: 2 minutes per post | Team Size: Any | Async: Yes
Create a dedicated Slack channel (name it something like #team-wins or #props) where team members post specific, behavior-based recognition of each other's contributions. The key is specificity. "Thanks to Jordan" is low-value. "Jordan's decision to refactor the retry logic before the launch saved us a production incident on Tuesday" gives the recognition weight.
Zak's research found that recognition has the largest effect on trust when it occurs immediately after a goal has been met, when it comes from peers, and when it is tangible, unexpected, personal, and public (HBR). An async gratitude channel checks every box except "unexpected," which you can solve by varying when and how you post.
This exercise also creates a passive trust artifact: new team members can scroll through the channel to see what the team values. It encodes culture in writing.
3. "What I Changed My Mind About"
Effort: 10 minutes per retro | Team Size: 4-12 | Async: Partially (written prompts work, but live discussion is better)
During retrospectives, add a standing prompt: "What did you change your mind about this sprint?" This surfaces intellectual humility, which Project Aristotle identified as a key characteristic of high-performing teams. Teams with high "social sensitivity" and equal conversational turn-taking outperformed teams composed of individual stars (LeaderFactor).
The question works because it normalizes changing positions based on new evidence. On engineering teams, where technical opinions can calcify into identity, this is particularly valuable. It decouples ego from architecture decisions.
4. Team User Manuals
Effort: 30-45 minutes to create, 5 minutes to reference | Team Size: Any | Async: Yes
Each team member writes a short document (one page) describing how they work best. Sections include: preferred communication channel, best time for deep work, how they prefer to receive feedback, what frustrates them, what motivates them, and how they signal they are stressed. Store these in a shared wiki or Notion page.
This exercise works because it makes implicit preferences explicit. On remote teams where you cannot read body language or observe someone's desk vibe, a user manual reduces the friction that comes from mismatched expectations. BetterUp's research found that employees who feel highly connected at work are 18 times more likely to be promoted and receive twice as many salary increases (BetterUp). Team user manuals are a low-cost way to increase that connection.
5. Failure Shares
Effort: 15-20 minutes per session | Team Size: 4-8 | Async: No (requires live discussion)
Monthly, one team member presents a failure in detail: what they were trying to do, what went wrong, what they learned, and what they would do differently. The format is a five-minute presentation followed by ten minutes of questions. No judgment. No "what you should have done." Just curiosity.
This is the deeper version of exercise #1. Where vulnerability loops are quick admissions, failure shares are structured stories. They build trust by demonstrating that the team treats failure as information, not ammunition. Edmondson's three habits of psychological safety map directly to this format: set the stage (the facilitator frames the session as learning), invite participation (questions from the team), and respond thoughtfully (curiosity over criticism) (NeuroLeadership Institute).
6. Paired Problem-Solving Across Teams
Effort: 1-2 hours per session | Team Size: Pairs from different teams | Async: No
Pair two engineers from different teams to solve a real problem together. Not a contrived exercise. An actual bug, a design challenge, or a scaling question from one of their codebases. The pairing lasts 60-90 minutes. The output is a shared solution or recommendation.
This exercise builds cross-team trust, which is often weaker than within-team trust. Research on quiet quitting found a 44% reduction in voluntary inter-team projects as disengagement spreads (IJRISS). Deliberate cross-team pairing fights that decay. It also creates informal knowledge transfer pathways that no documentation system can replace.
7. Structured Retrospective Formats
Effort: 45-60 minutes | Team Size: 4-12 | Async: Partially (written retros work but live is better)
Replace unstructured "what went well / what did not" retros with formats designed to surface trust dynamics. Three effective formats:
The Sailboat: Wind (what propelled us), Anchor (what slowed us), Rocks (hidden risks we avoided), Island (where we want to go). This metaphor externalizes problems, making it safer to raise them.
The Energy Check: Each person rates their energy level 1-5 and names one thing that added energy and one that drained it. This surfaces team health data that standard retros miss.
The Appreciation Round: Each person names one specific contribution from another team member that made a difference this sprint. This combines accountability with recognition. Zak's research shows recognition with both purpose and trust has a correlation of 0.77 with organizational joy and performance (HBR).
8. Cross-Team Shadowing
Effort: Half-day commitment | Team Size: Any (1:1 shadowing) | Async: No
An engineer shadows a colleague from a different team for half a day: attending their standups, sitting in on their meetings, observing their workflow. Afterward, the shadower writes a brief summary of what they learned about how the other team operates.
This exercise builds empathy across organizational boundaries. Remote teams in particular struggle with cross-team empathy because they lack the informal hallway interactions that surface context about other teams' challenges. 38% of remote workers report feeling isolated (PeopleManagingPeople.com). Shadowing creates a structured bridge that reduces that isolation. It also prevents the "us vs. them" narratives that erode inter-team trust.
9. Skip-Level Coffee Chats
Effort: 30 minutes per chat | Team Size: Any (1:1 format) | Async: No
Engineers have a casual 30-minute conversation with a leader two levels up from them. No agenda. No performance discussion. The only rule: the leader asks questions and listens. Topics can include what the engineer is working on, what they find interesting, what they wish were different, or what they are learning.
Skip-level chats build vertical trust, which is distinct from peer trust. When engineers feel that senior leadership sees them and listens to them, it reinforces that their contributions matter beyond their immediate team. This directly addresses one of the primary drivers of disengagement that Gallup identifies: employees feeling overlooked or unrecognized by the organization (Gallup, 2025).
Run these monthly. Rotate pairings. Track who has met with whom to avoid gaps.
10. Quest-Based Team Challenges (Always-On)
Effort: No facilitator needed (runs continuously) | Team Size: 4-12 | Async: Yes (built for distributed teams)
Every exercise above requires someone to plan, facilitate, or schedule it. That works for a while. Then the facilitator gets busy, the retro format goes stale, and the gratitude channel goes quiet. The pattern is predictable: manual processes decay.
QuestWorks, the flight simulator for team dynamics, runs continuously on its own cinematic, voice-controlled platform, generating trust-building interactions through scenario-based team quests. Each quest creates the exact conditions these other exercises try to manufacture: shared challenges that require communication, coordination, and mutual support.
The difference from the other nine exercises is sustainability. QuestWorks does not depend on a facilitator remembering to schedule a retro format or a manager modeling vulnerability in a Slack thread. It runs on its own, generating behavioral data with every quest. QuestDash shows team trends. HeroGPT provides private AI coaching that never shares upstream. HeroTypes make personality profiles visible to teammates.
Exercises 1 through 9 are excellent starting points. They are also manual. Exercise 10 is what happens when you want the trust-building to keep going without someone holding it together every week.
How to Choose
Start with effort level. If your team has never done any trust-building work, exercises 1 and 2 are the right entry points: low effort, high frequency, async compatible. If your team already has some psychological safety but you want to go deeper, exercises 3, 5, and 7 add structure to existing rituals. If you need cross-team trust, exercises 6 and 8 address the gap that within-team exercises miss.
The research is clear on one principle: frequency beats intensity. A five-minute vulnerability loop every week builds more trust than a half-day workshop every quarter. Google's Project Aristotle found that "social sensitivity" in high-performing teams was "fostered through greater time together, online or in-person" (Aristotle Performance). Time together does not have to mean hours. It means repeated interactions where people experience each other as human.
The trust deficit on remote teams is real. Global employee engagement is at 21%. Manager engagement dropped to 27%. The cost of that distrust is $8.9 trillion annually (Gallup, 2025). These exercises are not nice-to-haves. They are the mechanism by which teams move from a collection of individuals to a unit that trusts each other enough to do great work.
For a deeper implementation framework, see our guide to psychological safety training that sticks.
Try it free
