SENIOR TECHNICAL ACCOUNT MANAGER · PAYMENTS · FINTECH
The most interesting problems rarely come with a job description. I've spent 15 years at PayPal figuring out what nobody asked me to figure out — and delivering it anyway.
// BACKGROUND
I joined PayPal in customer service. Within that first role I noticed that our teams had no repeatable framework for supporting our first mobile payment product. I built one. It became the team standard, and I was recognized as one of fewer than a dozen Process Specialists in the organization — the final escalation point for the most complex customer contacts we handled. I spent a decade in general operations, picking up institutional knowledge that most enterprise professionals never get close to.
In 2019 I was selected to pilot a new enterprise-facing operational model — a transition that moved me from supporting the general public into working directly with PayPal's largest managed merchants. I've been in that space ever since. That foundation decade isn't a detour. It's the reason I can navigate problems that most enterprise peers have never seen from the ground level.
A customer — a small business owner trying to launch a side hustle with PayPal Here — couldn't pair their Bluetooth card reader. Four agents had already tried and failed before the call reached me. I ran every standard approach — Bluetooth resets, app reinstalls, software updates, device reboots. Nothing. An hour in, I was exactly where the first agent had been.
So I stopped looking at the device. I started looking at the environment. I knew from physics that Bluetooth operates over electromagnetic frequencies and that certain metallic structures block those signals. I asked the merchant to describe their surroundings. Metal-framed furniture. A table and chair with a grid-like base — effectively sitting inside a Faraday cage.
I asked them to move to a different room and try again. It worked immediately. The device was never the problem. The environment was. The only way to find that was to stop solving the problem everyone else had been solving and ask whether the problem itself had been correctly identified. That question has shaped how I approach every complex situation since.
That instinct isn't limited to merchant problems. At PayPal's Scottsdale office, while others moved through their day unaware, I noticed an unfamiliar network appearing as an available connection on my phone — a rogue wireless access point, a potential intrusion vector into PayPal's corporate network. I reported it. PayPal's security organization recognized the find formally. Noticing what others don't isn't a job function. It's a disposition.
On the Specialist Desk — the enterprise pilot program I joined in 2019 — I identified critical gaps in a multi-currency withdrawal product and built a direct feedback loop with the product management team. A channel that didn't exist before because it needed to exist. As an Enterprise Servicing Manager, I spent four months coordinating between a major media company, multiple seller risk teams, and a data science division to deploy custom fraud mitigation rules. Most people in my role would have stopped after the second unanswered request. I didn't. The rules went live. The merchant was satisfied.
Fifteen years in one ecosystem builds a kind of knowledge that's hard to transfer on a résumé. A colleague once spent a month working a support ticket across multiple internal teams — Slack channels, JIRA requests, no resolution. I answered it in minutes. Separately, two internal departments told a colleague a critical PayPal tool had been decommissioned. I checked independently, found it was still running, and used it to recover merchant funds that would otherwise have been lost entirely. These aren't exceptional days. They're Tuesday.
I'm currently a Senior Technical Account Manager supporting enterprise merchants across PayPal and Braintree — and mentoring newer team members on the operational fundamentals that took me years to develop.
// HOW I THINK
When a problem resists every standard approach, most people apply more pressure to the same approach. I do something different. I step back and ask whether the problem has been framed right — because a well-framed problem is usually most of the solution.
This isn't skepticism. It's a discipline developed across fifteen years at PayPal — a decade in general operations followed by six years in the enterprise space — navigating situations where the documented expectation and the actual output had quietly diverged, and everyone around me was troubleshooting the wrong thing. I've escalated situations where products weren't behaving as documented — not because I read the documentation more carefully, but because I had enough hands-on experience to recognize when reality and the spec had parted ways. Most people trusted the documentation. I trusted what I could observe.
Once the problem is framed correctly, I think in paths. When one closes, I find another. As long as options remain, I stay in the game — not out of stubbornness, but out of a quiet certainty that the solution is somewhere. Fifteen years of building mental maps of how large organizations actually work — not the official version, but the operational one — is what makes that useful. Where exceptions get made. Who has the authority to make them. How to frame a request so it reaches the right people.
01
Stop solving the problem everyone else is solving. Ask first whether the problem has been correctly identified. The answer is usually hiding one level up.
02
Move across teams and silos without losing the thread. Organizational complexity is navigable when you understand how it actually works — not how the org chart says it works.
03
Closing the gap is the only metric that matters. Persistence without delivery is just stubbornness. I stay in the game until the outcome is real.
// INTEGRITY
There's something I've found matters more than most people talk about openly at the senior level: trust. Not the kind you claim. The kind that gets tested.
Before PayPal, I spent five years at IKEA as a closing supervisor in the cash department. I held keys to two safes, secured nightly cash deposits, and was responsible for arming the building before leaving each night.
When a deposit went missing and a scandal unfolded that ended the employment of everyone else in the department, I was the only person who remained.
// MY INTEGRITY WAS NOT QUESTIONED.
I've carried that same standard into every role since. Colleagues have consistently trusted me with sensitive information, confidential situations, and problems they couldn't bring to anyone else — not because I asked them to, but because trust is either present or it isn't.
At the level where compensation reflects genuine responsibility, that matters: I understand what it means to be trusted with things that matter.
// UNDER PRESSURE
There's a type of situation most people aren't built for — the one where the error is already made, the client is already angry, the financial exposure is real, and the answer doesn't exist yet.
I've been in that room more than once.
When two multi-billion dollar public companies had their funds frozen after erroneously triggering a programmatic rule, I was called in despite having no direct involvement with either account. Working with a colleague, we identified the internal error, corrected it, and restored access — doing so, as a colleague later noted, "with a sense of humor, broad skillsets, and tons of empathy."
The merchants were taken care of. The error didn't repeat.
// TWO MULTI-BILLION DOLLAR ACCOUNTS. RESOLVED SAME DAY.
One week. Two enterprise merchants. Two different critical errors. Both mine to resolve.
The first: a major retail merchant whose authorization batch had been processed against the wrong account — then duplicated, then had the wrong set voided. The authorization state was a mess. There was no clean path forward without building one from scratch. I reverse-engineered the full authorization picture, reconstructed the correct state, and built a reconciliation that untangled thousands of affected transactions.
The second was a different kind of forensic problem. Over 4,750 transactions had been re-run against expired authorizations and assigned incorrect reference numbers — $737,271.44 in capture volume with corrupted metadata. The money reached the right customers in the right amounts. But without correct reference number mapping, future refund processing would have failed across the entire batch. I built a custom lookup table that restored the correct mapping.
I delivered both resolutions the same week. Sole author of both.
When it was over, I didn't move on. I wrote the postmortem for each incident and drafted the process controls that followed — control validation procedures, standardized output formats, escalation protocols. Both became team standards. A crisis that ends without reform is just a crisis that hasn't happened again...yet.
"Todd was brought in on a limb and he really stepped up. He helped with the identification of the issue, the reconciliation, and the root cause analysis. What a tremendous lift — you are mythical."
// PAYPAL COLLEAGUEThere's always an answer in what's actually known. The job is finding it before the room loses faith that it's there — and staying calm enough to keep looking.
// SELECTED OUTCOMES
A colleague spent over a month working a complex reporting issue through multiple Slack channels and a JIRA ticket across several internal teams — getting no resolution. I resolved it in minutes. The gap between what I know and what the standard escalation path can access is the result of fifteen years of paying close attention to how the system actually works.
Tapped outside my portfolio to assist on a pressing escalation involving a US federal government strategic partner. Personally led a 2+ hour live configuration call, walking each user through authenticator app setup to secure their accounts — zero margin for error on a high-visibility relationship. Outside my scope. Done because it needed to be done.
Led the onboarding of one of PayPal's largest multi-currency withdrawal merchants — $10 million TPV in indirect attribution — coordinating across product, tech, and design teams across multiple time zones. Recognized org-wide as the go-to expert for MCW configuration and onboarding, having trained significant portions of the Specialist Desk on this complex capability.
Coordinated across seller risk teams and a data science division to build and deploy custom transaction-level fraud rules. Most peers stopped filing requests after the second attempt. I kept going until the right team was found. The rules went live. The merchant was satisfied.
Awarded "Peer of the Year" by colleagues — a peer-elected designation, not a management award. Combined with being named one of fewer than a dozen Process Specialists earlier in my career, formal peer recognition has followed me across every role I've held. Peers don't recognize people out of obligation. They recognize people whose presence makes their work materially better.
Selected as one of two ICs to pilot a new operational support model for account managers. Established white-glove service standards and documented repeatable workflows that supported scaling across US, UK, EU, and APAC regions.
Built the first troubleshooting framework for PayPal Here, the company's initial mobile payment product, after identifying that no repeatable support methodology existed for its most common contact type. Framework adopted as team standard. Recognized as one of fewer than a dozen Process Specialists — the final escalation point for the most complex contacts in the organization.
// DEVELOPING OTHERS
I've been developing people informally for most of my career — in call centers, on specialist teams, and now across a global TAM organization. No formal mandate. No direct reports. Just a belief I've held since early on: the most useful thing I can do isn't solving the next problem myself. It's making sure someone else can solve it too.
I can only work on one thing at a time. But every person I bring along creates another person who can work on something simultaneously. And each of them can do the same. That's why I've always shared knowledge freely — documentation, walkthroughs, screenshare sessions, quiet conversations after difficult calls.
Most people who bring a problem already know more than they think. A couple of steering questions at the right moment and they find their own answer — one that sticks in a way a handed-down solution never does.
The difference between performed empathy and genuine perspective-taking is the gap between what someone asks for and what they actually need. I teach people to find that gap. It changes how they work.
Knowledge that lives only in someone's head disappears when they leave the room. I build things that outlast my direct involvement — frameworks, documentation, tools — because that's how knowledge actually scales.
If you found this page because someone I worked with sent you here — that's exactly what this section is about. The door is open.
If you're a recruiter or hiring manager reading this — this is what it looks like when someone develops people without being asked to. It tends to show up everywhere they go.
// LET'S CONNECT
I'd welcome the conversation. No friction — reach out whichever way works best for you.