A Through-Line
the arc
🏗️
Elegrity
Engineering Project Manager
2006 – 2009
🛒
eBay
Program Manager
2009 – 2011
🍎
Apple
EPM → Business Analyst & Process Engineer
2011 – 2018
🌿
Sabbatical
Deliberate pause
2018 – 2020
📊
Independent Consulting
Data Analysis for Community Nonprofits
2020 – 2024
🚌
SFMTA
Principal Business Analyst
2024 – present
Now
Each role contributed something the next one required. Managing projects → solving org-wide problems → translating complexity at scale. Nothing wasted.
Case Studies
three in depth
🔐
Program ManagereBay · 2009–2011
eBay Site Security Program
eBay Marketplaces' Site Security team had the right people but no shared map — no view of what was being worked on, no way for product teams to know when they needed a security review, no operating rhythm that scaled. I built the map, unblocked the intake, designed how the team showed up as internal consultants — and opened a cross-company conversation with PayPal's security org.
Process Design
Intake & Triage
Internal Consulting
Cross-org Collaboration
01Make the work visible
Built a roadmap so the team and its stakeholders could see what was on deck and when. Transparency turned out to be the missing prerequisite for everything that came after.
02Unblock the intake
Picked up a stalled questionnaire project and shipped it — a triage tool product teams could use themselves to identify whether their work needed security consultation.
03Operationalize the consulting role
Designed engagement processes so the team functioned better as internal consultants — clearer entry, clearer handoff, fewer surprises on either side.
04Open the cross-company conversation
Started a recurring discussion group with PayPal's security org. Both companies were learning the same lessons; this turned them into shared lessons.
The team stopped firefighting and started consulting. Product teams learned when to loop them in, and the work that mattered got the attention it needed.
🎵
Engineering Project Manager → Business AnalystApple · 2011–2018
Making iTunes' Crashes Countable
iTunes was crashing constantly, and my team — the site reliability engineers carrying the pagers — knew exactly why. New features kept shipping, bugs kept accruing, technical debt kept growing. We held post-mortems, but the results lived in Word documents nobody could aggregate or compare. Even the basic question, is downtime getting better or worse?, had no answer: every property measured it differently, every year measured it differently. Leadership kept prioritizing features over bug fixes because the conversation couldn't land on the bugs. The team knew. There was no data backing us up yet.
Incident Management
Dashboard Design
Process Creation
Business Intelligence
01Get the root causes captured consistently
Found a web-based outage system the team could use. Talked the owners into letting me add the fields we actually needed. Trained the SREs and convinced them — one at a time — to use it. Suddenly there was a record of why outages happened, not just that they had.
02Build the data pipeline — on a discarded machine
Stood up a MySQL prototype on a spare box, hooked it to Tableau, started shipping regular reports to management. Iterated on the format until it worked for the readers. Then rebuilt the whole thing properly online, using everything the prototype had taught me.
03Show leadership what the team already knew
Provided the visualizations for the monthly downtime reviews. The data said what the SREs had been saying for years: the majority of iTunes downtime came from bugs that were already tracked, just not fixed.
04The screenshot that changed the roadmap
A friend called from the iTunes offsite with a screenshot — one of my visualizations, up on the VP's slide. The VP was using it to tell the engineers that bug fixes were going to start coming before new features. It was a triumph.
I left Apple before the new roadmap played out, so there's no tidy number to point at. But iTunes crashes a lot less these days than it did when I was carrying a pager.
⚙️
Business Analyst / Process EngineerApple · 2014–2018
Kernel Updates for 500,000 Systems
At Apple, kernel-update tickets generated themselves by the hundred every day. The information that mattered lived inside spreadsheets attached to each ticket — outdated by the time anyone opened them, impossible to scan. Most managers had given up trying to act on them. Across 500,000 systems and 40+ engineering groups, the work was happening in the dark, and the people responsible for it were burnt out. I pulled on three threads at once.
Process Reinvention
Automation
Business Intelligence
Cross-functional Teams
01Surface what the tickets buried
A live dashboard pulled the at-a-glance state — what needed updating, what was failing, where the risk concentrated — out of the spreadsheet attachments and onto a single screen managers could actually read.
02Automate the work itself
Led the design of a new process that applied updates across the fleet at scale. Spotting what needed doing and actually doing it stopped being two separate hard problems.
03Renegotiate the bar
Brokered a new agreement between ops and infosec — replacing security requirements no one could realistically meet with ones engineers could actually deliver against.
Better security, and reverse burnout. Managers got a screen that showed exactly what needed doing; the work to do it was already automated; the bar was set where the team could clear it. Teams that had given up started knowing what they had to do — and being able to do it.
Notes, Essays & Side Quests
three lighter reads
🌿
Exploring and mapping the little-known public spaces hidden in downtown San Francisco. A love letter to the city — because understanding a place is its own kind of project management.
Explore the map →
🎲
If you test positive for malaria, how likely is it you actually have malaria? Many doctors get this wrong. An explanation without formulas — because making complex ideas accessible to decision-makers is the job.
Read the explainer →
🦄
In honor of Pride, I dug into Google searches for the word "unicorn." When were these searches most popular, where, and why? The answer surprised me.
Follow the search →