A good escalation path has four steps, each with a time limit: the two engineers talk, their tech leads decide, the build or platform owner rules, and a named executive breaks any tie. Most disputes should end at step one or two, and every step produces a written decision.
Why a ladder helps
Without a ladder, a version dispute drifts. Someone posts in chat, someone else reacts with an emoji, and a vulnerable transitive version stays in production because no one has authority to end the discussion. A ladder replaces that drift with a clock.
It also protects relationships. Escalation stops being a personal move ("I am going over your head") and becomes the next step in a process that everyone agreed to in advance.
The four steps
| Step | Who | Time limit | Output |
|---|---|---|---|
| 1. Direct talk | The engineers who raised and own the affected code | 2 business days | Agreement, or a written list of the open questions |
| 2. Lead decision | Tech leads of both teams | 3 business days | Decision with reasons, or a handoff to step 3 |
| 3. Build owner ruling | Owner of the root build, shared version list or platform | 3 business days | Binding decision for the affected builds |
| 4. Tie break | Named engineering executive, with security input | 5 business days | Final decision and, if needed, an exception with an end date |
The numbers are examples. Pick limits your org can meet and write them down. Short limits matter more than perfect ones.
What each step must bring
Each handoff should carry the same packet so nobody restarts the argument:
- The package, the current version and the target version.
- Which services use it, and at what depth in the tree.
- The reason for the change, such as an advisory with a fixed version.
- The risk of the change: patch, minor or major in Semantic Versioning terms, and test results so far.
- The options already considered, including leaving things as they are.
If a packet is incomplete, the person who receives it sends it back with a list of what is missing and the clock pauses once.
Rules that keep the ladder honest
- Skip steps for severity. A known exploited issue can go straight to step 3.
- Do not allow reopening a decided dispute without new facts, such as a new advisory or a failing test.
- Record exceptions with an expiry. An override that nobody revisits becomes permanent by accident.
- Let the person who raised the issue see the outcome. Silence breeds repeat tickets.
Measure it lightly
Track two numbers per quarter: how many disputes reached each step, and how long each took. If most reach step 4, your criteria are unclear. If most end at step 1, the ladder is working and you can relax the process for low risk bumps.
Quick check
Should every dependency bump go through the ladder?
No. Routine patch updates with passing tests should merge under normal review. The ladder is for disagreements, usually major version jumps, shared version lists, or overrides that affect more than one team.
Who writes the decision down?
The person making the decision at that step. A short record in the repository or ticket with the date, the reason and a review date is enough.
Last reviewed: 19 October 2026.
