~90-second spoken pitch
At NetApp I’m in the partner and channel space, and I run two things in parallel. One is a vendor data-warehouse migration — managing the integration and the source-to-target mapping as we move off one vendor’s platform. The other is partner-marketing attribution, the MDF program — figuring out what every partner-marketing dollar actually sourced.
That’s a messy data-hygiene problem: partner and customer names come in free-text, multi-language, across marketing, CRM, and ERP, and none of it joins cleanly. I designed the matching logic — fuzzy matching with confidence thresholds — that resolved hundreds of thousands of records to real accounts, with a human-review queue for the ones the system wasn’t sure about, so a bad match never drove a payout.
Day to day I’m gathering stakeholder requirements, owning the roadmaps, and keeping partner ops, data engineering, and marketing aligned. And I lean on my own AI workflows to compress the front end — turning thirty-plus stakeholder interviews into a prioritized roadmap in days.
Questions I must be able to answer
Partner MDF program · tap a question to reveal a strong answer
Frame it as a programOne core idea underneath every answer: I took a messy, ambiguous global data problem and turned it into a structured, trusted, repeatable technical capability leadership could use to make decisions. Lead with the program; use the technical depth to prove I understand it, not to become the story.
Why was this a program, not simply a dashboard project?
Testing: Do you see the difference between output and capability?Because the dashboard was the last 10%. The real work was connecting fragmented investment, pipeline, and identity data across three enterprise systems, seven currencies, and three regions — and doing it reliably enough that leadership would move money on the result. That’s a program: multiple workstreams, cross-team dependencies, technical decisions, quality controls, and a repeatable operating model. A dashboard was the surface; the program was everything that made the number underneath it trustworthy.
What exactly did you own?
Testing: Are you a tracker or an owner?I owned the program end to end — problem framing, scope, decomposing it into six workstreams, the roadmap and refresh schedule, translating leadership’s questions into technical capabilities, stakeholder alignment across partner ops, data engineering, marketing ops and channel finance, dependency management, the key technical decisions, the data-quality and exception strategy, reconciliation, the monthly operating cadence, and the enhancement backlog. I also designed the identity-matching logic myself.
How hands-on were you?
Testing: Depth without overclaiming being the sole engineer.Hands-on where it improved program decisions. I designed the matching logic — the cleansing, country blocking, and confidence scoring — wrote SQL and Python for harmonization and the resolution pipeline, built the touch→account→pipeline model, and personally investigated reconciliation issues. I went deep enough to challenge assumptions and evaluate trade-offs, but my primary job was leading the program, not being the engineer of record on every component.
What did engineering own versus what you owned?
Testing: Clean ownership boundaries — no overclaiming.Data Engineering owned production pipeline implementation, orchestration, and the technical data-quality plumbing. Source-system owners (Salesforce, SAP) owned the account masters and access. Regional partner operations owned the manual exception review. I owned the program — requirements, the matching design and business rules, dependencies, decisions, quality thresholds, reconciliation, cadence, and the reporting leadership consumed. I coordinated four teams: partner ops, data engineering, marketing ops, and channel finance.
Why didn’t you use a more sophisticated ML attribution model?
Testing: Judgment over resume-padding.Because partner leaders had to defend every credited dollar in a review. A Markov or Shapley model would have looked more sophisticated and been a black box — nobody could explain why a specific partner got credit. I chose a rules-based, account-based model where every credited dollar traces to a specific touch and account. The ‘less sophisticated’ choice was the correct one, because an attribution number leadership won’t stand behind is worthless.
Why did explainability matter?
Testing: Do you connect a technical property to business adoption?Because the output drove money. Explainability was the difference between a number leaders would act on and one they’d quietly ignore. When a partner asked ‘why was this credited to me?’, the answer had to be a specific touch tied to a specific account, not ‘the model said so.’ Explainability was a business requirement disguised as a technical property.
How did identity resolution work?
Testing: Can you explain the core mechanic simply and correctly?Each free-text company name in a partner touch had to be resolved to a real CRM account. I cleansed the names (stripped legal suffixes and words that appear in over 0.5% of names), standardized country to ISO codes and translated non-Latin scripts, then blocked candidates by country so I only compared within the same country. I scored the remaining candidates with six similarity metrics combined by a harmonic mean — so one flattering metric couldn’t carry a bad match — added a city/country tie-break, and kept the single best account per touch so nothing double-counts downstream.
How did you determine the confidence thresholds?
Testing: Threshold-setting as risk management, not arbitrary numbers.By the cost of being wrong. Because a false positive drives a wrong payout and a skewed investment decision, I set the bar conservatively: high-confidence scores auto-resolve (~82–85%), records scoring roughly 0.60–0.79 route to a human review queue, and anything below ~0.60 is held as unattributed rather than force-matched. The thresholds were calibrated to keep confident wrong answers out, not to maximize the match rate.
What happened to the unmatched 15–18%?
Testing: Did you hide the long tail or manage it?It was managed, not hidden. The middle band (0.60–0.79) went to regional partner operations for manual verification — borderline cases went to a person, not an algorithm guessing. Anything below the floor was tagged ‘Unattributed Partner Spend’ and shown as its own line in the reporting, so leadership saw the true size of what we couldn’t attribute. An honest gap protected the credibility of everything above it.
Why was a false positive dangerous?
Testing: The core risk principle of the whole program.Because leadership was using the output to make investment and payout decisions. A false positive quietly credits the wrong partner and skews where the next MDF dollar goes — and it’s invisible, so no one catches it. An unresolved record is at least visibly unknown. So a false positive was more dangerous than a missing match, and the entire control model was built to avoid confident wrong answers rather than to chase a higher match rate.
What was the hardest dependency?
Testing: Do you understand where the program was most fragile?Harmonization, because it’s invisible when it’s wrong. Everything downstream compares on the standardized geography, currency, and taxonomy — so a quiet harmonization error silently degrades match quality, which degrades attribution, which erodes trust, without ever throwing an obvious error. Identity resolution was the highest-stakes dependency, but harmonization was the hardest to manage precisely because its failures are silent.
How did you manage data quality?
Testing: Quality as a system, not a hope.With a control model and gates. Match confidence was scored and surfaced; high confidence auto-resolved, medium went to human review, low was held. Every monthly cycle had validation gates — match-quality validation plus spend and pipeline reconciliation — that had to pass before anything published, so no unreconciled number ever reached leadership. And I surfaced confidence and the unattributed line in the output itself, so quality was visible, not asserted.
How did you build stakeholder trust?
Testing: The signature lesson of this program.Not by claiming the data was perfect — by making the uncertainty visible and manageable. Partner leaders had been burned by numbers that didn’t reconcile before, so I surfaced match confidence, showed the unattributed slice honestly, reconciled spend and pipeline every cycle, and made the same number mean the same thing in every region’s view. Trust came from showing the seams, not hiding them.
How did the three source ecosystems depend on one another?
Testing: System-level understanding of the data flow.The partner-marketing system held the touches and funding claims — the spend side. Salesforce held the account master and the pipeline — the outcome side. SAP contributed account/financial context. None of them shared a key, so the whole program hinged on resolving the marketing side’s free-text names to the CRM’s account master, then joining to that account’s pipeline. Marketing gave me the investment, CRM gave me the return, and identity resolution was the bridge between them.
How did you prioritize work?
Testing: Sequencing logic, not gut feel.By dependency and by what unlocked trust. Sources and harmonization came first because everything else compares on them; identity resolution next because it’s the make-or-break join; then attribution, then reporting. Within that, I prioritized the decisions that most affected whether leadership would trust the output — explainable attribution and the confidence/exception model — over cosmetic dashboard work. On the front end, I used my own AI workflows to turn 30-plus stakeholder interviews into a prioritized roadmap in days.
How did you track the roadmap?
Testing: Concrete delivery mechanics.I ran the roadmap, the monthly refresh schedule, and the enhancement backlog in Asana, and mapped it into the wider program plan in Microsoft Project so it stayed visible alongside the broader partner-marketing calendar. The backlog was prioritized and worked over time, so the capability kept improving rather than decaying.
How did the monthly operating cycle work?
Testing: Do you run a repeatable capability, not a one-off?Data refresh, pipeline execution, match-quality validation, spend reconciliation, pipeline reconciliation, exception review, Tableau publication, leadership consumption, then enhancement backlog — and repeat. The two reconciliation steps and the match-quality validation were gates: nothing published until they passed. That’s what turned a one-time analysis into a standing capability that produced the same trusted number every month.
How did you measure success?
Testing: Honest outcomes, not inflated metrics.The honest measure: partner leadership went from no trustworthy MDF attribution to a single monthly view they actually used to judge partner and regional performance and steer investment — 460K+ touches resolved, three systems and seven currencies reconciled, ~82–85% auto-resolved with the rest managed transparently, reconciliation variance explained each cycle. I deliberately don’t attach an inflated ROI multiple; the dashboard sample figures illustrate the layout, not a validated business result.
What was the most difficult decision?
Testing: Can you defend a hard trade-off?Keeping an explicit ‘Unattributed Partner Spend’ line instead of forcing every record to a match. Forcing 100% would have produced a tidier dashboard and a wrong one. It was uncomfortable to show leadership a visible gap, but it was the decision that protected the credibility of every number above it — and paired with explainable attribution over a black-box model, it’s the choice that made the platform trusted.
What would you do differently?
Testing: Reflective, senior, specific.I’d formalize data-quality observability earlier. My reconciliation and confidence controls caught problems, but a lot of it was run through a disciplined monthly cycle rather than automated monitoring. On a bigger program I’d instrument the harmonization and match-quality layers with automated checks and alerting from the start, so silent degradation is caught by the system, not by me during the monthly QA.
What would break if volume increased 10x?
Testing: Do you understand the scaling limits of your own design?Three things. The comparison space — already why I block by country; at 10x I’d need more granular blocking and incremental, delta-only matching instead of reprocessing everything. The human-review queue — a fixed team can’t manually verify 10x the borderline records, so I’d add ML-assisted triage to pre-sort the queue and auto-clear the easy ones. And the monthly manual reconciliation — that wouldn’t scale, so I’d automate the reconciliation and DQ gates with proper orchestration and observability. The explainable attribution model itself scales fine; the bottlenecks are matching compute, human review, and manual QA.
How would you run this as a larger multi-team platform program?
Testing: Can you scale the program, not just the pipeline?I’d turn the six workstreams into owned tracks with named leads — data engineering, identity/matching, analytics/semantic layer, partner ops for exceptions — and add real governance: a decision log, a RAID register, and stage gates for data quality and release. I’d put a governed semantic/metrics layer over the attribution so definitions are shared and versioned, replace the monthly manual QA with automated DQ and observability, formalize the operating model with SLAs and on-call for the pipeline, and keep the same principle at the center — explainable output with visible uncertainty — because at platform scale, trust is still what makes it get used.