Escalate Early, Escalate Often
One of the strongest moves a team has, and it only works if someone above makes it safe.

At AWS, one of the first things I learned was to escalate early, and often. It was just what you did, and nobody read it as a sign you had failed. I took it for granted. Working with organisations where escalation is treated as weakness showed me how much that one habit was doing.
Escalation is one of the most useful moves a team has. Raised early, a stuck problem goes to the level where it can actually be solved, before it grows into something you cannot walk back. Most of the time a problem is stuck for a reason nobody in the room can fix. Two teams want different things and neither can overrule the other. A decision needs authority nobody present has. A risk needs budget or people that only a higher level can free. Escalation puts the problem in front of the person who can act on it.
I have watched escalation matter most in the same few situations, over and over. Two teams blocked on a shared dependency, each with its own deadline, stuck for a week because the tradeoff needed a director they both reported to. An engineer who could see a capacity limit coming months out, but needed budget they did not control to fix it, and only got it once they raised it loudly enough. An on-call engineer partway through an incident who realised the problem was bigger than the people on the call, and needed both more hands and the authority to take a customer-facing action. In every case the person at the edge could see the problem clearly. What they did not have was the authority to fix it, and often the standing to make a call that big alone. That is what escalation is for. It moves the problem to where both of those exist.
The habit reminds me of something from car manufacturing. On a Toyota production line there is a cord that runs the length of the line, the andon cord. Any worker who spots a defect can pull it. Pulling it does not stop the whole factory. It calls a team leader over to help, and the line only stops if the problem cannot be sorted out inside the normal cycle. The idea is that a small problem gets attention early, from someone who can help, before it travels down the line and ends up inside a finished car. What makes it work is cultural. Pulling the cord is treated as the right thing to do, not as an admission that you failed, and it gets pulled often by design. Escalation is the same move. You pull it when something is wrong and you have run out of ways to fix it yourself, so the problem gets help before it spreads. And like the cord, it only works if pulling it is welcomed.
So escalation is powerful. It is also almost entirely conditional. The thing I missed for years is that “escalate early, often” was never really a rule for the person raising their hand. It was an obligation on the people above them. Escalating has to be safe, and only the people above can make it so. The moment it feels like failure, people wait. And waiting removes the whole value, because the point was to raise the problem while it was still small and cheap to fix. If people are afraid to escalate, the tool does not exist, whatever the process document says.
For escalation to work, the people above owe three things. They have to be reachable. They have to not punish the person who escalates. And they have to hold the authority the person escalating does not have. Miss any one of them and escalation stops happening, and nobody notices, because a problem that never gets raised looks exactly like no problem at all.
But none of that can rest on good intentions. Intentions do not survive a bad quarter or a busy week. That is the real lesson of the andon cord. Toyota did not make stopping the line safe by asking supervisors to be understanding. They built the safety into the mechanism. The cord is there, pulling it is expected, and the response is fixed. Escalation needs the same, a path people know, a response owed within a set time, and a norm that holds whether or not the manager is having a good day. Build the safety in, and you stop depending on the people at the top being reachable and kind on the worst day of the quarter, which is the day they will not be.
One tell is whether people escalate over each other or with each other. Escalating over someone means going above their head, and it lands as a complaint about them. Escalating with someone means you have hit a wall you cannot clear alone, so you take the problem up together. The second kind stays on the problem and the customer. The first turns into an argument about who is to blame.
Most organisations make escalation harder without meaning to. Some do it through a culture that expects people to arrive with the problem already solved, so raising something you cannot fix on your own reads as not being good enough, and people learn to sit on exactly the problems that most needed an early hand. Some do it by turning escalation into a political weapon, where taking an issue up the chain becomes a way to go after a rival team or a person, so everyone treats it as dangerous. Some do it more simply, by punishing the messenger. An engineer raises a real risk, gets labelled negative or not a team player, and the next risk stays unspoken. Each of these raises the cost of speaking up, and the higher that cost, the less escalation you get, until the only things that reach the top are the problems too big to hide. None of it is deliberate. It is the reward system showing what it actually values, which is usually not what the company says it values.
And the welcome has to be said, out loud, more than once. The organisations that get this right tell people plainly and often that escalation is wanted, and they prove it by how they react when it happens. Assuming people already know is the most common way to lose escalation without ever changing a policy. Everywhere else, the default assumption is that raising your hand is a risk, and that default wins unless someone keeps pushing against it.
So escalation is one of the most useful moves a team has, and the one most completely dependent on the people above it. The engineer at the edge can see the problem and raise their hand. Whether that hand gets met, or costs them, is decided much higher up. Make escalating early normal and safe, and problems reach you while they are still small. Do the opposite, and they reach you as outages, with a log that shows someone saw it coming and said nothing, because speaking up was the more dangerous choice.
//Adrian


