When leadership means doing the boring analysis nobody else has a reason to do.
A trending red project came across my desk. The later phases of a deal that had been sold a few years previously, it was getting to the point where it had to prove itself. The customer - a large, process-heavy institution - had been promised a certain level of system performance during procurement, this was committed contractually. What was contracted was accurate and achievable. What they expected and were testing for wasn't quite the same thing, and the gap between the two was becoming an unstated source of trouble.
Their test approach took the worst-case volume for every type of transaction the system handled, added them all together as if they'd all happen at once, and threw the total at the system as peak load for a period of time. It wouldn't happen like this in reality, but that's what they wanted to test and the system couldn't cope with it.
The part I found more interesting than the technical problem itself was that everyone involved was behaving completely reasonably, but between all of them nobody was going to solve it.
Our engineering team said the customer's approach was simply wrong, which was true, but they treated "wrong" as a reason not to engage with it rather than a reason to help reframe it. Without their backing our project manager didn't want to challenge the customer's test design, knowing that the system wouldn't be able to cope with what they were expecting anyway. Our delivery partner on the ground meant well, but we were one of many accounts they were juggling, they had a broader relationship and needed to keep the customer happy, and in any case we were the experts. And on the customer's side, the business, operations and technical contacts didn't fully agree with each other on what actually mattered, so nobody there was pushing a single clear ask either.
Nobody was acting in bad faith. Everyone had a perfectly good reason, from where they sat, to agree it was a problem for someone else, and leave it sitting there unresolved.
What moved it forwards was going and doing the unglamorous analysis work: pull apart the real usage patterns behind the requirements, build an honest combined picture of what the system would actually see in production rather than an artificial worst case, identify precisely what the contract was saying, and then set about proving it in stages - start with a smaller, but realistic, volume first, then next step up, then the next and involve everyone in real end-to-end testing right through to the operational teams, to get them hands-on with the system. Once the plan existed, it wasn't hard to get people behind it. Everyone had been reasonable about not fixing it. Nobody was unreasonable about a collaborative plan that would show progress instead of paralysing the process waiting for a solution from elsewhere.
I left the company before that project reached its final chapter, so I can't tell you how the story ends. What I can tell you is that the plan was signed off by everyone who needed to sign off on it, and the customer was finally testing something that had a real chance of succeeding.
The lesson I took from it wasn't really about testing methodology. It was that when a group of reasonable people fail to address an obvious problem, the issue usually isn't one of competence or capability. It's that everyone has a perfectly good reason not to be the one who does it. Find that, and you usually find the fix too.