Launch Day 🚀

This stage looks simple on the surface: a 60-minute meeting, one email, one switch. The simplicity is the trap. The decisions that make Launch Day work — hard switch vs. gradual, who sends the email, which workflows are in scope — were made by the time the room fills. By the time you're standing in front of the team, you're not deciding; you're announcing.

---

In this document

What happens at this stage

The hard switch

The Launch Day meeting

What to prepare before this stage

Avoid this if you don't want your transformation to fail or delay

What you get with the full protocol

---

1️⃣ What happens at this stage

This stage is the day your organisation switches. Three pieces have to land together — and they have to land in this order:

• The Launch Day meeting — a 60-minute working session with all project participants in one room: Sponsor, Guardian, Change Alliance, and the team that will operate in the system. Run by the Guardian, opened by the Sponsor.
• The company-wide announcement email — sent within hours of the meeting, under the Sponsor's name (not the Guardian's, not Remote Sensei's), giving the switch the institutional weight it needs.
• The hard switch itself — the operational line that says "for these workflows, the old channels are no longer valid; the system is where work happens now."

The meeting is where the team gets to ask questions in real time. The email is where the switch becomes a written, archive-able decision the team can re-read in week two when memory fades. The hard switch is what those two artifacts protect.

Note on naming (Guardian, Change Alliance) — click to reveal

You were formally appointed Guardian at the

Kick-off 🏈 stage; the Change Alliance was named at the Change Alliance 👥 stage; the team trained at the Training 🧑‍🏫 stage.

This stage is where everything you've prepared meets the live team in one room, on one day.

---

2️⃣ The hard switch

The decision that makes Stage 10 work — or quietly unmakes it — is whether the switch is hard or gradual.

A hard switch says: from Launch Day onward, the onboarded workflows live in the new system. Period. The old channels are explicitly retired for those workflows. Email still exists for emails. Slack still exists for chat. But "where is the status of this project?" has exactly one answer.

A gradual rollover says: we'll use both for a while; people can choose. This sounds humane. It almost always fails. Teams default to the channel of least friction — the one they already know. Three weeks in, adoption is patchy, the conventions decay, and the project quietly slides back to email while the workspace sits half-populated.

Why hard beats gradual: people don't change behaviour because the new way is better. They change because the old way isn't an option anymore. The hard switch creates that scarcity. Gradual rollover preserves the escape hatch — and the escape hatch is the thing that kills the transformation.

---

3️⃣ The Launch Day meeting

60 minutes. All project participants in one room — Sponsor, Guardian, Change Alliance (Convention Setter, Workflow Guardian, Awareness-Builder), and every team member who will operate in the system. Run by the Guardian. The meeting has five blocks — each is a teaser, the full agenda with timings and facilitator cues is in the toolkit:

