Leading BNPL platform engineering at PayPal

Role

Senior Engineering Manager, BNPL platform

Span

From a seven-person team to a first-class partner on the core checkout platform

Scale

~$40B in annual platform volume across international markets

Headline outcomes

Maintainer standing in the shared checkout codebase in two quarters · review cycle from two weeks to ship-when-done · 4× experiment throughput driving $180M incremental TPV

I joined PayPal's Buy-Now-Pay-Later team in 2022 to lead seven engineers with an ambitious credit product roadmap and no reliable path to ship it. Every change we owned ran through the company's core checkout codebase, a domain where we had no independent standing. As with any critical shared codebase, changes from outside teams moved through conservative, high touch review, and our pull requests sat behind weeks of manual walkthroughs. Priority depended on relationships rather than an agreed process, and our delivery speed depended on the goodwill we could borrow rather than on any process we controlled.

The deeper problem was that no one had defined what my team actually was: what we owned, what we were accountable for, and on what terms we were allowed to touch a codebase the company depended on to keep running. Until that was settled, every delivery conversation kept collapsing back into a negotiation. My goal was to stop operating as a supervised guest in someone else's codebase and become a first-class engineering partner with standing of our own.

I went to the platform's leadership first, not with a technical proposal but an organizational one, deliberately lopsided: we would make no claim on ownership of their codebase, their architecture, or their roadmap, and in return they would treat my engineers like new hires on their own team, with the same onboarding, the same access, and the same ramp up anyone joining their team would get. I paired that with a single point of accountability: if something we shipped broke, my team took accountability for it, not a platform engineer who happened to approve the pull request. Over the next two quarters we earned that access in the open. The team worked against both our own roadmap and the platform's, junior engineers carried genuine capacity against the platform team's own goals, and relationships formed at the staff engineer level so the technical trust ran peer to peer. Then I proposed a one quarter probationary period and invited extreme scrutiny of everything we shipped, because a team that welcomes hard review is a team you stop needing to police. Once the model held, I wrote it up as a repeatable ladder of trust: the concrete stages a partner team moves through, from supervised contributions to full maintainer standing, so the next team would not have to reinvent the path we had walked.

Within two quarters my team held maintainer standing and owned production issues end to end. The review cycle went from a two-week walkthrough to ship-when-done, which roughly doubled our project output inside the shared codebase. After full integration, the team delivered four times as many experiments per quarter, generating nearly $180M in additional total payment volume. The onboarding program we built grew the platform's contributor roster to twenty engineers across multiple teams through a quarterly intake, and the following year my team was named a critical partner on a ground-up overhaul of the checkout experience.

There is more to this story than fits on a page: the failures along the way, what I would do differently, and how the framework traveled. If it resonates, I would genuinely enjoy comparing notes. Find me on LinkedIn or email me directly.

Back to selected work