The Orchestrator of Scale

Most people describe their career as a progression. Mine is better described as a system.

I’ve worked across design, front-end development, marketing, product management, and operations — not because I couldn’t pick a lane, but because I kept finding the same problem in every lane: the work was fine, but the infrastructure holding it together was broken.

That’s what I fix. I’m a systems thinker who specializes in building the connective tissue that allows large, complex organizations to act with intention — consistently, at scale, without burning out the people doing the work.

I don’t do it alone. The best governance frameworks, design systems, and operational models I’ve built came from pulling the right people into the room early — not to approve a decision, but to pressure-test one.

When process became the product

The project that crystallized how I think was a global migration across 500+ pages for BBVA — a financial institution operating across multiple international markets, each with its own teams, priorities, and constraints.

The instinct would have been to hire more designers. I stopped and asked a different question: why is the workflow broken?

I stopped designing pages and started building the pipeline. The real deliverable wasn’t the website — it was a federated system that let local teams in different countries deploy compliant, high-performance pages without needing central approval for every pixel. Governance, not gatekeeping. Speed through structure, not despite it.

That project taught me that DesignOps is the ultimate risk-management tool. If the process is governed, the output is guaranteed.

Why complex organizations

The organizations I'm drawn to aren't broken — they're grown. They started with good instincts and talented people, and then they scaled. And somewhere in that scaling, the infrastructure didn't keep up.

Maybe it's a design team that tripled in size but still operates on tribal knowledge. Maybe it's a brand that spans dozens of departments or markets, each interpreting the standards differently. Maybe it's a retail operation that needs to run like a larger organization than it actually is.

The pattern is always the same: the work is fine, but the system holding it together is improvised. That's the moment I'm most useful.

I build federated models — shared infrastructure that protects the core standards while giving the people doing the actual work enough autonomy to move. Not compliance through control. Consistency through empowerment.

How I approach problems

I plan for systems, not scenarios.

Scenarios change — budgets shift, stakeholders rotate, priorities pivot. A plan built around a specific scenario breaks the moment the scenario does. A system built around principles adapts. That’s the difference between a workflow that survives one project and one that outlasts the person who built it.

But a system no one helped shape is a system no one will protect.

Before I design anything, I map the people it will touch — the ones who will use it, the ones who will maintain it, and the ones who will push back on it. I bring them into the process early, not as approvers but as contributors. Different viewpoints don’t slow the work down. They stress-test it. The solution that survives that process is stronger than anything I could have built alone.

My tools are refinement and efficiency. I’m not chasing perfection — I’m chasing the version that works better than the last one, with less friction than before, that more people can actually use and sustain.

The goal is never the plan. The goal is the organization being able to move well — with or without me in the room.