Giving teams a paved path

The problem

Eventbrite’s core product experience ran through a large Django application called Core. It handled requests, authentication, sessions, application context, and direct database access. Releases happened only two or three times a week.

After incidents and site outages, leadership introduced an exception process requiring approval for changes to Core. Teams were often asked to find another way to build, but they still needed to ship.

I built Frontend Enablement in a quarter to help provide that alternative. I brought in engineers who understood the legacy codebase and hired for the infrastructure expertise we needed.

Turning a migration into a roadmap

Leadership initially wanted our team to migrate Event Listings, a high-traffic page, end to end to prove the new architecture.

I had the team investigate the migration and break it into a work breakdown structure. That exposed capabilities other teams would also need: data aggregation, application context, authorization, deployment, and monitoring.

I worked with the principal engineering community to build support for delivering those capabilities first. We prioritized the roadmap around the product work it would unblock and negotiated requests that would have turned us into a bespoke migration team.

A central piece was standalone backends-for-frontends, or BFFs. Teams could build that layer in Next.js, call service APIs, and move data aggregation and application context out of Core.

Leading across teams

We brought the shared capabilities together in Valkyrie, our paved path for building outside Core. It supported AWS Fargate, Lambda, and static hosting, with reusable infrastructure, CI/CD, environments, and observability.

I coordinated dependencies with the Identity team as they migrated to Auth0, agreeing on ownership and sequencing. When architectural views differed, I helped engineers work through the tradeoffs and reach decisions. I kept leadership informed about delivery risks, capacity, and decisions that needed their involvement.

When the broader program slipped, I helped identify the causes, reset ownership and sequencing, and restore a credible delivery plan.

Within my team, I gave staff engineers ownership of major workstreams and opportunities to influence decisions at the principal-engineering level. I coached them on proposals, stakeholder communication, and presenting architectural decisions.

Written decisions, clear ownership, and handoffs helped our distributed team make progress across time zones without depending on my availability.

Making adoption sustainable

I treated adoption as part of the product.

Every sprint, we recorded demos and I published an internal engineering blog covering what shipped, what was next, and which decisions were still open. I credited contributing engineers by name and invited teams to influence the direction.

Office hours, technical deep dives, self-service guides, and a playground repository helped teams get started. Early-adopter feedback changed our priorities, while we balanced individual project needs against capabilities other teams could reuse.

We clarified what product teams would own and what Frontend Enablement would support. We also established support practices that kept adoption work from overwhelming planned delivery.

I looked beyond repository counts to whether teams were launching successfully and becoming less dependent on us.

What changed

The platform grew from one proof of concept to 29 repositories in three quarters, and more than 80 the following year. It became the standard for new web projects.

Application setup fell from roughly ten days to one. Standing up a BFF went from six weeks to two days, while deployment time dropped from about an hour to approximately 15 minutes.

Commits to Core fell 50% year over year. The exception policy was an important forcing function; our contribution was giving teams a practical alternative.

The product team responsible for Event Listings eventually migrated it themselves, improving page load times and reliability. That validated the sequencing decision: domain teams could own their migrations using the capabilities we had built.

What I would carry forward

Infrastructure was only part of the migration cost. Existing frontend code lived in a monorepo with shared dependency versions and global CSS. Moving applications also meant making that code portable.

We started a foundations repository to publish shared components and reduce that work. Frontend Enablement was disbanded amid broader business headwinds before it reached critical mass. During the transition, I helped transfer ownership and knowledge so teams could continue using the platform.

My biggest lesson was that an internal platform has two products—the destination architecture and the path teams take to get there.

I would address application portability earlier alongside infrastructure. I would also preserve the open communication, feedback loops, and investment in technical leadership that helped teams adopt the platform and take ownership of their work.

Back to the career journey