Real problems solved — through clear thinking, process design, and a good question or two.
A Through-Line
the arc
Managing projects → solving org-wide problems → putting it all into public service.
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. The work in progress was invisible, product teams couldn't easily tell when they needed a security review, and the group's way of working didn't scale. I built the map, smoothed out the intake, designed how the team showed up as partners, not obstacles — and opened a cross-company conversation with PayPal's security org.
Process DesignIntake & TriageInternal ConsultingCross-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.
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 handed the prototype off to my team — the logic, the data model, all of it — and led them in building the production system properly online.
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 my people carried pagers.
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 ReinventionAutomationBusiness IntelligenceCross-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 deployment 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.
Downtown San Francisco hides public gardens on its rooftops and inside its office towers — the kind you reach by walking past a security guard to an unmarked elevator. A coworker showed me my first; I've been tracking them down and mapping them ever since.
If you test positive for malaria, how likely is it you actually have malaria? Many doctors get this wrong. Here's the intuition, without a single formula.
