Escalation manifesto

💡 Our guide to get the right people together, and empower them to make difficult decisions faster in a bottom-up culture.

Escalation, a practice for the intellectually humble

We consider escalation a manifestation of a key cultural trait: intellectual humility. It is because we understand our limitations, that we escalate when we need help resolving an unexpected challenge. It is also because we have an innate builder attitude that we want to hold ourselves accountable & responsible for those final decisions. As a result, escalations become a necessary tool that is used early, often & explicitly.

At Tech, we promote escalations to happen whenever the issue at hand cannot be resolved by the involved individuals and a serious trade-off is needed. Hence, the individuals sought during an escalation, welcome the opportunity to intercede and collaborate beyond their current scope. It means their skills are required and no-one in that current group feels comfortable driving the decision.

Interestingly enough, not only should you frequently escalate looking for more senior individuals in an area, but we also consider it a clear sign of seniority for those that know what, how and when to escalate.

Are you delayed, surprised or blocked?

🫵🏽 It’s not on you, but you are your only hope.
Since we know you will need help while delivering autonomously, being autonomous means we trust you to know when to escalate.

We escalate,

• As soon as we foresee a potential delay
  You want the right people to be aware of potential tardiness so that they can either help accelerate or communicate accordingly.
  This is the main reason why we escalate (usually after waiting a reasonable time). We have several SLAs defined for different activities that allow us to know when to escalate. For example, we have a 48hrs start-to-finish rule for any design document, so comments are expected to be replied in a couple hours, not days. In general, clear pre-arranged ETAs for activities is essential to ensure escalations are no surprises.
• When unforeseen circumstances happen
  We’ve all been there. The reasons are many, e.g. either because we missed a now “obvious” requirement, we didn’t identify a key dependency, or simply, because all software changes [Check “No Silver Bullet” on software Changeability]. Although most of the time we are able to resolve those challenges swiftly, it’s important to at least give visibility to the organization so we can learn from them.

“Do you have any idea what a curse it is to have perfect 20/20 hindsight? As soon as something bad happens, I immediately know how it could have been avoided. I can’t take it anymore!” — Captain Hindsight.

• When you are overwhelmed
  The above was centered on how other foreign elements could affect your project. However, there’s one thing that could also result in a need for escalation: work paralysis. How many times have you found yourself going again and again over your list of tasks without being able to move forward on any? That is usually coupled with the feeling of lack of understanding of where to start. This is the right moment and time to escalate. You have exhausted almost all reasonable alternatives, you need help!
  Hopefully you can quickly navigate this difficult moment together with your manager, tech lead or a more senior team member.

Early, often and explicitly

❤️‍🔥 In a remote set up, escalation is fundamental
Your co-workers don’t notice you are blocked, or waiting, unless you promptly voice your concerns. Thus, this skill must be mastered very early in your career.

Often we avoid bothering colleagues assuming they are busy with their day-to-day. In fact, we perceive that those who can help us usually complain it takes away their focus. As a result, we try to wait until our next daily, 1<>1, weekly catch-up, etc…

Waiting times compound, ask for help early on!
Given the team you need help from takes 1 hour to reply to your emails, and you probably wait for an extra hour before sending a response, and email thread trying to resolve an issue could take a day easily. Now you are at least a day delayed. Generally speaking, if you wait X and the other person waits Y, each communication flow would add X+Y in each direction. You can see how you need to aim to shorten these cycles as much as possible.

For that reason, we strive to communicate promptly and escalate even earlier to resolve challenges. Whenever you are delayed, you should be able to ‘start a mental counter’, until escalation happens. And the steps through that escalation path should be aim to accelerate the feedback cycle each time.

For example, to accelerate the feedback cycle at Tech, we follow this rule for tickets:

(i) ticket → (ii) group message → (iii) direct message → (iv) video-call

We have reasonable ETAs for each and it includes checking the working hours, as we are globally remote.

Escalating often means you are giving visibility
You are trusted to be autonomous, this means when you face a challenge you are expected to raise awareness on your own. The other person can always share context with you on why this is not relevant for them at a given point in time. However, they won’t be able to do so unless you escalated first.

We know there is a balance here to strike, as a result, part of our onboarding focuses on our communication style.

Be explicit!

When escalating, the new individual/s involved should be able to quickly internalize, and gain a clear understanding on what you expect they will provide to this challenge. Hence, they need to understand (a) this is an escalation, (b) required context, and (c) your expected outcome & timeline.

To be able to communicate efficiently we suggest to be extremely concise when preemptively answering the following four (4) questions in any escalation message:

Why is this important to the person/team I’m escalating to?
Be crystal clear of the impact for them, and the company. This should be your first line in your email/message as it defines the urgency and importance for anyone else. For example: this will delay project X 2 weeks if not looked upon, and project X is our top team priority.

What are the relevant details of the challenge?
Summarize all relevant context for the current issue, aiming to reduce unnecessary back-and-forth.

What have you tried?
If you already tried something or you have any suggestions on how to proceed, you need to specify it here together with the trade-offs you need help with.

What do you need?
Explicitly say what is your expected outcome, from whom and by when.

Thanks for reading through our escalation manifesto 3.0!

Escalation has become a key tool for our ever growing team in the past year, and we have had multiple conversations across the whole org in this regard. Escalation is regarded nowadays as a great example on how our remote teams differ from collocated/hybrid teams, a cultural staple, one skill that is mandatory for all from day one, and a ‘must’ as we become a top tech team world-wide.