Right. I've read the postmortem, and then I read the one before it. So before we start — David, is this a "we've got it under control" conversation, or a "we need something from you" conversation? Because they're very different meetings.
Sarah isn't being hostile; she's being efficient. Senior people want to know which meeting they're in within thirty seconds: are you informing me, or are you asking me for something? Most escalations fail right here, because the person brings a problem without knowing which one they're doing. Notice she gives David a clean choice rather than making him guess.
The second one. We need something from you, and it's specific, and it's small.
No preamble, no "well, it's a bit of both." "The second one. We need something from you, and it's specific, and it's small." Fifteen words that tell Sarah exactly how to listen for the next five minutes. The word "specific" is doing a lot of work — it's a promise that this won't be a vague plea for help, and it buys attention.
So. Four schema changes this quarter, all unannounced, and the last one took the reports down for a morning. Priya's built everything we can build on our side — the pipeline fails loudly now, the alerts page us, the schema check catches changes before the load. That's all done.
But we're detecting a problem we shouldn't be having. And that half is not something we can fix. It sits with the ERP team, and I've asked twice.
Before asking for anything, David establishes that he's exhausted his own options: everything buildable is built. You do not get to escalate until you've spent your own leverage — and saying so out loud is what separates an escalation from a complaint. "I've asked twice" is a fact, said flatly, with no editorial. He doesn't say "and they ignored me," which would turn a request into an accusation.
And what did they say?
First time, I caught their lead after a workshop — he said "yeah, no problem, we'll ping you." Second time I put it in writing, properly, with the table list. Got a thumbs up.
David doesn't say "I tried twice and got nowhere" — he shows the receipts: a corridor conversation, then a written request with the table list attached. Escalation is an evidence-based genre. The detail also quietly answers a question Sarah hasn't asked yet: was the ask clear, or is this a communication failure on your side? A thumbs up on a written request with a table list is not ambiguity — it's a priority problem, which is exactly where he's heading.
Honestly? They said yes, both times. And then Tuesday releases kept going out. I don't think anyone's being difficult — I think we're not on their list, and nothing that isn't on the list happens.
This is the sentence that makes the escalation survivable: "I don't think anyone's being difficult — I think we're not on their list." David reframes a human failure as a prioritisation failure. Two reasons this matters. First, it's usually true. Second, he will need the ERP team next month, and nothing poisons a working relationship faster than finding out you were described as obstructive in a room with the sponsor. Escalate the problem, never the people.
Priya, how bad is this actually? Give me a number, not an adjective.
Four breaks, four reruns. Around six hours of my time, plus half a day of Marco's, plus the reports being wrong for a morning each time. So — call it two days a quarter, and growing, because the ERP release cadence is going up, not down.
Sarah's phrasing is worth memorising, and so is Priya's answer. No "it's really disruptive", no "it's a nightmare." Hours, days, a trend. "And growing" is the important half — it turns a cost into a trajectory, which is what actually moves a decision. Senior people discount adjectives automatically; they can't discount two days a quarter.
And the honest version — it's not the two days. It's that I now don't trust the platform enough to leave it alone. Every Tuesday I'm watching it. That's the real cost.
Priya gives the measurable answer first — that's what earns her the right to add this. The real damage isn't the six hours; it's that a system nobody trusts has to be babysat forever. Saying it after the numbers makes it credible. Saying it instead of the numbers would have made it a feeling.
And the forecasting module — where is that, honestly? Because that's the thing I have to show in November, and I'm now hearing it's got a Tuesday-shaped hole in it.
It's on track. But "on track" assumes I'm building it, not firefighting. Two days a quarter is the difference between comfortable and tight.
Sarah doesn't care about schemas; she cares about November. Priya's answer does the translation without exaggerating: "on track" — she doesn't manufacture a crisis to strengthen the case — and then names the honest margin, "the difference between comfortable and tight." An escalation lands when the cost is expressed in the listener's currency, and it stays credible when you resist the temptation to inflate it while you have their attention.
Okay. But let me push back on something. You're the delivery partner. We hired you to build a platform that works in our environment — and our environment includes an ERP team that ships on Tuesdays. Why is this landing on my desk?
This is a legitimate question, asked well. She's not attacking; she's testing whether David has thought about the boundary of his own responsibility. Every escalation to a senior person meets some version of "why is this mine?" — and the ones that collapse are the ones where the answer is improvised. Notice Sarah names her reasoning ("our environment includes an ERP team that ships on Tuesdays") rather than just refusing. That's a challenge you can answer.
That's a fair challenge, and I've thought about it. Here's where I land: we can absorb the ERP team shipping on Tuesdays. We've done that — that's what the schema check is. What we can't absorb is not being told. That's not an engineering gap, it's a comms gap between two teams inside your organisation, and I don't have a lever there. You do.
Two moves in one breath. First he validates the question honestly — not "well, actually", but "that's a fair challenge, and I've thought about it." You cannot win a pushback by treating it as unreasonable. Then he draws the line precisely: we own the engineering problem, you own the organisational one. He isn't giving the problem back; he's separating the half he's already solved from the half that requires authority he structurally doesn't have. "I don't have a lever there. You do."
And — I'd back that up, Sarah. I've been on both sides of this one. Nobody in ERP is doing anything wrong. They've got a roadmap, we're not on it, and there's no mechanism that makes them think about downstream. There's no bad guy. There's just a missing process.
Tom is the most delicate voice in the room: he's client-side, so he's effectively siding with the consultants against another internal team. Watch how he protects himself — he defends ERP twice ("nobody is doing anything wrong", "there's no bad guy") before landing his actual point. If you're going to support an escalation against your own colleagues, defend them first and make it about the system. Otherwise you're the person who briefed against another team, and that follows you.
Hm. That's the bit that lands, honestly. "There's no mechanism." Everything else I could argue with.
Which raises a question. Are you the only ones this happens to? Or are we just the only ones complaining?
No — finance hit the same thing in May. A column moved and their month-end extract broke. They didn't escalate, they just rebuilt the extract and put a note in their runbook to check it every month.
...Nobody told me that.
Nobody tells you that. It's a Tuesday problem. It never gets big enough to be worth a meeting — it just quietly costs everyone a day a month forever.
Sarah asks the shrewdest question in the meeting, and it isn't aimed at David — it's aimed at her own organisation. The answer transforms the escalation: it's no longer a consulting team asking for a favour, it's a systemic cost nobody has ever added up. If you're escalating, find out who else has the same problem before you go in — a shared problem is a policy decision, a lone problem is a special request, and policy is much easier to say yes to. And Tom's line names why these things stay invisible: "it never gets big enough to be worth a meeting."
So finance absorbed it silently and you didn't. Interesting.
We absorbed it three times. This is the fourth.
Sarah's "finance absorbed it silently and you didn't" has a small edge in it — the implication that the consultants are the ones making noise. David doesn't get defensive and doesn't let it stand: six words, factual, no tone. "We absorbed it three times. This is the fourth." Correcting a mischaracterisation without arguing about it is a register worth practising — you state the fact and stop talking.
So be concrete. What are you actually asking me for? And don't say "support."
Two things, both small. One: ERP add a line to their release checklist — "does this change a table anyone downstream reads?" If yes, they post in one channel. That's it, no meeting, no approval. Priya reckons the check itself is ten minutes a release.
Two: someone in ERP owns it. Not a team — a name. Because "the team will handle it" is what we've had for three months.
Look at what David is NOT asking for: no reprioritisation, no headcount, no process overhaul, nobody told off. One checklist line, one channel post, ten minutes a release, one named human. The smaller and more precise your ask, the harder it is to refuse — and the more likely it is to actually happen. And the "name, not a team" point is the hard-won one: work assigned to a group is work assigned to nobody.
And I'll give them the list of tables. They shouldn't have to work out what we read — that's on us. Eleven tables, I'll send it today.
Priya takes the one piece of work the other team would have had to do and does it herself. "They shouldn't have to work out what we read — that's on us." This is what makes a small ask genuinely small: not just "please do this", but "here's everything you'd need, already done." Every gram of effort you leave on the other team's side is a reason for it to slip another quarter.
And if I don't?
Then we keep absorbing it. It's survivable — but Priya babysits Tuesdays instead of building the forecasting module, and that's the thing you asked for by November. I'd rather flag that now than in October.
"And if I don't?" is the question every sponsor asks, and the answer is where escalations turn ugly. David doesn't say "then we can't be held responsible" (defensive) or "then the project fails" (inflated). He states a trade honestly: it's survivable, and here's what it costs you — in the currency you care about. Then the tell: "I'd rather flag that now than in October." That single sentence reframes the whole meeting from complaint to professionalism — he's not protecting himself, he's protecting her from a surprise.
Right. I'll do it — but not the way you've asked.
A checklist line from me lands as "the sponsor is annoyed," and they'll comply for three weeks and then drift. I'll go to Ravi — he runs ERP — and I'll frame it as a shared standard, not a favour for your project. Any team that reads someone else's tables gets told. It'll take me a fortnight instead of a phone call, and it'll actually stick.
This is what you escalate for. Sarah accepts the substance and changes the delivery — because she knows something David can't: how an instruction from her actually lands inside her own organisation. "They'll comply for three weeks and then drift" is a piece of political knowledge no consultant has. A good escalation gives the decision-maker the problem, not the solution — and then lets them use their own leverage their own way.
That's better than what I asked for.
Can I ask the awkward one — what if Ravi says no?
He won't. But if he did, you'd hear it from me the same week, and we'd talk about what you stop doing to cover it. I'm not going to leave you carrying it and pretend it's fine.
"Can I ask the awkward one" — David flags that he's about to be uncomfortable, which is how you buy permission for a hard question. And the question itself is the mature one: escalations often end in a warm yes that quietly evaporates, and the person who asked walks away with no plan for the version where nothing happens. Sarah's answer is the good one: a no gets communicated fast, and it comes with a trade ("what you stop doing to cover it"). A decision you can't rely on is worse than a refusal you can plan around.
It usually is. But — a fortnight. So you carry it for two more Tuesdays. Can you?
Yeah. The schema check goes in Thursday anyway, so worst case I get an email at eight in the evening instead of a phone call at half eight in the morning.
Sarah gives a date and immediately checks the gap is survivable — "you carry it for two more Tuesdays. Can you?" And Priya says yes with evidence, not stoicism. If you escalate and then can't tolerate the realistic timeline of the fix, the escalation was actually a demand. Notice the whole room is now solving the same problem.
One thing — when you talk to Ravi, can you keep us out of it? Not hidden, just... it shouldn't sound like the consultants complained. We've got to work with those guys for another year.
Noted. And for what it's worth, that's a sensible thing to ask. Most people don't think about the year after the meeting they're in.
The escalation is won; David's last move is to make sure winning it doesn't cost him something else. "It shouldn't sound like the consultants complained" — he's managing how the story travels, because in a year's time the ERP team's willingness to help him will depend on it. Escalating is easy; escalating without becoming the person who escalates is the skill. Sarah's reply tells you he read it right.
Okay. I'll talk to Ravi this week, shared standard, and I'll copy Tom when it's agreed so you know it's real. David — thank you for bringing it like this rather than in an amber status report.
"Rather than in an amber status report" — she's naming the alternative universe where this problem shows up as a yellow box on a slide in six weeks, with no ask attached and no time to fix it. Sponsors don't mind problems; they mind being surprised by problems that were visible months earlier. An escalation delivered early, with a specific ask, is a favour to the person receiving it — which is exactly why the good ones get said yes to.
Tom — one for you. Go and find out what finance actually did in May, and whether anyone else has quietly built a workaround. If there are four teams doing this, I'm not asking Ravi for a favour, I'm taking a number to the exec.
On it. I can have that by Friday — I know who to ask in finance.
Watch what David's request has become in Sarah's hands: a request for a checklist line is now a possible exec-level policy backed by a cost number across four teams. He didn't ask for that and couldn't have — he doesn't have the standing. This is the real return on escalating well: you hand a clean, small, well-evidenced problem to someone with reach, and it comes back bigger than you could have made it. Note also she's arming herself with a number before she walks into the room — the same discipline she demanded from Priya at the start.
Appreciated. And if the standard lands, I'll stop bringing you ERP problems entirely.
That's the deal. And David — next time, bring it after two. Not four.
Fair. Noted, and I mean that.
Sarah's last line is the one to sit with. David ran a textbook escalation — and she still tells him he was late. "Bring it after two. Not four." Absorbing the problem three times looked like professionalism from where he stood; from where she sits it looks like two extra quarters of a cost she could have killed. The instinct to cope quietly is admired right up until the moment it isn't. And note the shape of his answer: "Fair." One word, no defence — the same move he made all meeting.