Pre-close
A deal sits in the last stage for six weeks. Legal is waiting on Product. Product is waiting on a decision Sales assumed Legal had already made.
For fintech and payments companies that outgrew how they run.
The deal is stuck
in the last stage
and nobody can tell you
who's supposed to move it.
Operational diagnostics · Fintech and payments
I diagnose where execution breaks down between teams as fintech companies scale, then build the operating structure that fixes it.
Square, Afterpay and American Express from the inside. Banks, card networks and payments infrastructure from the outside.
Start with the real issueThe pattern
You've seen at least one of these this quarter.
Post-close
A deal closes with a pricing exception Sales approved on the call. Finance finds out at invoicing, six weeks later, and nobody can reconstruct who actually had authority to grant it.
Post-launch
A partner integration goes live and Risk learns the exposure profile from the launch announcement. Remediating it costs more than the deal was worth.
Every one of these has a competent person at the centre of it, doing exactly what they were asked to do. What's missing is the sequence between them, and nobody designed that sequence. It got inherited, one deal at a time.
Why this is different
Most operating advice doesn't survive contact with a payments company.
The standard prescription is to reduce friction: fewer approvals, a shorter path, control functions moved out of the way of the deal.
In payments that advice buys you eighteen quiet months and then a considerably worse problem. Legal, Risk and Compliance sit in the deal path because the business requires them there. The useful question is about timing rather than access. Are they engaged at the point where their answer can still change the shape of a deal, or at the point where it can only stop one?
Most of the friction I get called about turns out to be sequencing. The control function is doing precisely what it should, three weeks after the moment that would have mattered.
I've been that function on both sides of it: inside Square, Afterpay and American Express, and independently for the banks, card networks and fintechs I advised in between. Then I moved to the go-to-market side and watched the same breakdowns from the other direction.
The work
Diagnose first. Build second.
Diagnose
I talk to the people running the work and not only the ones describing it, which usually means the deal desk, the account managers, and the RevOps analyst maintaining the spreadsheet everyone actually uses. Then I map where a deal moves through the organization against where the documented process says it moves. In regulated businesses those two paths diverge further than anywhere else, because the official one was drawn to satisfy a control requirement and the real one was drawn by whoever needed to close last quarter.
Design
Once the constraint is validated I build around it: decision rights, escalation paths, handoff rules, and enough governance to stop them eroding by the third quarter. The test is whether it survives a reorg, not whether it reads well in a document. I stay accountable through stabilization, which means the engagement finishes when someone inside the business can run the thing without me in the room, not when the recommendation is delivered.
Every recommendation traces to evidence from inside your business. If I can't trace it, I don't recommend it.
Selected work
Three examples of operating systems under strain.
These are examples of the kinds of operating problems I diagnose and redesign: where ownership is unclear, decisions happen too late, or the system relies on people to compensate for what it was never designed to handle.
What it looked like
Deals were closing later than the forecast assumed and nobody could say exactly why. Internal teams were increasingly described as blockers, and every week brought pressure for another exception to get a specific deal through. Every function was operating in good faith. Leadership read the friction as capacity, tooling, or training.
What was actually happening
The organization was moving upmarket while its existing high-volume motion stayed live underneath. That process was built for throughput: linear, fast, few dependencies. The larger deals were none of those things. They touched more functions, held open questions further into the cycle, and required decisions the high-volume process had been designed to defer. The breakdowns were not inside any team. They were at the seams, where a complex deal hit a process that had never been asked to decide anything that early.
What changed
Critical decisions moved earlier in the lifecycle. Judgment was replaced with explicit thresholds. Ownership was made explicit at every point where a deal crossed between functions, and exception paths were reduced rather than formalized. No reorg, no added headcount. The organization shifted from exception-driven execution to designed execution.
What it looked like
A deal that had been in the pipeline for two quarters went to legal review three days before quarter end and surfaced a data residency requirement nobody had raised at any earlier stage. It wasn't unusual. Late-stage escalations of that kind were the normal way large deals moved, cycles were lengthening, and sellers had started treating internal teams as obstacles rather than participants.
What was actually happening
The breakdowns lived between functions rather than inside them. Decisions that belonged at qualification were being made at contract, which in a regulated business is the most expensive available moment to discover a constraint. The rules governing those decisions existed as accumulated judgment rather than design, so every new deal reopened a question the last deal had already answered, and each function was confident the problem sat with a different one.
What changed
I redefined decision sequencing, ownership and handoff logic across the revenue motion, moving genuine deal constraints into qualification rather than contract stage. Risk, Legal and other downstream functions had explicit entry points and decision rights instead of relying on late escalation. The organization moved from escalation-driven to designed execution without a reorg or added headcount.
What it looked like
The account managers supporting the highest-value customers were absorbing a continuous stream of updates from Product, Partnerships, Lifecycle, Engineering and Enablement, arriving at unpredictable times through whichever channel the sender happened to prefer. High-impact changes surfaced late, occasionally after a customer had already felt them.
What was actually happening
The organization was treating a capacity-constrained team as an always-available distribution surface. A pricing change, a deprecation and a compliance-driven migration all landed on the same person, through the same channel, with nothing to signal which one carried real risk. No rule existed for what qualified for AM attention or when leadership review was required, so the team was personally absorbing a triage function the system should have been performing.
What changed
A single intake for cross-functional updates, prioritization tiers tied to customer impact, leadership gating on high-impact items, and a cadence built around what the team could actually absorb. Information was no longer routed directly to AMs simply because someone wanted them to know about it. High-impact changes surfaced earlier, with context and clear ownership, without new tooling.
Engagements
Two ways in.
Operational Diagnostic
A bounded engagement to identify which operating problems are real, systemic, and expensive enough to justify fixing. You get a clear account of what's breaking, why it's breaking, and what a durable fix requires. Every finding traces to evidence from inside your business.
System Design and Build
Once a constraint is validated I design the operating model around it and stay accountable until it holds under real conditions: structure, decision rights, cross-functional workflow, escalation. The engagement ends with a handoff to an internal owner rather than an open-ended retainer.
If you're not sure which of these you need, it's the first one.
About
I find the issue underneath the issue.
Companies call me about the visible thing: a stalled deal, a broken handoff, a rollout that stopped working. My job is to get the right people looking at the real one.
Twenty years in payments, at TD, American Express, Afterpay and Square, and a decade in between running my own advisory for card networks, North American banks and payments infrastructure companies operating in Canada.
Across all of it I sat at the point every commercial deal had to clear. At American Express that meant the leadership teams for commercial card and business travel. Afterpay was the largest merchant and partner negotiations, the deal infrastructure built from nothing, and a seat on the Canadian board through registration under the Retail Payments Activities Act. By Square I was doing the same across a global platform, until I moved into the go-to-market organization to work on execution directly.
That position teaches you something you can't learn from inside a single function. When every deal, exception and escalation routes through you, individual problems stop looking individual. You start noticing that the same handoff has failed the same way for two years, that a workaround someone improvised in 2021 has quietly become load-bearing, and that nobody can any longer explain why a particular rule exists.
That's the pattern I go after now.
I write about it monthly in The Issue Underneath the Issue.
Contact
Start with the real issue.
Tell me what's going on. I read every message myself.