Skip to content
ale@portfolio:~/portfolio$ cat README.md

portfolio

Every case study here answers one question: measurable outcome.

lighter-tracking-library.mdZapier

Lighter Tracking Library

ShippedTeam: Data + Eng
TL;DR

Rebuilt the tracking library from validated requirements only, cutting the effort to add eventing to any new microservice.

Outcome

  • ↓effort to add eventing to a new microservice
  • ↑library portability and compliance with current eventing rules
Saw It
  • The tracking library had passed through multiple owners over the years, picking up weight with every addition.
  • Direct engineer feedback on pain points with the existing library, plus a mapping exercise that showed which components no longer earned their place.
↓
Figured It Out
  • Validated every component against current requirements before deciding what to keep.
  • Weighed a full rebuild against a targeted trim, chose rebuild since legacy pieces were tightly coupled.
  • Ran working groups with engineers to technically evaluate alternatives before committing.
↓
Did It
  • Shipped a lighter, portable, expandable library after a POC.
  • A secondary legacy library turned out to be just as heavy as the one being replaced, with undocumented use cases. Some services had to run both libraries for a transition period, not ideal, but manageable.

My Role

Owned the requirements validation, the roadmap, and the POC. Partnered with engineers directly through working groups to evaluate technical alternatives.

Full breakdown

Problem & Risk

Usability RiskFeasibility Risk

A heavy, hard-to-implement tracking library was slowing down every team adding eventing to a new microservice. Risk was continued organic growth making the problem worse over time.

Customer Discovery & Validation

Evidence

Built two inventories, tracking needs across teams and tracking functions across sub-libraries, then mapped one against the other to find real gaps versus assumed ones.

Context

Over the years the tracking library changed owners and grew heavy and difficult to implement. We validated each component against current requirements before rebuilding.

Timeline

git log --oneline⏱ phased rollout
kickoff: legacy library too heavy, no clear ownershipPhase 0
discovery: inventoried tracking needs and functions, mapped gapsPhase 1
ship v1: POC launched after technical evaluation of alternativesPhase 2
feedback: legacy library still required for some servicesPhase 2
next: rolling out service by service with developer supportNext

What We Did

  • Gathered engineer feedback on pain points with the existing library
  • Built and cross-referenced two inventories: tracking needs and tracking functions
  • Ran working groups to evaluate technical alternatives
  • Built the roadmap, launched a POC, turned feedback into Jira tickets
~ rough sketch, not an actual screenshot ~

heavy legacy library

inventory needs + functions

gap mapped

POC

lighter, portable library

Who Benefits

Teams get a library that's easy to use and fully compliant with current eventing rules, cutting the time to add tracking to any new microservice.

Next Steps

Rolling out service by service, with dedicated support time from the library's own developers.