We use our incident plan and communication escalation process enables the entire organization to understand actions/inactions to take when an incident occurs. Consider it like “tiers”, where when a specific tier is communicated to the team members, all appropriate departments know what actions to take/not take.
A contentious issue that undermines a critical attribute of our company’s brand and challenges its reputation. And/or an incident which impacts, or has the potential to impact the safety and wellbeing of our team-members.
When determining the need for communication escalation, it is important to first determine what the immediate issue is and determine what caused said issue. After collecting this information, review Tier 1-4 to determine the severity and subsequent action plan
A Tier 4 event is something we already have a process for like a security incident or a customer support request via Zendesk. In the case of a Tier 4, please follow the established company process.
A Tier 3 is a rapid response needed to address industry changes, competitive moves, news about the company, and other opportunities to provide comment/opinion or thought leadership. In the case of a Tier 3, please follow the Rapid Response directive.
A Tier 2 incident is a current issue, gray area communication or planned sensitive company communication that could lead to loss of customers, team members or market trust in the company. An incident has short term impact, but is high risk. Examples include; hiring policy, implementing unwelcome product changes, executive changes, being disingenuous to company values. If it meets the criteria for an incident, please initiate the below process.
A Tier 1 escalated incident is a significant reputational or financial risk to the company with long-term impacts. Industry examples include class-action lawsuits, highly public litigation (IP infringement or sexual harassment lawsuits), board removal of executives, etc. Please follow the Escalated Incident response team and process.
If a Tier 2 communication escalation arises, please use Slack or a text message to alert:
The head of corporate communications will propose a recommendation on how to best proceed with an external company message and recruit the resources to accomplish the plan (this becomes the #1 priority for each resource, unless physically impossible or their manager provides a replacement). A template for a Tier 2 communication escalation action plan can be found here.
The head of corporate communications will assess the request within 1 HOUR (6amPST-6pmPST). Urgency will be assessed and will be determined to be 3 HOURS (ASAP) or 24 HOURS turnaround, and the communication escalation action plan will be scoped accordingly - with a bias towards releasing an MVC as soon as possible, and iterating as more news becomes available.
While monitoring takes place on a regular (if not several times a day) basis across social channels from both the Developer Relations team and the social team, it’s particularly important to monitor channels on a more frequent basis during this time. There is a need to have many instigators (that may be different per channel) and it’s critical to try and understand this information in order to best evaluate the actions to be taken for communication escalation.
Social Listening could take place in the existing GitLab brand health monitor inside of Sprout Social. Because listening is always on (and Sprout backfills data, it is not an immediate need to set up a new topic.
Tier 2 incidents could either be addressed publicly without further interruption or be cause for a temporary pause on outbound organic social media from our brand channels. In either scenario, inbound responses (replying to folks directly rather than a new message from GitLab) should be included as part of the response. Generally, Developer Relations and support teams use canned messages for product service interruptions to communicate with customers and the community, especially if the incident is product or service-related.
When the incident is not caused by our product and is not service-related, the need to coordinate with support teams may not exist. However, working with the Developer Relations team helps to address core and niche social media channels.
To learn more about pausing social media / going dark during an incident, review the social media handbook.
The Community Operations Manager will work through existing frameworks for tiers 3 and 4. For a tier 2 incident, the director of Developer Relations and the community operations manager will be looped into the existing e-group led response.
For tier 2 incidents, the community team follows their responsible portions of the comms-reactive-tier-2-incident-checklist template.
Coordinating communication between people working on the communication escalation action plan.
All Slack channels related to the incident should contain a link to the issue and a link to the communication escalation action plan in their channel description
Open a new issue in the corporate marketing project using the comms-reactive-tier-2-incident-checklist template. Be sure to confirm that the issue is marked as confidential, as it pertains to work prior to releasing communications. Use the issue as our project center, assigning to-do’s and accomplishing tasks. Updates including links to external messages from the community should also be added as a comment in the issue, we should look to reduce the volume and locations of chatter on the topic into a singular location, since we will always need to corral several slack threads to the issue.
Our values guide our actions: our sense of urgency under Results and our value of not waiting under Iteration and RADCIE will under our value of Collaboration.
Where possible when dealing with an incident, we want team members to hear about it internally first. Depending on the incident though this may not be possible. However as soon as communication has happened externally we should aim to respond quickly internally - even if it's just to acknowledge we are aware/and are preparing a statement/ or looking into the details of the issue and will update team members as soon as we have more information.
Internal Communications Channel
Centering Communications on GitLab Values + Research - In “Incorporating Social Media in Risk Communication,” it’s recommended that we handle communication escalation through:
A number of these recommendations directly or indirectly align with GitLab’s Values.
Additionally, we need to be sure we:
Communications intended to alleviate the incident should be delivered to owned and earned channels alike.
Only addressing an incident in a blog post, and telling the community and the media to click a link may work, but that demands moving into our arena first. GitLab should be comfortable with hybrid communications - e.g. updates via blog, but turning the email into a threaded Tweet where the first tweet also includes a link to the blog. Other places to consider posting or adding a link include: GitLab forum, footer of Support and Sales emails, and Help Center docs.
In order to have maximum reach, we’ll need to consider alleviating the incident for the community at every possible step in their journey with GitLab communication (some folks would click the blog link right away, others would follow an issue comment - in both cases we captured a higher reach because we gave both options).
Make messages distinguishable from one another, depending on the audience. Consistency does not need to be homogenous.
The specific makeup of this mix will change depending on the incident.
It’s important to use listening (either a tool or manual research) to understand where the incident is emerging. More often than not, most incidents will originate on 1 to 3 channels (HackerNews, Twitter, Reddit, GitLab issue, news article, etc.), and it is entirely possible to manage the incident by communicating on these same channels only.
If an incident is not properly analyzed, GitLab runs the risk of over communicating and inviting the issue to be more severe.
At some point on managing an incident, planned external communication is to be thought of as our “last response” to our stakeholders and the greater GitLab community. This is identified when the company feels that we’ve addressed everything we can in the communication, we’ve taken ownership of any mistakes made, and we’ve committed to our stance.
Once we’ve identified this last communication, it is best to stop addressing the issue in the public square. No more broadcasts to stakeholders across any other channels. Always direct those with follow up questions to our last communication. In most “small” to “medium” incidents, the last communication may be our first communication.
We’ll know when the heat starts to die down naturally as our inboxes and notifications across channels begins to return to normal levels. However, we shouldn’t go by instinct only. In most cases, we should use a listening tool or review @mentions and non @mentions across channels to quantify the incident being over, e.g. determine that the volume of messages are decreasing and/or sentiment* returning to what we determine is a normal level.
*depending on the tool, sentiment analysis can be an inaccurate view of actual sentiment. In some cases, manual tweaking may be necessary to accurately capture.
Once we determine that the incident is over, move to reporting mode. Narrate the story of Why the incident happened, where and when it took place, who was affected by the incident initially and are there any long-term effects, Who was talking about the incident externally, what the team did, and How the incident was resolved and How we can prevent this from happening in the future.
It’s important to include data analysis and “the story” of stakeholders, community members, and GitLab team members. Neither the numbers nor “the story” express the entire picture. Use screenshots of positive and negative feedback from the community.
Optional: Deliver the retrospective issue to the entire team after feedback and updates are made, and invite all GitLab team members to a post mortem AMA to discuss more about the incident and invite an open Q&A. Always be sure to close this meeting with a link to the final talking points in the event GitLab team members need to answer this incident in their own conversations.
After retrospective is shared, archive designated incident Slack channels.
(Optional) Public Retrospective- In the case of a severe product- or service-related incident, publishing a summary of the communication escalation process should be considered. A summary of the incident in the days or weeks following could include scope, impact, timeline, root cause, resolution, and planned improvements.
As discussed when deciding which communication will be your last, it’s best to finalize your communications and end new talking points. We’re likely to still be asked about the incident even after it’s over.
It is important to stick to the final talking points and direct everyone to our last communication. If this is a blog, a tweet thread, or a moment in a YouTube video, we should be ready to direct those that ask.