So you want to be a Communication Commander? You've come to the right place!

Purpose#

The purpose of the Communication Commander is to be the primary individual in charge of notifying our users and community of the current conditions, and informing the Incident Commander of any relevant feedback from users as the incident progresses.

It's important for the rest of the command staff to be able to focus on the problem at hand, rather than worrying about crafting messages to users and partners.

Your job as Communication Commander is to listen to the call, watch the incident Slack channel, and track incoming user reports from community channels (Discord, Telegram, X/Twitter, etc.), keeping track of what's going on and how far the incident is progressing (still investigating vs. close to resolution). The Incident Commander will instruct you to notify users of the incident and keep them updated at various points throughout the call. You will be required to craft the message, gain approval from the IC, and then disseminate that message publicly.

Prerequisites#

Before you can be a Communication Commander, it is expected that you meet the following criteria. Don't worry if you don't meet them all yet, you can still continue with training!

  • Excellent verbal and written communication skills.
  • Be a member of the Marketing / Communications team, or have experience with public-facing communications.

Responsibilities#

Read up on our Different Roles for Incidents to see what is expected from a Communication Commander, as well as what we expect from the other roles you'll be interacting with.

Training Process#

There is no formal training process for this role. You should familiarize yourself with our External Communication Guidelines and review past incident communications.

Communication Commander#

The objective of a Communication Commander is to keep our users and community informed during an incident as to what is happening, and to act as a voice for our users to the Incident Commander. It is important for users to have visibility into how they are impacted by an incident, and to have insight into the fact that the problem is actively being worked on. Crafting a public message is tricky, especially on platforms where the number of characters you can use is limited. But here are some general tips for crafting a public message:

  • Prepare a default message in advance.
    • One that can be used for the initial update if the scope of the issue is unknown.
  • Be honest.
    • Never lie, and never guess. Work with the Incident Commander if you are unsure as to what is actually happening.
    • Provide transparent information to users. If we are dropping the ball, be upfront about it.
  • Describe our progress in resolving the incident.
    • "We are aware of an incident..."
    • "We are investigating degraded performance on..."
    • "A fix has been applied and is currently being deployed..."
    • "The issue has been resolved..."
  • Be clear about how the incident is affecting users. This is the primary piece of information users will care about.
    • Are transactions failing? Is the bridge delayed? Are RPC endpoints responding slowly but still working?
  • Provide any workarounds users can use until the incident is resolved.
  • Don't estimate resolution times.
    • Never say something like "We expect this incident to be resolved in 10 minutes". Something else could happen, and users get angry when you set an expectation you can't keep.
  • Don't provide too much detail.
    • Users don't care if validator-node-123 is having issues — they care that their transactions are failing. Make sure the information you provide is relevant and not just noise.

Incident Call Procedures and Lingo#

The Steps for Communication Commander provide a detailed description of what you should be doing during an incident.

Here are some examples of phrases and patterns you should use during incident calls.

Gaining Message Approval#

After you have crafted the public message, you should gain approval from the IC before posting it publicly. Simply copy the message into Slack and wait for verbal/written confirmation from the IC before proceeding.

(You) Message for users: "We are currently experiencing degraded RPC performance on PoS Mainnet and are actively investigating the issue."

(IC): Looks good, go ahead and post.

It's important to get sign-off from the IC before posting as the nature of the incident may have changed while you were crafting the message, and new information might now be known and need to be included.

Notification of User Response#

You may be receiving reports from users in Discord, Telegram, and other community channels during the incident. This provides useful context for the Incident Commander, as it gives an indication of the scope of the incident. You should keep the IC apprised of any relevant information from users.

We've had multiple users in Discord report that bridge withdrawals have been stuck for the last 20 minutes.

This can provide the IC with information which affects which areas we investigate first, or an indication of how the incident is progressing.