Enterprise technology groups have a lot of responsibilities, but their primary mission is incident resolution. Incident resolution typically happens through the forward escalation process, but sometimes it is invoked in the reverse order. In this article, I will explore the pitfalls of this predicament, and offer some solutions.

Forward Escalation

This is the normal mode of incident resolution. The best-case scenario is a user that can achieve incident resolution via a self-service portal or a good knowledge-base. If not, then they engage the Service Desk. Most Service Desks are measured on first-contact resolution, so they make their best effort to resolve the issue, but if they cannot, they escalate to a more specialized group. If that group cannot resolve it, it goes to senior engineering. If they cannot resolve it, the senior engineers engage vendor support.

That’s the typical flow. Inherent in this flow is a funnel-effect. The majority of issues are resolved at the earlier stages, and are done so in the shortest amount of time and for the least expense. Escalations are time-consuming and expensive. They should be used sparingly for only the most complex issues. It’s also worth noting, that this entire escalation process can be executed without any management involvement.

Reverse Escalation

This unofficial process starts with management engagement. The point of engagement varies, but it is usually the highest-ranking IT manager, director, or CIO that the customer feels confident contacting. In this case, let’s say it’s the CIO. Then, the CIO contacts the manager or director mostly closely aligned to the function that is impacted. Then that manager or director feels the pressure of the CIO to act quickly, and finds the best and most senior engineer to put on the incident. That engineer might be the brightest, but may not be familiar with the common incidents, so he or she may reverse escalate to a support team to fix the actual issue.

Why does Reverse Escalation exist?

Reverse escalation is far from ideal, but it happens all the time for two primary reasons. The first reason it happens is because the forward escalation process has failed, or is anticipated to fail due to previous failed attempts. Based on that failure, the customer believes that management engagement is the quickest route to resolution.

The second reason is a personal preference for management by hierarchy. This is the traditional thinking that the way to get a group to do work, is to engage the leader. Then the leader will direct their people to do their jobs. Without direct command and control from the authority hierarchy, workers won’t be motivated to work.

The Problems with Reverse Escalation

For the engineers and support technicians involved, this feels like a bad game of UNO. Just when you think you have the right color or number, some director throws a reverse card then the manager throws a wild and you are left drawing four.

1. Reverse escalations are much more expensive than forward escalations for two reasons: First, it requires the use of management resources, and second, it involves the most expensive technical resources first, instead of last.
2. It illegitimizes the forward escalation process. Reverse escalation doesn’t work without management. Every time management engages because of urgency, partnership, or customer service, it undermines the legitimacy and authority of the forward process.
3. It stops strategic work. IT management should be spending time on strategic organizational work, not support. Senior Engineers should be spending most of their time on projects, enhancements, and upgrades and very little on support. Every time a reverse escalation is invoked, the entire IT organization becomes a little less proactive and strategic.
4. It’s archaic management. If you are trying to evolve your organization to be more self-directed, empowered, growth-minded, engaged, synergistic, and in every way a modern workplace that people love to join and grow, then reverse escalation is the antidote. It sends a clear message that command and control is alive and well.

The Solution to Reverse Escalation

1. First and foremost, you need an effective and efficient forward escalation process. If that needs some tuning, start there. If you have a “helpless desk” and tickets that are escalated go into “the black hole” never to be seen again, then work on that.
2. This is a leadership issue. Reverse escalation cannot thrive without complicit management. Every manager, director, and CIO needs to redirect to the forward escalation process.
3. Resist the urge to be responsive. Especially since I personally held various support roles, it’s still wired into me to be responsive to support requests. One thing that helps, is the fact that I’m in meetings most of the day. My work day isn’t structured to field real-time support issues. By not being responsive, it discourages future use of my role in reverse escalations.
4. Many of the reverse escalation candidates are high-severity incidents. Make sure high-severity incident management is integral to your forward escalation process with timely communication intervals.
5. IT managers, directors, and CIOs are the incident manager of last resort, not first. Make your forward escalation and incident management processes visible, easy to engage, and well-communicated.

This is a real IT leadership issue in every enterprise organization I’ve ever been a part of. You might be thinking to yourself, “guilty as charged!” Well, so am I. Let’s try to be a little more disciplined about this going forward. It might come across as tough love, but it’s necessary for the health of the entire enterprise, not just the technology group. Agree? Disagree? Please comment below.