Escalation Policy at Syndicode

The escalation policy tells you whom to apply in case of a particular issue. Escalation policy is made up of levels that allow you to escalate incident notifications to different users and/or on-call schedules in the case that no one responds. There are three levels of escalation policy in Syndicode: PM (project manager), team lead or developer, CEO. Let’s get down to details and examples.

What Is the Escalation Policy?

The escalation appears in case of the major incident that couldn’t be solved within a determined amount of time. When it happens, it should be customized who will receive the alert, as well as the amount of time needed to wait before escalating to the next users.

The alert can be sent out by a fellow team member or some monitoring tool connected to the endpoints and being monitored. In this case, the critical issues will not be missed and the escalation will solve the problem.

Every team and company has its fail-over policies and easily automates the alert process and can reduce the possibility of human mistakes. As you know about Syndicode’s communication policies, we obviously have our own escalation policy too.

Escalation Levels

Escalation policies have several levels that ensure that if there will be no responses, escalation of incident notifications will be sent to different users. It’s necessary to have at least two levels, but the more options the company has, the better.

With the help of multi-user notifications, you can notify multiple users at once. There are three methods of configuring multi-user notifications:

• Sending notifications to multiple users at once regardless of their on-call status.
• Sending notifications to multiple users and groups at once based on a specific span of time.
• Sending notifications to a secondary on-call user when a primary on-call user does not respond.

Escalation Policy Examples

Let’s dig into some of the escalation policy examples to understand their mission better:

• Example 1: Let’s imagine there is a service that has a 50% outage for an hour, but we don’t know the reason. The problem is also that this service has exceeded its 7-day and 30-day error budgets. In this case, the escalation policy will deal with the production’s impact. The developers may need new metrics for the investigation of the problem, use fallback alerting. It can take a week to research the issue. If the root is still unknown, the outage needs to pass out the 30-day SLO measurement window. By the end of the investigation, the teams should be confident that there will be no recurrence of the problem.
• Example 2: Binary releases are the roots of transient error spikes. This problem can happen on a daily or weekly release. The escalation process can start with notifications of SREs, and the issue shouldn’t be resolved when SLI returns to normal.

Some escalation policies could be made online using already existing templates. With their help, it’s easier to make sure that required people are notified at the right time.

The incident notifications will be configured to escalate to users, squads or schedules in the order and time you select. You can also create different escalation policies for different services.

Escalation Policy Best Practices

In the case of the escalation policies, the project manager needs to ensure that the necessary analysis was done. Here are some best practices that we recommend to use for better project escalation:

• The escalation matrix as well as all escalation levels and areas, have to be completely defined and documented at the beginning of the project.
• The project stakeholders should be aware of the whole escalation process.
• The escalation process should be done on time by all responsible without any fear or hesitation.
• All data points should be analyzed thoroughly to make sure everything was done properly before the escalation.
• No actions have to be done while you are waiting for the response of Service Level Agreements (SLAs).
• The frequent and unnecessary escalation should be avoided.
• The focus should be on the specific escalation issue before moving to another problem.
• Only the right stakeholders should be involved in the escalation process.
• The issue should be on the focus of attention, no other personal emotions should interfere in this matter.
• While escalating all needed background and correct data should be given.
• All data points and necessary actions should be documented properly during the escalation process.
• Depending on the severity, two levels up should be involved in the escalation.
• Research the previous similar escalation situations to learn.
• If the first escalation fails, continue escalating it to the next level.
• In case when vertical escalation does not work, try horizontal, indirect or innovative methods, and any other until you the issue is resolved.
• Don’t be afraid of the stong measures if needed.

Project escalation can be risky but understanding which project situations need escalation and escalate these issues professionally to the right people is key to the project’s success.

Escalation Policy at Syndicode

The escalation policy in Syndicode usually is done in the following way:

Initially, the client always turns to the project manager, and if the manager cannot answer the question or solve it, then the developer and CEO are involved in the discussion.

The actions of the PM in this case:

• To specify any kind of information regarding the project.
• To provide any kind of information regarding the project.
• A complaint about some issues (budget overruns, failure to meet deadlines).

The actions of the developer in this case:

• Technical questions that the project manager cannot answer

Usually, the CEO is needed rarely when everything is fine. But sometimes the client can address his concerns in the hope that the CEO will be able to somehow influence the situation and fix it.

Escalation Matrix at Syndicode

Time to response

• CEO
  Must respond within 2 business days about the current status of the project and provide general project information
• Key account manager
  Must respond within 4 business hours about the current project status and the Invoice status
• PM
  Must respond within 4 business hours about the current status of the sprint, efforts required to finish it and the delivery date of the sprint
• Engineer
  Must respond within 2 business hours about the current task he works on and if he has any blocks

From our experience, we can say that it’s important to document any kind of escalation policy with possible scenarios. It will help to be prepared for unexpected cases. We choose draft policies wisely and expect to have a discussion. Understanding the right use of the escalation technique is important and this process should be treated professionally and with high effectiveness.