Taking over an account that's already on warning
What I did in the first two weeks of a rescue engagement, in order — including the parts that were uncomfortable.
There's a particular kind of phone call in this job. A flagship account is in trouble, the customer has put something in writing, and someone needs to take it over. In my case the stack was unfamiliar, the team was demoralised, and the customer had stopped assuming good faith.
That engagement ended with documented positive feedback. Here's the order I did things in, because the order mattered more than any individual decision.
Week one: stop talking about the plan
The instinct when you inherit a troubled account is to produce a recovery plan. Resist it for a few days. A plan written before you understand the failure is a second thing the customer will watch you miss.
What I did instead:
Read every ticket, not the summary of every ticket. Summaries are written by people protecting themselves. The raw tickets told me the real story: the same three integration points failing repeatedly, and each fix being applied at the symptom.
Talked to the engineers alone, before the managers. Not to gather evidence — to find out what they'd already flagged and been overruled on. In almost every troubled project I've walked into, someone junior called it correctly six months earlier and got talked out of it. Finding that person is the fastest route to the actual problem.
Asked the customer what "fixed" looks like. Concretely. Not "improved quality" — which release, which behaviour, observed by whom. A formal warning is usually a communication failure wearing a technical costume. The customer often can't tell you what would satisfy them until you make them say it out loud.
Week two: fix one visible thing, completely
Not the biggest thing. The most visible thing that can be genuinely finished.
Credibility on a warned account is spent, and you rebuild it with completed items, not progress percentages. One thing shipped, verified, and closed does more for the relationship than a Gantt chart showing eleven things at 60%.
This is also where you find out whether your team can actually finish anything, which is diagnostic information you need early.
The uncomfortable parts
I stopped some work that people were emotionally invested in. Two workstreams were consuming capacity and producing nothing the customer had asked for. Ending them cost me goodwill inside the team that took months to earn back.
I over-communicated to the point of it feeling excessive. Weekly written status, every week, whether or not there was good news — especially when there wasn't. A warned customer reads silence as concealment. The week I had nothing good to report was the most important status update I sent.
I didn't defend the past. The temptation to explain why the previous decisions were reasonable given the constraints is strong and completely counterproductive. The customer doesn't need the history litigated. They need to see the next thing land.
What I'd tell someone walking into one
Ramping up on an unfamiliar stack while the account is on fire is survivable — the technology is rarely the bottleneck. The bottleneck is that everyone involved has stopped trusting the process, and trust is rebuilt in small completed increments, publicly, on a schedule.
The stack you can learn in a fortnight. The trust takes the whole engagement.