Why Talk Incident Management with Non-Engineers
Incidents aren’t just for engineers. When there’s a SEV 1 or 2, you can be sure that not only are customers impacted, but other departments are as well. Consequently, if your organization isn’t properly integrated and trained on your incident management process, you’ll be sure to have contentious relationships.
Learning how to talk about incidents, the response process, and agree on communication with non-engineers will help your entire organization keep everyone on the same page when things go haywire.
When To Talk Incident Management with Non-Engineers
Non-engineers can often get in the way of incidents if they aren’t adequately trained or don’t have a process to manage incidents across different teams. Customer support or customer success teams will likely be heavily involved with reporting and following up on incidents that impact end-users. Without proper training, interference and miscommunication with the engineers trying to resolve the incident are inevitable. No one needs additional stress during an incident.
Here are some common examples of non-engineering support that may be required during an incident:
Supporting the communication process during an incident, such as alerting C-suite executives or following up afterward with customers.
Sharing feedback to help improve processes by participating in incident retrospectives.
Provide necessary resources for the on-call response team to resolve the incident(s) and proactively address future incidents.
How To Talk Incident Management with Non-Engineers
The first step to improve non-engineer communication is identifying who needs incident training. Make a list of often impacted teams and key stakeholders that you will need to train on the incident process. These can include:
Customer Success (CS) or Support teams
Sales and account management teams
Marketing and public relations teams
Once you’ve identified the appropriate teams, you will need to train, prepare your incident management communication with your actual process in mind. It’s important to remember that not everyone has a technical background in your organization, so keep communication clear, concise, and straightforward.
A great place to start is thinking about the different severity tiers, the impact on each team and customers, and how your team should respond. In many instances, outside team members need to be notified at specific intervals about what’s going on. They need to understand what your incident response team is working on so they know either how to help or how to stay out of the way.
It’s also crucial that your customer-facing teams are trained to know when and how to properly communicate externally. You may have SLAs in place with customers that require frequent check-ins. To meet those SLAs, your CS should have a protocol built into the incident management process to receive information from the responders and share it with impacted customers. If an issue is highly technical, it may require a dedicated responder to be available to answer complicated questions.
Maintaining clear communication
During an incident retrospective, you should always check in on how information was shared. If you noticed that some teams or members were hindering others from responding, it’s a good idea to work with them to make sure everyone is on the same page.
It’s vital to keep the customer in mind when reviewing the incident’s impact to ensure that information flows beyond the on-call team. Most customers will not interact with an engineering team but will interact with their account managers, customer success managers, and public-facing assets that the marketing team promotes. Ensuring that all of these stakeholders understand incidents and the customer impact will help keep any “damage” at a minimum. Regular evaluation, such as during retrospectives, and training, such as during game days, will keep your process strong outside of the engineering organization.