Skip to main content

Escalate, Escalate, Escalate!


What is escalation at organizations? Is it a way to solve problems? Is it a way to report things? Is it a way to put more pressure? Is it a CYA technique? What is it? How do you use it at your organization? How other colleagues of yours use escalation? Really, think about it and observe.

At IT service companies, leadership measures the performance of IT Help Desk by number of escalated work items over a period of time. The less escalation the better. The reasons are simple:

  1. It is cheaper for companies if an IT Help Desk Specialist resolves an issue than an experienced technical specialist at one or two level higher. This is simple math, one gets $X and the other get $X*2
  2. And when client gets result fast, he/she will be happier. So, less escalation equals happier client in IT Services. Client raise an issue, IT Help Desk Specialist resolve it, BOOM, Next!


At organizations, It is amazing (sadly) to see how much lower level managers escalate problems, that they and their fellows can resolve without escalation  to more senior managers, these days. How much money is wasted?! Studies show that escalating a problem that can be resolved at lower level of organization will increase the cost and the duration of  the resolution time. So, why do you do this? either the organization has a lot of money to waste, or the senior manager has nothing do and has lots of time to waste? or this is again a CYA strategy. And yes, 90% is CYA by escalation.

The relationship issues and conflicts that happen because of escalation is even more expensive than the time senior management spends on investigating and resolving a problem that could be resolved by a lower level manager at the first place.


Here are 6 simple and common sense use of escalation:
  1. Escalate only, if you are not able to solve the problem on your own or at your level.
  2. Do not create artificial problems to exaggerate the main problem to justify your escalation.
  3. Do not blame when escalating, Simply concentrate on resolving the problem at hand and preventing it from happening again.
  4. As a senior manager, advise your directs to escalate less, unless your help is really needed.
  5. As senior manager, reward those who solve problems before informing you about the problem!
  6. Do not cover escalation by "informing" excuse. Sometimes, people escalate indirectly and they call it informing. But, in reality they do not have the courage to handle problems alone, therefore they escalate indirectly!


Post a Comment

Popular posts from this blog

DAD Inception Phase Workshop Agenda

Disciplined Agile Delivery (DAD) realised the reality of the projects and introduced back phases to Agile community. Whoever works in a project based company, especially a project based company where projects are usually less than one year in length and each are for different clients, understands the reality of Agile in such environment. When you start working on a new project for a new client, it is essential to go through a phase that you get to know each other better, to understand the business purpose of the project, to understand the scope of the project, to know what are the high level architecture and what technologies are going to be used and who is the initial team, and if funding is available and also when things must be delivered and to whom.
In answering these questions you may need to meet with different people, run couple of workshops and brainstorming sessions. And this is called Inception Phase. As DAD is more like a goal oriented decision framework and not a prescrip…

Collocation is not the silver bullet for success and agility

To collocate or not to collocate? Most companies that are new to agile have been "consulted" by a "Scrum" Agile Coach, who suggested that they must break their organisation and have cross-functional teams to sit together in one location. Is that the recipe for success?.. Is it really?

Even though collocation has its benefits, it is not the necessary condition for a successful delivery team. Collocation as a dogmatic view may hurt you more than you think, and will not necessarily help you to deliver more successful products.

I am neither for nor against collocation, but I have experienced and worked with both approaches. And each sometimes worked very well and sometimes failed. All the variations of teams geolocation (collocated, fully-dispersed, partially-dispersed, or distributed) can work. It all depends on how the collaboration model is setup, what is the context and conditions, and how much the team and organisation are aware of each other, and are aligned.

Ha…