BE Teck Notes Back to be-teck.com

5 min read

Escalation without shame

Most escalation systems require somebody to name a colleague. That is why they go unused, and why problems reach management only after they are unfixable.

Every organisation has a process for raising a problem upward. Very few of them are used at the moment they would be useful.

The reason is rarely written down: escalating means naming somebody. To report that a task is stuck, you have to say who it is stuck with. To report that material has not arrived, you name the person who was buying it. And the person you are naming will be at lunch with you tomorrow.

So people wait. They wait until the problem is large enough that raising it is clearly justified, which is usually after the point at which it could have been fixed cheaply.

What the delay costs#

Not the escalation itself. The window.

Almost everything on a construction project is fixable if you know about it a week early and expensive if you know about it a week late. A material that has not been ordered can be ordered. A drawing that has not arrived can be chased. An approval that has not moved can be pushed. The same three problems, found after the crew is standing idle, cost their delay plus everything downstream.

An escalation system that reliably fires two weeks late has not reduced the number of problems. It has removed the only period in which they were cheap.

Design so nobody has to accuse anybody#

The move that changes behaviour is to make the system, rather than a person, be the one that notices.

Concretely, that means surfacing conditions rather than reports:

  • Work that has slipped its date more than once.
  • A task waiting on the same thing for longer than similar tasks usually wait.
  • An approval sitting unactioned past the point where approvals normally move.
  • A payment stage past its date.
  • A delivery expected and not arrived.

Each of those is computable from data the system already holds. None requires anybody to file a complaint. And because the observation is mechanical, the conversation it produces starts from a fact rather than from an allegation — this has moved twice is a much easier sentence to open with than he keeps missing it.

We built ours this way deliberately: chronically sliding work surfaces itself, so nobody has to snitch. The word is the right one, because that is exactly what people feel they are being asked to do. It matters most at the boundary between two agencies, where the problem belongs to neither of them — one project, many contractors.

Predict rather than report#

The next step is to notice before the date rather than after it.

A late task is a fact. A task likely to be late is a warning, and it is the warning that has value, because it arrives while there is still time.

The inputs are unremarkable: how long this kind of work usually takes, how much of the remaining time is left, whether it has been pushed before, whether the person holding it is carrying an unusual load, whether it is waiting on somebody who is on leave. None of this is clever. Most organisations have all of it and use none of it, because nobody has ever been asked to compute a forecast for a task.

Two rules make it usable rather than annoying.

It goes to the person who can act, not to everybody. A slip-risk warning broadcast widely is a public prediction of somebody's failure, which is exactly the shame problem again, arriving from the other direction.

It says why it thinks so. A score with no explanation is either believed blindly or ignored entirely, and both are useless. Pushed twice, two days left, usually takes five is actionable. A number out of a hundred is not. The general form of that requirement is the app should tell you why.

The scoring mistake we made#

Our early risk scoring treated every task settled stage-by-stage as money not yet paid, because a staged payment never wrote the field meaning paid. That added a substantial pile of pure noise to a board built to show what actually needs a human.

A warning system that cries wolf gets ignored, and it gets ignored wholesale — people do not learn to discount one category of false positive while remaining alert to the rest. They discount the board.

The underlying fault was the same one that had leaked into eight other places in the application, and it is described in a fact that had no owner. Its relevance here is narrower and worth stating plainly: the accuracy of an early-warning system is not a quality attribute, it is the entire asset. A risk board that is right most of the time is not most of a risk board. It is nothing.

Ask the person first#

Before anything goes upward, the person holding the work should have had a chance to say what is happening, in a form that takes seconds.

A short evening list of what is outstanding, with a small number of honest answers — done, moving to tomorrow, moving to a date, stuck and here is why — resolves most of what would otherwise have escalated, and it does so without anybody being told on.

The fourth answer is the valuable one. Stuck, waiting for the drawing is a complete escalation, filed by the person best placed to file it, without requiring them to make a complaint about anybody. It arrives as an explanation of their own situation rather than as a report about somebody else's.

Cap the list. A list of thirty items is not a question, it is an accusation, and people stop answering. Respect leave, or the first message somebody gets on returning from a funeral will be a demand.

What escalation should look like when it does happen#

  • Addressed to somebody specific, who can act.
  • Stating the condition, not a judgement. What has happened, how long, what it is waiting on.
  • Carrying its own history. How many times, since when, what was tried.
  • Closable. An escalation with no way to say resolved, because this stays open and pollutes the next one.

And it should be quiet by default. An escalation that arrives with alarm attached spends attention that a later, more serious one will need. Attention is a fixed supply, which is the subject of an alert that rings for everything.

The short version#

People do not escalate because escalating means naming a colleague.

Let the system notice instead. Compute the conditions rather than requiring reports, warn before the date rather than after it, tell the person who can act and tell them why, and give the person holding the work a two-second way to say they are stuck.

And make sure the warnings are right. An early-warning board that is frequently wrong is not a partly working control. It is an ignored screen. The related question of where the time actually goes is in why tasks stall between people.

Have a gap worth closing?

If something in your daily work is broken in a way everybody has stopped complaining about, that is exactly what we want to hear.

Write to hello@be-teck.com

More notes