When to Escalate and When to Absorb

A payments engineer pinged me at 11:40 on a Tuesday night: our settlement reconciliation job had thrown an exception and stopped halfway through a batch of about 4,000 merchant payouts. Her message ended with a question that, over fifteen years, I've come to see as the sharpest thing a growing engineer can learn to ask: "Do you need to know about this now, or can it wait until standup?"

That question is the whole game. Escalation is not a measure of how serious a problem is. It's a bet about who needs to be involved, and when, to get the best outcome at the lowest cost. Get the bet wrong in one direction and you burn out your leaders and desensitize everyone to alarms. Get it wrong in the other and you find out about a regulatory breach from the regulator. I've done both. This is what I've learned about the line between the two.

The real cost of escalating is attention, not embarrassment

Most engineers think the cost of escalating is looking incompetent. That's the wrong worry. The actual cost is that you're spending someone else's attention, and attention is the scarcest resource in any engineering org. When you page me at midnight, you are not just waking me up. You are training me, and everyone watching, about what "midnight-worthy" means. Do it for a non-event and you've quietly raised my baseline anxiety and lowered my trust in the next page.

There's a symmetrical cost to absorbing, and it's larger but slower. When someone quietly eats a problem that should have surfaced, the organization loses the chance to learn from it. I once had a senior engineer who was so good that he absorbed everything. Flaky deploy pipeline? He'd babysit it. Onboarding docs wrong? He'd walk each new hire through it personally. He was a hero, and he was also a single point of failure who hid three quarters of our operational debt from me. When he left, we discovered we had no runbooks because he was the runbook.

Two questions that settle most cases

When a problem lands on your desk, I want you to ask two things before you decide to escalate or absorb. First: is this reversible? Second: is it contained? Reversibility tells you how much a wrong decision costs. Containment tells you whether the blast radius is growing while you think.

A reversible, contained problem is yours to absorb. A failed non-critical batch job that you can safely rerun in the morning, affecting internal reporting and nobody's money? Absorb it, fix it, mention it at standup. An irreversible or spreading problem belongs to more people immediately. Funds moving to the wrong accounts is irreversible in practice, even if technically you can claw back, because the clawback involves lawyers and partner banks and a mess. Here's the rough hierarchy I teach:

• Reversible and contained: absorb it. Log it, fix it, and report it in the normal cadence.
• Reversible but spreading: absorb the fix, but announce it in the incident channel so others can help stop the spread.
• Irreversible but contained: escalate to your lead, calmly, now. One wrong payout is contained but you don't get to undo it alone.
• Irreversible and spreading: escalate loudly and immediately. Wake people up. This is the page-the-CTO case.

What happened with the midnight batch

Back to that Tuesday. The engineer's job had failed halfway through payouts. My first two questions: reversible, contained? She'd already checked. The job was idempotent, it tracked which payouts had completed, and the remaining 2,100 merchants simply hadn't been paid yet. No double payments were possible. No money had gone anywhere wrong. The only consequence was that some merchants would see their payout a few hours later than usual, and our SLA gave us until the next business day.

So the honest answer was: it can wait until standup. And I told her exactly that, and I thanked her for asking rather than either paging me reflexively or sitting on it silently. She'd done the analysis, reached a defensible conclusion, and checked her work with a low-cost question instead of a high-cost page. That's the behavior I want to reward, because the alternative version of that engineer either wakes me for nothing or, worse, decides on her own to manually push the remaining payouts at midnight, half-asleep, outside the tested path. That's how a delayed payout becomes a duplicated one.

Absorbing well is an active skill, not passivity

People hear "absorb" and picture someone swallowing a problem and moving on. That's not absorbing, that's hiding. Absorbing well means you take responsibility for the resolution and for making the problem visible at the right altitude. The difference is whether the information still flows, just through a cheaper channel.

Concretely, an engineer who absorbs a flaky test correctly doesn't just retry the build until it goes green. She files a ticket, tags it, notes the flake rate, and if it crosses a threshold she brings it to the team. The problem got handled without consuming a leader's real-time attention, but it did not vanish from the record. I care enormously about that distinction. A team that absorbs well has a clean backlog of known issues and a quiet on-call. A team that hides has a suspiciously quiet on-call and a horrifying surprise every quarter.

