Work · Nike · 2022 – present
Privacy consent platform work
Most people see privacy as a setting. My work has been the backend side: services, data contracts, release paths, monitoring, and audit trails that make those choices behave consistently.
Selected outcomes
- Owned day-to-day backend and platform work for consent services used by consumer product surfaces.
- Moved a major API path to a new ingress pattern through phased rollout and rollback testing.
- Designed and ran a regulated data migration against a fixed compliance deadline.
- Helped raise the security floor across service repositories, build checks, and dependency remediation.
- Built check tooling that made on-call preparation easier for other engineers.
What it does
The platform is a source of truth for consent and preference state: which policy applies, what the user chose, which surface collected the choice, and which downstream systems need to honor it. The important property is not just storage. It is whether engineers can trace the decision later without guessing.
The shape of the work splits roughly four ways: keeping the read path available, keeping the write path correct, evolving the data model for new regulations as they land, and making the platform understandable for future engineers.
Things I've owned end-to-end
A small selection. I can share more detail privately where it is appropriate.
Moving a production API to a new ingress path
Moved a major API path onto a new ingress pattern. The rollout used phased traffic shifts, pre-written rollback plans, and production validation at each step. Security hardening landed on the same path, so the migration improved both the operating model and the control posture.
Running a regulated data migration
Compliance work required a large population of consent records to move through a fixed renewal path. I handled spike research, pipeline design, staged rollout, validation against source-of-truth queries, and documented rollback. Wrote up a separate piece on this: the regulated migration case study.
Building an event-driven service
Designed and shipped an event-driven service around consent-record changes. The important work was not only the handler. It was the contract, test coverage, deployment path, and operational behavior around it.
Raising the security floor
Helped move a service portfolio toward stronger build maturity: dependency scanning, static analysis, credential exposure checks, infrastructure checks, and remediation of the resulting backlog. Coordinated across teams to land changes in dependency order.
Check tooling for on-call preparation
Built a small tool that checks the health signals that matter before on-call and surfaces what drifted overnight. It started as a personal tool and became useful enough for teammates to adopt.
What I've learned
The useful work is usually the part someone else has to live with.
A few things I would keep carrying forward:
- Distributed systems need a failure story. Every "just deploy it everywhere" assumption needs a matching story for disagreement, rollback, and ownership.
- The integration layer is real work. API contracts, deploy pipelines, observability, runbooks, and service boundaries are what make product changes repeatable.
- Regulatory deadlines force clarity. A hard date makes the plan concrete and exposes the parts that are still hand-wavy.
- Cross-team coordination is engineering work. A broad migration has to be sequenced, communicated, and rollback-ready. The code is only one part of the work.
What I'd do next
If I owned this platform for another two years, I would push hardest on three things: tighter contracts at the service boundaries, stronger failure-mode rehearsal, and a clearer story for how AI-assisted developer tooling fits into on-call work without taking ownership away from the human on call.