• Reminder: why we're doing this — revisit the starting point named at the Discovering problems worth solving 🔬 stage. The communication gaps, the status-visibility problem, the workflow complexity. Ask the team: does this still reflect our situation? Have the goals or success metrics shifted? Re-anchor the why before introducing the how.
• Workspace inventory — walk the team through the teams, templates, and projects that now exist in the workspace. This is where you find what's mis-named, mis-scoped, or duplicated. Schedule a focused clean-up afterward if needed — don't try to fix it in the room.
• Conventions and expectations — emphasise what the new system is now replacing (from the Work Conventions 🤝 stage). Make the hard switch explicit. Reference the Tooling Landscape from the Audit 🔍 stage if helpful — don't rebuild it, point at it.
• Important use cases — walk through one or two concrete workflows or meeting agendas where the team will feel immediate value. This is where doubt converts.
• Resources and support — point the team to the conventions project, the questions-for-RS project (if you're working with a partner) or the internal equivalent, the training recordings, and the Slite knowledge base.

The closing move: the Guardian sends the company-wide announcement email within hours of the meeting, while the room is still warm and the questions are still fresh.

---

4️⃣ What to prepare before this stage

• The Training 🧑‍🏫 stage complete — three training tracks delivered, the License to Operate Quality Gate cleared, the Guardian debriefing held. Any blockers the Gate surfaced are resolved before Launch Day, not after.
• Workspace finalised — projects exist, conventions documented, mapped workflows live. No "we'll fix it after Launch Day" debt in the workspace.
• Sponsor confirmed and prepped — they're attending, opening the meeting for ~90 seconds, and sending (or co-signing) the announcement email under their name. The Guardian briefs them on the hard switch language so they don't ad-lib a softer version in the room.
• Hard switch decision documented — which workflows switch, from what channels, on which date. Aligned between Guardian and Sponsor before the meeting; no surprises in the room.
• Personal Onboarding Project assigned — each team member has it queued in My Tasks. The announcement email reminds them to start it.
• Announcement email drafted, placeholders filled — the why, the timeline, the conventions link, the recordings link, the support channel, the Consolidation phase framing.
• Resource links live and ready to share — Work Conventions project, questions-for-RS project (or internal equivalent), training recordings, knowledge base.
• First weekly check-in scheduled — recurring meeting with the Guardian to monitor week-one signals and run the Onboarding 👋 stage adjustments.

---

5️⃣ Avoid this if you don't want your transformation to fail or delay

‼️ Don't switch gradually. "We'll use both for a while" is the most common reason transformations stall at this stage. Gradual rollover preserves the escape hatch; the escape hatch kills the change. Pick the hard switch.

‼️ Don't send the announcement from the Guardian. Without the Sponsor's name on it, the email reads as "another internal initiative the operations team is pushing," and the team waits to see if it sticks. The Sponsor's name is the institutional signal that says this is the decision, not a proposal.

‼️ Don't skip the meeting in favour of "just send the email and the recordings." The meeting is where commitment becomes public and questions get asked in real time. The email is the archive. You need both — the email without the meeting reads as a directive nobody quite understands; the meeting without the email reads as a discussion nobody has to honour.

‼️ Don't include workflows that aren't ready. A half-mapped workflow on Launch Day undoes the trust you built across Stage Implementation Plan 🗺️ – Training 🧑‍🏫. The team will generalise from the one broken thing to "the whole system is broken."

‼️ Don't let the announcement go out without naming the support channel. If there's no clearly named first point of contact — Change Leader internally, or RS coach if you're partnered — the team works around the gaps in week one, and "working around the system" becomes the new convention.

‼️ Don't conflate Launch Day with a workshops product. If you ran the lighter Asana Workshops offering (a different RS product, two sessions in a week), there's a separate, lighter-touch announcement email for that flow. The full Reliability Protocol's Launch Day — described on this page — is the meeting + executive announcement + hard line.

‼️ Don't disappear after Launch Day. Week one is when the team's instinct is still to fall back into email. The Guardian holds the line by redirecting every off-platform request back to the system, every time, for the first two weeks. That redirection is what the Consolidation of changes 🌳 stage protects.

---

✅ What you get with the full protocol

The full Reliability Protocol is delivered as one weekly action by email — you receive one stage at a time, with one implementable artifact, and one clear next step you (or your Guardian) can act on that week. The artifacts you get for this stage:

• The Launch Day Meeting Agenda — minute-by-minute 60-minute structure with facilitator cues, the five-block sequence (Why / Inventory / Conventions / Use cases / Resources), the Sponsor's 90-second opener script, and the closing move that hands off to the announcement email.
• The Company-Wide Announcement Email Template — drop-in template for the Sponsor with placeholders for the why-statement, the timeline, the Personal Onboarding Project assignment, the two-to-three-week Consolidation framing, the support layers, and the weekly check-in pattern.
• The Launch Day Slide Deck — editable Miro/PDF template you customise for your organisation, with a Loom walkthrough showing how to adapt it for your team's specific workflows and language.
• The Personal Onboarding Project (CSV) — importable Asana project with a per-team-member onboarding checklist. One CSV becomes "MASTER — Onboarding Template" once imported, then gets duplicated per team member and assigned.
• The Resource Bundle — pre-formatted links to your Work Conventions project, the questions-for-RS project structure, the training recordings, and the Slite knowledge base your team can reference from Day One.
• The Sponsor Briefing — what to say in the 90-second meeting opener, how to write the announcement so it carries executive weight without sounding corporate, and the three questions the Sponsor should be ready to answer in the room.

💬 Take this with you and your team can run Launch Day yourselves. Hit a wall on the hard switch decision, the meeting facilitation, or holding the line in week one — book the session below.

When to bring in a partner

The package above is the framework, the templates, and the meeting structure. Most operators run Launch Day themselves once the first nine stages are durable. Bring in a partner when:

• The Sponsor is wavering on the hard switch and you need someone with cross-industry data to make the case in the room — the gradual-rollover failure pattern is easier to defend against when an outside voice names it.
• You haven't run a full-room transition meeting before and want a neutral facilitator handling the energy, the questions, and the timing while you focus on the workflow-specific answers only you can give.
• You expect week-one and week-two adoption to wobble — partner support during the Consolidation window at the Consolidation of changes 🌳 stage is the highest-leverage purchase of the whole Protocol, because conventions decay fast in the first two weeks if nobody is actively redirecting drift back to the system.

💡 This is Stage 10 of the Reliability Protocol — Remote Sensei's 15-stage system for permanent organisational transformation, and the global standard for Asana implementation: making Asana and AI stick in mid-size and enterprise teams so work ships on time without anyone chasing it.

➡️ How it works · ➡️ Client results