SENIOR TECHNICAL ACCOUNT MANAGER · PAYMENTS · FINTECH
The most interesting problems rarely come with a job description. I've spent 15 years at PayPal learning how to build the path while walking it.
// 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, building institutional knowledge in the trenches that most enterprise professionals never develop.
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.
That instinct for reframing problems showed up early. 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. From my background in physics I knew that Bluetooth operates over electromagnetic frequencies, and that certain metallic structures interfere with those signals. I asked the customer 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 representing a potential intrusion vector into PayPal's corporate network. I reported it. PayPal's security organization recognized the find formally. For someone whose background spans cybersecurity, payments operations, and technical account management, noticing what others don't isn't a job function. It's a disposition.
The depth of institutional knowledge that accumulates over fifteen years in one ecosystem is difficult to overstate. A colleague once spent a month working a support ticket across multiple internal teams trying to resolve an issue for a major global travel platform — reaching out through Slack channels, filing JIRA requests, getting no resolution. I answered it in minutes. Separately, two internal departments told a colleague that a critical PayPal tool had been decommissioned. I investigated independently, found it was still functioning, and used it to recover funds for a merchant affected by a platform incident — funds they would otherwise have lost entirely.
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 correctly framed — 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 correctly framed, 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 exists somewhere. What makes this useful professionally is fifteen years of building mental maps of how large organizations actually work — not the official version, but the operational one. 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, I think it's worth saying plainly: I understand what it means to be trusted with things that matter.
// UNDER PRESSURE
There's a specific kind of professional situation that most people are not equipped to handle — 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.
The most sustained crisis I navigated involved two high-profile enterprise merchants simultaneously experiencing the same critical internal error — a payout file that had been scrambled, sending wrong amounts to wrong recipients with incorrect metadata attached. Over $600,000 in payout volume was affected. Both merchants were catastrophizing in real time. Churn was threatened explicitly.
I did two things in parallel that week. The first was human — I slowed the pace of every conversation deliberately. I separated what was actually known from what was being assumed. I educated both merchants on their real exposure and gave them my word that PayPal would not leave them at a loss for an error we had caused. I held that commitment through every subsequent call while the solution was still being built.
The second was forensic. I reverse-engineered the corrupted payout file from the ground up — reconstructing which amounts belonged to which recipients, restoring correct metadata, and building a reconciliation file that made both merchants whole. It took the better part of a week. Both merchants remain customers.
"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 COLLEAGUEThe answer always exists somewhere 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
Three-year engagement with a high-value merchant at churn risk. Led weekly fraud review calls, redesigned internal client processes, and advised on webhook and transaction data utilization. Reduced fraud losses by more than 23% year-over-year. Retained the client.
What the number doesn't show is what surrounded it. During that final engagement year I was simultaneously completing my cybersecurity degree, preparing for the CompTIA Security+ certification exam, and actively working to grow professionally inside PayPal. A colleague who observed the work noted at the time that the quality of my engagement had only improved throughout the process. I don't include this to impress. I include it because it tells you something about how I operate when the stakes are highest and the bandwidth is thinnest.
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.
Over $600,000 in payout volume scrambled by an internal error — wrong amounts, wrong recipients, wrong metadata. Two enterprise merchants threatening churn simultaneously. Reverse-engineered the corrupted file from the ground up, rebuilt the reconciliation from scratch, and managed both merchant relationships in parallel throughout the week-long resolution. Both merchants remain customers.
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 efficient thing I can do is not solve the next problem myself. It's make 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 compounding effect is 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.