The goal of escalation is not to transfer the problem to someone more senior. It's to bring the right amount of judgment and authority to bear at the right time. Sometimes that authority is you.

Regulated money changes the math

Everything I've said gets reweighted the moment real money and regulators are involved. In a regulated payments business, some categories are escalate-always regardless of how contained or reversible they look, because the obligation isn't technical, it's legal. Suspected fraud, potential data breaches involving customer PII, anything that might be a reportable AML event, and any incident that could trip a regulatory notification clock all go up the chain immediately. Not because you can't handle them, but because the clock started the moment you knew, and now other people need to know so the org can meet its obligations.

I learned this the expensive way at a previous company. An engineer noticed unusual login patterns that turned out to be credential stuffing against a subset of accounts. He handled the technical side beautifully: rate limits, forced resets, the works. He did not tell anyone in compliance for two days because, in his words, "I fixed it." But we had contractual notification windows with partners, and "I fixed it" was not a defense. The technical incident was contained in hours. The trust and contractual fallout took months. When PII or regulatory reporting is even plausibly in scope, the reversibility-and-containment test doesn't apply. You escalate. Full stop.

Calibrating a team so the line is shared

The line between escalate and absorb only works if the whole team draws it in roughly the same place. If every engineer has their own private threshold, you get chaos: one person pages for a slow query, another sits on a data integrity bug for a week. The fix is not a rulebook. It's repeated, concrete examples and a lot of "you made the right call" and "here's why I'd have called that differently" delivered without blame.

I do this in incident reviews by explicitly grading the escalation decision separately from the technical response. Someone can handle an incident technically well and escalate poorly, or vice versa, and I want to name both. The message I'm sending is that the decision itself is a first-class piece of work, not an afterthought. Over about six months a team converges on a shared sense of the line, and then on-call gets genuinely calmer because nobody is second-guessing whether a given thing is "a big deal."

The line moves with seniority, on purpose

A brand new engineer should escalate more than a staff engineer, and I want them to. Early on, I'd rather you over-escalate and we recalibrate down than have you make a lonely call on something you don't yet have the context to judge. The threshold is a function of judgment, and judgment is exactly what a junior engineer is still building. So I tell new hires directly: for your first few months, when in doubt, ask. You will not annoy me. You will annoy me if you guess wrong on something you could have cheaply checked.

The trap is when that never shifts. A senior engineer who still escalates every ambiguous case hasn't grown into the role, and one who absorbs everything without surfacing it has grown in the wrong direction. Part of my job is watching where each person's threshold sits and nudging it. The best senior engineers I've worked with escalate rarely but with perfect aim, and when they do escalate I move immediately, because they've earned the reflex. That earned trust is worth more than any alerting policy.

What I actually tell people to do

When someone asks me for a rule they can carry in their head, I give them the question the midnight engineer used, plus one addition. Ask whether it's reversible and contained, and decide accordingly. But when you're genuinely unsure and the cost of asking is low, ask the cheap question first. A two-line message that says "here's the situation, here's my read, do you agree?" costs almost nothing and it's neither a full escalation nor silent absorption. It's the pressure-release valve between them, and it's underused.

The people who master that middle move end up being the ones I trust most, because they've shown they can think about the decision and also show their work. They're not offloading the judgment onto me; they're checking their judgment against mine while it's still cheap to correct. Over time I stop needing to be asked at all, which is the actual point.

Conclusion

Here's the thing I'd add that took me the longest to learn: escalating and absorbing aren't opposite virtues where one is brave and the other is cautious. They're the same skill pointed in two directions, and the skill is honest situational judgment about who needs what information, when. A person who only ever escalates isn't careful, they're outsourcing their thinking. A person who only ever absorbs isn't strong, they're a liability wearing a cape. Build people who can do both, name the decision out loud when you review incidents, and reweight everything the moment regulated money is in play. Do that, and your on-call gets quiet for the right reasons instead of the terrifying ones.