Principal Engineer
I work on our video platform, which is really several products stitched together over the years. My job is making them work as one platform for the customers using them, the teams building them, and the people keeping them running. The work spans teams, systems, and leadership levels, connecting technical direction with delivery reality.
High-volume templated video where one creative fans out into many platform and market variants in long-running bursts across tenants.
The hard parts are fair scheduling, template-level reuse, and deadline-aware queueing under load that goes from idle to 50k+ requests in a second.
A tightly-coupled estate where shared databases, chained services, and deploy coupling meant one team's change could break another team's product.
Redrawing service and data boundaries so teams can ship independently, and pulling deploy coupling out of the critical path.
Three product platforms merging into one. The hard part was the data: three models that had to keep talking to each other while old customers stayed on the old systems and new ones came up on the unified surface.
Twelve teams, five months, and architecture decisions that couldn't break any account, especially the big ones sales was watching. Then took the unified system to global rollout.
Establishing the decision practices the org now runs on: ADRs, RFCs, and design reviews adopted across most teams.
Pushing end-to-end ownership of each domain into the teams that build it, with feature flags and CI/CD as the default delivery posture.
Helping shape the technical side of every roadmap at quarterly planning, with each domain's lead carrying the deep work.
Keeping twelve teams aligned on direction as the platform comes together, so the calls made in one domain don't break the others.
- I treat decisions as artefacts. If it's worth doing, it's worth an ADR. And if no one can find the ADR later, the decision didn't really happen.
- I'd rather make a domain boundary clear than perfect. Most architecture pain comes from fuzzy ownership, not bad code.
- I work hardest on the parts of a system that only a few people understand. Knowledge concentrated in heads is a load-bearing dependency, and I'd rather pay it down than route around it.
- I connect technical direction with delivery reality. Which mostly means saying no to clean architectures that won't survive contact with how teams actually ship.