By the time the 2024 China payment migration reached my team at Payoneer, the senior business stakeholder driving it had already been waiting roughly two years for the capability to be prioritized. We were inheriting more than a product request; we were inheriting the frustration around it.
Much of the skepticism predated our work. The capability had struggled to reach prioritization, earlier interactions with Product and R&D had left some confidence to rebuild, and there was an understandable concern that teams balancing global priorities might not fully appreciate what mattered to the China business.
The migration itself was substantial: replacing an existing payment route with a more durable alternative across customer, operational and platform dependencies. I cover that product and regulatory story separately in The Payment Route Was Still Working. We Had to Build Its Replacement Anyway.; here, the harder problem was the relationship around the work.
The stakeholder followed the program closely, and his weekly reporting carried concerns about delays or insufficient progress upward. Those concerns would then return through management as questions and additional status work for a team already coordinating a complex program. Given the history, the scrutiny was understandable; asking for more trust would not have given him a reason to extend it.
Making execution visible
We aligned around a clear plan and explicit commitments, then followed progress closely enough to see when something was moving off plan before somebody outside the team had to point it out. With that many dependencies, not every delay was preventable, but discovering one late was something we could control.
When something slipped, we surfaced it ourselves. We owned what was ours, explained what had happened and made the recovery clear. The reporting only mattered if it gave everyone a shared view of reality before escalation became the mechanism for creating one.
That visibility mattered beyond the stakeholder directly challenging us. When managers and adjacent teams already understood where the program stood, including its problems, escalation was less likely to introduce a different account of events. We were demonstrating that the program could govern its own performance while still listening carefully to the concern behind the pressure and taking the China organization’s needs seriously. Transparency supported the relationship because our commitments were backed by observable follow-through.
Learning to work as a partner
At Amdocs, I led a delivery organization working directly with internal business customers, and one senior stakeholder relationship was particularly difficult for me at first. I was approaching too much of it through a conventional customer-and-delivery model in which the business asked, IT responded, and much of the tension revolved around whether and when we could satisfy the request.
My manager helped me shift the relationship toward what we called partner mode. The technology organization needed a position of its own, roles and responsibilities had to be clearer, and both sides needed an agreed way of working and a plan that made commitments explicit.
Taking that position also raised the standard for our own behavior. If I expected the stakeholder to respect our judgment, our execution had to make that judgment credible: understand the business concern rather than simply process the request, be clear about commitments, expose problems openly and own mistakes when they were ours.
Over time, the relationship became more manageable. What stayed with me was the combination of the relational and operational sides of partnership: personal trust, communication and mutual understanding matter, and they are easier to build when the organization behind you repeatedly demonstrates that it can be trusted with its own commitments.
Recognizing the pattern again
Years later at Payoneer, I recognized the same pattern. When confidence is low, stakeholders often create visibility from outside through more checking, reporting and escalation. I had learned not to make that oversight the first problem to solve; the better target was the uncertainty that made the oversight feel necessary.
We kept the program legible and stayed consistent when the news was uncomfortable. After at least a couple of months, the recurring escalations largely stopped. The relationship was still demanding, but management escalation was no longer the routine way to establish whether the program was under control.
To me, that was evidence of a more functional kind of trust. The stakeholder had more reason to believe that we would surface problems ourselves, and the organization around the relationship could see that accountability was already happening inside the program.
Trust still starts with the relationship
I do not see operational transparency as a substitute for the human side of stakeholder management. Strong relationships still depend on listening, understanding the other side’s priorities and history, adapting how you communicate, and creating a relationship in which both sides can work together productively; where possible, I want that relationship to be pleasant as well as effective.
Operational discipline adds another layer because it turns accountability into something the stakeholder and the organization around them can observe. A clear plan creates shared expectations, proactively surfacing a miss shows that transparency survives bad news, and owning the recovery demonstrates that accountability does not have to be imposed from outside.
Once that shared visibility exists, escalation can return to resolving the problems that genuinely require higher-level intervention instead of serving as the normal way to discover whether a team is paying attention. You do not reduce oversight by asking for trust; you build the relationship and the operating discipline that make close supervision less necessary.
The shift is not fewer problems.It’s moving visibility earlier —and returning escalation to its proper role.