Encouraging escalations in engineering organizations

Humans are social beings. They dislike conflicts and try their best to avoid conflicting situations. It is due to this innate nature that companies start forming silos as organizations become larger. It is easier to do your thing than having to resolve a conflict with an overlapping team.

If you want your organizations to succeed, you should help make this process easier and non emotional. Here is exactly how to go about it.

Blend it into the culture

Escalation should be encouraged and should be a really light weight process and encouraged.

Don’t like food in the cafeteria? talk to the cafeteria manager. If they say that they cannot do much beyond this due to budget, go ahead and use an escalation template. It does sound silly to be ‘escalating’ this. Here is the point, when you can train your muscles on simple non consequential things, you get better at it. The goal is to blend it into the culture.

The escalation process

Escalation is not a complain but a request for improvement. Providing a framework to do this is critical. An escalation doc should be a standard doc. Every person in the company gets to a maximum of one escalation one per quarter.

Here is a template:

• Suggestion by:
• Suggestion:
• Thoughts from Impacted Party 1:
• Thoughts from Impacted Party 2:
• Escalated to:

If someone receives an escalation, they can respond to it within two weeks. Once thoughts from all parties have been collected, it should be sent to the skip of all parties involved. Two week after, all parties should hear back a response from their skips via an email or meeting. There will obviously be more discussions between everyone involved until the decision is made. If the person suggesting is not happy with the response, they can always escalate it back next quarter with more data to back their suggestion.

Sounds too drastic? I have not tried this out, but in an ideal happy world, I want to give this a try. If you have tried a version of this, let me know.