Skip to content
Private link. This page is set to noindex and nofollow, so it will not appear in search and will not be crawled. It is reachable only from the link shared directly with you.
W
Email

An application, not a portfolio

I build the layer design teams run on

Senior Experience Design Operations Manager · Experience Design · Expedia Group. Thirteen years of building the intake, the review cadence, the capacity view and the tooling that let design teams ship on dates that do not move.1

Going to

Expedia Group, Experience Design

Product design, research and content

Traveling as

Design Operations, senior manager

13+ years, program and creative operations

Departing from

Dow Jones, UX Program Manager, Brand

New York, since February 2026. Brand steward, six requesting functions, one team.

Start readingSee the audit

  • 8 into 1

    Property builds onto one design system

    Six of eight migrated. Two are not.

  • 6 teams

    Six spreadsheet formats, one resourced plan

    Read by a tool I built rather than by hand.

  • 28+

    Engineers a design system had to survive

    Arizona Public Service, delivered with Vertic and Infosys.

  • 13+ yrs

    The same job under five different titles

    Beyond, POSSIBLE, Vertic, Huge at Google, Everyrealm, Dow Jones. Two more before that, on my own.

01 · The route

Predictable is not the opposite of creative. It is what protects it.

Your posting says the goal is to make design predictable, scalable and deeply integrated into product development. That sentence gets read two ways. One turns Design Ops into a service desk: a queue, a calendar, a tool inventory, a team that files things. The other is where predictability buys designers the room to do the actual work, because nobody is spending Thursday reconstructing what was decided on Tuesday.

I have spent thirteen years on the second reading. At Everyrealm I built a creative function that did not exist before I arrived and hired the team into it. At Dow Jones I am the operating layer of a brand function, fielding quarterly demand from six teams and resourcing my own across design, content design and copy. When the process needed a tool that did not exist, I built that too. The first of those three is the rarest, and it is the one this page argues hardest.

How I get there is not process administration. My master's is Digital Media Management at Hyper Island, a leadership program built on business strategy, product development, experience design and change management, and it is why I reach for the problem before I reach for a framework. Every process on this page started as a question about a broken week, not as a template somebody handed me.

Read the intake problemSee the line-by-line

02 · The posting, audited

Line by line

Every line of your posting, in the order you wrote it. 15 I can prove outright and 4 are partial. Open any line to see the proof. Every partial names exactly where the gap is, which is the reason to read those four first.

What the role owns

your heading: “In this role you will”

Who you are looking for

your heading: “Who you are”

Minimum qualifications

your heading: “Minimum qualifications”

Preferred qualifications

your heading: “Preferred qualifications”

03 · Process, drawn

What I actually do, drawn before anyone asked me to describe it

I drew this for myself while running creative operations, to answer a question I kept being asked in a different form every quarter: why does this week always go wrong in the same place? It maps one execution phase of a creative project, from the operations chair rather than from inside any one project. The legend below explains the three rows.

Design Operations is mostly the middle row. Anyone can publish a workflow. The job is knowing where it leaks before the week it leaks, and having the response already named.

A working artifact from my own practice, not a diagram made for this page. Unretouched, typo included. It says PM because that is the title most organizations hand to whoever runs the day to day; I drew it while running creative operations, mapping the function and not my own job. The middle row is the Design Ops content, and it is the row I wrote first. Click to open it full size.

Top row
The ritual, in the order it happens
Middle row
Where that ritual leaks, every time
Bottom row
The response, and which tool it lands in

04 · The intake problem

Six teams, six formats, one plan

Every quarter, six teams at Dow Jones send in their plans and requests. Subscription strategy, product design, product management, performance marketing, CRM, event marketing. Each sends its own spreadsheet, in its own shape, half of it written in a hurry.

Asking everyone for a single template has never worked anywhere I have tried it. So I built Relay to take the files exactly as they arrive. The teams never open it.3

Step 1 of 6 · Collect

Six workbooks, no shared template

Nobody is doing anything wrong. Six teams have six ways of describing work, because they do six different jobs. The fix is not a nicer form. It is a thing that reads all six.

Six teams, thousands of cells, one plan out. The volume is why this is a system and not an afternoon.

1 / 6

The request

REQ · Q3
Who asked
What
Where
When
Owner
Effort
Priority

One request, moving through all six steps. The name, dates and figures shown are representative.

05 · What I built

Three operations systems, built because a week kept going wrong

They sit here, right after the intake problem, because that is what they are for. None of them is a side project about AI, a venture, or a product I am selling. Each one exists because a specific operational hour kept failing in a job I was running, and nothing on the market had the shape I needed. They are described here but not named or linked, because they are private and I would rather explain how they work than hand over an address. Same three questions for each.

Relay

Intake and planning · internal, one user

The problem I hit
Every quarter, six teams at Dow Jones send their plans and requests as six spreadsheets in six shapes, half of it typed in a hurry between other things. Reconciling those by hand ate the first two weeks of the quarter, every quarter, and the plan that came out the other side was already a fortnight old. Asking everyone to fill in one shared template has never worked anywhere I have tried it, because six teams describe work six ways for the good reason that they do six different jobs. This was not a product idea. It was two weeks I kept losing off the front of a quarter.
What it does
It takes the files exactly as they arrive. It reads the actual ask out of a hurried sentence, settles six vocabularies into one set of terms so that a week and a page mean the same thing on every line, and leaves a field empty rather than guessing when nobody named an owner. Where something is missing it writes the follow-up, sends it, holds the request open and fills the hole when the answer comes back, which is the part I care about most: a tool that hands you a list of gaps has moved the work rather than removed it. Then it proposes a resourced ranking, every line carrying a reason and a capacity cost so the order is arguable instead of handed down, and anything low confidence or over capacity lands in a tray that needs a person. Priority is a judgment call and stays one. I own the order, and every time I overrule the proposal that is recorded. Planning finishes there and only the finished plan moves into the tracker the PMs run execution in, with nothing re-typed on the way, because I own the setup on both sides and made the fields line up.
What made it a real build
Several tools integrated so the same work is never typed twice, a custom database underneath rather than a spreadsheet with ambitions, AI used in the two or three places it earns its place and nowhere else, identity and permissions designed in from the start rather than bolted on, and hosting and infrastructure I set up and keep running.

A resourcing tool

Capacity and review timing · built for my own team

The problem I hit
The resourcing hour is the hour I have watched go wrong at creative agencies, at a startup and on in-house teams, and now on my own. A room of people works out who is doing what next quarter, somebody writes it up afterwards, and by the time it reaches the board it is a week old and already partly wrong. Underneath that, capacity is assumed rather than computed: nobody has subtracted the standing meetings, the booked time off or the week somebody is only half on the team, so the over-capacity week is invisible until people are standing in it and something has to be dropped in public.
What it does
Capacity is computed per person per week, with time off, standing meetings and partial weeks coming off the top before anything is promised. It runs amber at eighty percent and red over a hundred across a twelve-week horizon, so an over-capacity week surfaces while there is still time to do something cheap about it. The decision made out loud in the meeting is captured and staged for a one-click confirm, so nothing changes because a machine thought it should; once a person confirms it, the capacity view and the plan of record update themselves and there is no second write-up. It also instruments the wait rather than the worker: moving a piece into review frees the assignee's capacity and starts a clock against that reviewer's own typical turnaround, so each reviewer is measured against themselves and not against one org-wide number.
What made it a real build
Several tools integrated so a decision never gets re-entered somewhere else, a custom database underneath, AI used only where it earns its place, identity and permissions designed in, and infrastructure I set up and keep running. It is fully built and in real weekly use, on my own planning rather than deployed across the company.

An agreements system

Commitments, recorded · private, two or three users · built 2024 to 2025

The problem I hit
Hiring conversations, vendor scoping and partnership talks all start before anyone has signed anything. I have staffed a function from zero and run vendor relationships from both sides of a contract, and in every one of them the commitments that decide how the thing goes are made in the conversation and then reconstructed afterwards from two memories that do not match. That is where scope quietly evaporates, where attribution gets argued about after the work rather than settled before it, and where an operations person spends a week rebuilding what everybody already agreed.
What it does
Both parties settle the terms before the conversation instead of after it, in about a minute, and what gets committed to in the working session becomes a reviewed, signed record attached to that agreement. From then on there is one honest account of what was promised, by whom, under which terms, so a scope or a hand-off cannot dissolve between the meeting and the follow-up. The running record of who you have talked to is a memory aid and not a decision maker; nothing about it is automatic, and no commitment enters it without a person putting it there.
What made it a real build
The deepest of the three. A custom database, identity and permissions designed in from the start, tamper-evident records because with this one the record is the entire point, two security audits, and infrastructure I set up and keep running. A year of spare time, and the clearest evidence on this page of how I take a problem apart when nobody has scoped it for me.

I am not an engineer. I specify the system, direct the AI agents that build it, review what comes back and send it round again, with staff engineer friends advising. I do not hand-write production code and nothing here claims I do. The point of building them is not the building. It is what stops costing a person a week: triaging what comes in, working out where the capacity actually is, chasing requests that arrive half specified, and rebuilding the same status for a different audience. Those hours go back to the work only the person running the function can do, which is why the ground I cover tends to be wider than the headcount suggests.4

06 · Adoption

Eight property builds, one system, and the part that was not engineering

What I do now, in one sentence: I am the brand steward for all product touchpoints and product-connected materials at Dow Jones, I field quarterly plans and requests from six functions, and I resource my own team across design, content design and copy. The scope runs from content design and UX to motion and some video production. Everything below came out of that.

This number is usually reported as an outcome: eight website properties unified onto one system, six of eight migrated, build time cut about 80%. Reported that way it sounds like an engineering result.

It was not. One engineering team did the building. The system half was design work: tokens defined in Figma for every brand asset, so eight properties could run on one system and still look like themselves. The rest was the CMS.

I joined Dow Jones in February 2026. Read this as six months of work, and ask me what was already underway when I arrived. My part was the agreement and the expectations. Consolidating eight property-specific builds meant getting the people who owned them onto a faster shared one, then holding them steady through migration and through the CMS changes. That half has nothing to do with engineering.

Two of the eight are not migrated yet. Six of eight is the honest state of it, and it is the number I would rather report than a rounded one.9

  • Consolidation

    8 builds1 system

  • Build time

    Baseline~80% less

  • Migration, honest state

    8 properties6 migrated

Eight core event and conference properties, out of more than ten event sites in scope. Unnumbered, not named, because which ones migrated first is not mine to publish.

I put this here because it is the fair challenge to the section above it. Relay has one user, and the resourcing tool runs on my own planning rather than being deployed across the company, so if you want evidence that I can get other people to change how they work, and not just build something they might, this is the piece of the record that carries it.

07 · Review pathways

Instrument the review, not the designer

Your posting asks for someone to support design review pathways, from early squad reviews to leadership checkpoints, and to maintain the schedules and alignment moments that keep quality and momentum. That is the bullet I would want to talk about first, because it is the one where most Design Ops functions quietly go wrong.

The failure mode of design metrics is measuring output, which makes designers defensive and tells leadership almost nothing. In a design org spanning product design, research and content, across a brand portfolio, the thing worth measuring is rarely how fast a designer works. It is how long work waits, and on whom.

Wait by stage, as a multiple of that stage's typical wait

  • Intake×1.0
  • Spec×1.2
  • Squad review×0.9
  • Leadership checkpoint×3.4
  • Handoff×1.1

Representative values, not measured data. This is the shape the resourcing tool's review timing surfaces. Bars are multiples of one shared baseline wait, never hours or days.

A measure that implicates the system rather than the person is, in my experience, the only kind a design team lets you keep for long.

This is not a theory I read. In the resourcing tool described in section five, moving work into review frees the assignee's capacity and starts a clock against that reviewer's own typical turnaround. Each reviewer is measured against themselves, not against one org-wide number, because a content review and a leadership checkpoint are not the same promise.

08 · The thesis

Where I think Design Ops has the most leverage inside Experience Design

Written from outside, from published material only. I have not seen your roadmap, your research repository, your internal documentation, or where the work actually hurts. So some of what follows will be wrong. Being told which parts, and why, is the fastest onboarding I can think of.2

  1. 1

    The multi-brand tax is a coordination problem before it is a token problem

    A multi-brand system solves the surface of this with tokens: a foundation layer, semantic aliases, and a theming layer that lets one component wear a different brand. Tokens are the part a design system can solve on its own.

    What tokens do not solve is the schedule around them. When a component changes underneath several consumer brands at once, somebody has to decide which brand absorbs it first, who signs off, how a squad finds out a change is coming, and what happens when one brand needs an exception. Those are decision paths and calendars, not variables.

    Proposal: a published change calendar for cross-brand component changes, with a named owner per brand and a written escalation path for exceptions. One page, in the open, so a squad can look up when a change lands instead of asking.

  2. 2

    Intent-based systems change what the word delivered means

    Expedia Group has said publicly that it is moving toward composable, data-aware blocks assembled across brands, and its design leadership has described designing for intent instead of for a fixed set of linear flows. If that direction holds, the operational unit of work stops being a screen and starts being a behavior.

    That has a direct consequence for review. You cannot walk a leadership checkpoint through every permutation of a non-deterministic surface. What you can do is agree, in advance, on the intents a surface must satisfy and the ones it deliberately will not.

    Proposal: a one-page review artifact that lists covered intents, deliberately uncovered intents, and the fallback for anything outside both. It gives a leadership checkpoint a finite thing to review on a surface that has no finite set of screens.

  3. 3

    Procurement is a gate, not the bottleneck

    Designers do not change how they work because a tool got approved. They change because two or three genuinely painful parts of their week got rebuilt with them, and the new version is obviously better. Procurement is a gate, and gates are worth being good at, but it is not the bottleneck.

    • Buy when a product does the real job. Most of the time it does, and arriving wanting to build is the fastest way to lose a procurement partner's trust.
    • Adapt when a product does most of the job and the rest is process rather than software. Change the process.
    • Build only when the near miss would force the team to reshape how it works around a tool's limits, and the build is days rather than quarters.

    Proposal: every build decision ships with one written sentence saying why buying was rejected. That sentence is what a procurement partner needs and almost never gets.

  4. 4

    Content design at scale is an operations customer, not a stakeholder

    Expedia Group has written publicly about growing content design from scattered pockets into a practice of more than fifty people embedded across the portfolio, including on the design system itself. A practice that size inside Experience Design has its own intake, its own review pathway and its own dependency on when engineering picks a string up.

    Most Design Ops functions treat content as a late-stage reviewer. That is where the deadline damage comes from: copy arriving after layout is a rewrite of both.

    Proposal: content enters at spec, not at review. Same intake, same capacity view, same wait-time instrument. That is a scheduling change, not a reorganization, which is why it is cheap enough to try in one quarter.

And what I would deliberately not do

A strategy without subtractions is a wish list.

  • Not doing

    A named framework

    No capitalized methodology, no acronym, no rollout deck. A named framework is a tax the team pays so Design Ops can be legible to people outside it. The team should be able to describe how work moves in plain sentences.

  • Not doing

    Measuring designer throughput

    No velocity per designer, no tickets closed, no output counts. Not privately, not just for capacity. The moment a designer believes a number about them is being watched, the number becomes the work. If leadership asks whether we are under-resourced, the honest answer is wait time by stage, coverage against what we committed to, and a count of what we declined.

  • Not yet

    Rebuilding intake in the first quarter

    Every ops person's instinct on arrival is to fix the front door, because the front door is where the pain is visible. It is also the thing most likely to be holding something up in ways a new person cannot see. Read the queue for six weeks first, then touch it.

  • Not mine

    The design system itself

    There are already people whose job that is, and by the public record they have been doing it for years. Design Ops taking ownership of the system would be a land grab dressed as helpfulness. My job is adoption, documentation, the decision path when the system has no answer, and making sure the people who own it get the credit.

Learned the hard way

At Everyrealm I hired the team and introduced the production processes and ceremonies they worked inside, then cut the ones that stopped earning their slot. Adding process is the easy half and it is the half that looks like the job. Removing it is where the judgment is, and it is why rebuilding intake sits on the not-yet list.

09 · Selected work

Five programs, and the hard part of each

Thirteen plus years of the same work under names that kept changing, because the function did not have a settled one. Open any card for the full account, including what was hard about it.

The whole route, in order

  1. 2011 to 2013Byte Feed MediaProject Lead and FounderMy own shop, in San Juan and Miami. Pitched and produced campaign sites and mobile apps for Nissan and for government projects in educational technology and public transport. Among them, a Clio-winning idea for the website and Facebook app behind the Puerto Rico Police's Ni Una Bala Más campaign. The thirteen-year count on this page starts after this, at Beyond.
  2. 2013 to 2015BeyondDigital ProducerGoogle's Google for Work website redesign, on a tight deadline with a distributed team, and Google DoubleClick's rebrand with the sales and executive collateral for programmatic. Viacom's intranet portal and its Office of Global Inclusion community site. Design explorations for a Novartis app for heart-failure patients and caregivers.
  3. 2015 to 2016POSSIBLEDigital Project Manager and ProducerPetfinder.com's redesign and rebrand. Updates to the Purina Veterinary Diets web app used by vets worldwide. Campaign asset production for Degree and Wild Turkey. Support to the program lead across part of ConEdison's website UX research and design phases.
  4. 2017 to 2020VerticSenior Digital Project ManagerA hybrid project and product role. End to end on Arizona Public Service: a complex utility .com, a web app, and the dashboards customers use to track energy transfers and consumption. Alongside it, Innophos.com, a secure custom B2B e-commerce platform for a highly regulated industry, plus smaller .coms and multi-country campaigns for Microsoft, SAP Ariba, Vodafone and Merck.
  5. 2020 to 2022Huge at GoogleLead Project Manager, Android PodA year-long retainer covering android.com, tv.google, Wear OS, Android Auto and Android Enterprise on one launch calendar, plus the planning phase for the Google Classroom product demo. Separately, a year-long retainer of design explorations on the future of Google Search Ads, run by our team at Huge as an embedded unit for Google Search's UX Director and his team.
  6. 2022 to 2023EveryrealmDirector of Creative OperationsCreative production built from zero at a $50M+ Web3 start-up. Twelve metaverse platforms, plus web2 properties and brand work.
  7. 2023 to presentFreelanceSenior PM, product and digital productionEight engagements, back to back. GE Healthcare, Azai Studios, thestrainapp.com, Moving Brands for NYU Langone, the agreements system, Prophet, and two lean solo builds. Open the row for the dated list.
  8. 2026 to presentDow JonesUX Program Manager, BrandBrand steward for all product touchpoints and product-connected materials, across the event and conference properties including JournalHouse and the WSJ Leadership Institute. Scope spans content design, UX and UI, motion and some video. I field quarterly plans from six functions, resource my team across design, content design and copy, own the Asana implementation, and partner with the commerce and acquisition product design teams. The eight-into-one system is mine. So is Relay. About eight events and five launches over five months.

10 · On record

Quoted, not paraphrased

Four references at four altitudes: a Design Ops practitioner, a director, an IC designer and an executive director. All verbatim excerpts from LinkedIn recommendations, shortened but not reworded. The titles are where each person works now, not where we worked together. Three of the four call me a PM, because that was the title then. What they describe is capacity planning across every workstream, expectation management on both sides of a contract, and design input instead of ticket movement. That is the operating layer under a different name.

  • Verified on LinkedInDesign Ops practitioner
    A great PM, diligent on the financial, creative and timing sides, a real go-getter, and someone who brought strong UX and design input rather than just moving tickets.

    Gary Goldsmith

    Design Operations, Meta

  • Verified on LinkedInDirector
    Warren owned creative, content, deployment and localization on android.com, with meticulous capacity planning to hit our targets across every workstream, without burning the team out. Exceptional communication and problem-solving.

    Hulya G.

    Director, Web Marketing Strategy, Google

  • Verified on LinkedInIC designer
    Across a year-long APS program, Warren ran PM and client management on a complex, multi-part project. A genuine team player and problem solver who built strong client relationships throughout.

    Stacey Wu Eggiman

    Sr. Interaction Designer, Google

  • Verified on LinkedInExecutive
    Exemplary PM on a complex, large-scale project. Diligent planning, real adaptability, and expectation management on both the internal and external sides. His role was critical to the project's success.

    Natasha Markley

    Exec Director, Marketing & Partnerships, A+I

Expedia scores its guest reviews out of ten. This page does not carry a score, because averaging four hand-picked recommendations into a number would be the first dishonest thing on it. The reviews are the evidence. The number would be decoration.

11 · The itinerary

A plan whose output is alignment is not a plan

Each step names the thing that exists at the end of it. Nothing here needs a budget or a reorganization to start.

  1. Weeks 1–2

    Read the queue, not the roadmap

    Every path work takes into design: where it enters, who bypasses the front door, and why they are right to.

    OutputA map of how work actually arrives, including the routes nobody documented.

  2. Weeks 3–4

    Sit in every review tier

    Squad review and leadership checkpoint both, for the same pieces of work. Where does work wait, and on whom? Not to assign blame, but to find out whether the waits are one reviewer, one stage, or one week of every month.

    OutputA first, unflattering picture of wait time by stage, shared with design managers before anyone else sees it.

  3. Weeks 5–6

    Audit the calendar and the tool stack together

    Both are inventories of what the organization has already said yes to. Neither gets read as an inventory until someone does it on purpose.

    OutputA kill-or-merge list for rituals, and an honest read on spend, overlap and real adoption before renewal season decides for us.

  4. Weeks 7–8

    Publish the prioritization logic

    Written, observable principles, so priority becomes a lookup instead of a negotiation and the loudest requester stops winning by default.

    OutputOne page, in the open, that anyone can check my decisions against.

  5. Weeks 9–10

    One cross-brand change, run end to end

    Take a single component change that lands under more than one brand and run it through the calendar, the owners and the escalation path from section eight. Small enough to be real, public enough to be checked.

    OutputA change that shipped, and a written account of every place the path did not exist yet.

  6. Weeks 11–12

    Make the function legible, and give a piece of it away

    One leadership view, one short changelog, one adoption number per surface. Each owned by someone other than me.

    OutputA reporting cadence that survives my calendar, plus the first written case for what Design Ops should invest in next.

Not in the first 90 days

Reorganize anything, replace a tool, or introduce a framework with a name. All three look like leadership. All three spend the trust you need to make the boring changes that work.

12 · Why Expedia Group

I am happy where I am. That is the part that needs explaining.

The obvious question is why I am moving about six months into a job I started in February. So: I am not running from anything. The work at Dow Jones is real, I am doing well at it, and nothing there has gone wrong. What is pulling is not a six-month reaction. It is a preference that took thirteen years to get clear, and it points at this role specifically rather than at the next thing going. It is specific enough to be worth writing down here rather than discovering together in month four.

What I want next is to be closer to the thing the company sells. Thirteen years of agency and media work is thirteen years of operating one step removed from it. I am good at that step, which is exactly why I know what the closer one is worth.

Travel is a fixed-date business, and fixed dates are most of my record. A launch calendar that cannot move is not a stressor for me, it is the condition I have worked in since Beyond in 2013. Android 12 had a public date. About eight events and five launches in five months at Dow Jones each had one.

The multi-brand part is the specific fit. A design system that has to make one component wear several brands without anyone downstream feeling the seam is the exact problem I spent this year on at a smaller scale, and the part that was hard there was never the tokens. It was getting eight property owners to give up a build they controlled.

The Hyper Island master's named in section one is also why the three systems in section five exist at all. They started as design exercises about a broken week, not as software projects.

13 · The ask

The job has had a lot of titles. It has been the same job.

Producer, project manager, creative operations lead, program manager, UX program manager. Your posting is the version of it I would want to keep doing, at the scale where the operating layer stops being a convenience and starts being the reason the work holds together.

Email WarrenRésuméLinkedIn

pr.wvelazquez@gmail.com · 917-554-5173 · New York

Fine print

Every marker on this page resolves here

Expedia prints the conditions under the price rather than beside it. Same idea. These are not disclaimers I am hoping you skip. The four partials in the posting audit are the ones I would want read first.

  1. 1

    The step up

    I built the operating system for a creative team once from nothing, at Everyrealm, where I also hired the team. I am the operating layer of a brand function now. I have never held a role titled Design Operations, and I have not run Design Ops inside an organization the size of yours. What I have is the less common half: I built the function instead of inheriting a working one.

    Back to the posting audit
  2. 2

    The thesis

    The thesis is written from outside, from Expedia Group's own published material only: the careers blog, the developer hub, public press releases and interviews given by your design leadership. I have not seen your roadmap, your research, your internal documentation, or where the work actually hurts. So some of what I propose there will be wrong. That is the point of writing it down rather than waiting.

    Back to the posting audit
  3. 3

    The AI claim, which is the one to read

    Relay has exactly one user: me. The six teams send spreadsheets and never open it. The resourcing tool is fully built and in real weekly use, but it runs on my own team's planning rather than being deployed across Dow Jones. The agreements system is private, in use by two or three friends. So I have built the systems, and I have not yet rolled an AI enablement program out to a design organization. That is the program I want, not one I have run. The nearest evidence that I move other people is the adoption section, which is about eight property owners and not a tool.

    Back to the posting audit
  4. 4

    Not an engineer

    I specify the system, direct the AI agents that build it, review what comes back and send it round again, with infrastructure feedback from staff engineer friends. I do not hand-write production code and nothing here claims I do. I am also not starting a business. These are proof of how I think about operational problems, not a venture. They are described on this page but deliberately not named or linked.

    Back to the posting audit
  5. 5

    Review pathways specifically

    I have run review cadences inside programs and client engagements, including the one at Arizona Public Service that brought skeptical executives in early. What I have not run is a standing critique ladder inside a design organization: a squad tier and a leadership tier on the calendar whether or not a project needs them that week, each with a written entry bar. Different object. I would be learning the organizational half.

    Back to the posting audit
  6. 6

    Staffing visibility

    The capacity and resourcing view I own is for a brand marketing team, built in Asana and fed by Relay. At Everyrealm the staffing view was mine end to end, because I hired into it. Neither is the same as maintaining staffing visibility for a design organization with a craft ladder, leveling and a headcount plan owned by someone else. I would want to be walked through how that is currently kept, rather than assume.

    Back to the posting audit
  7. 7

    Research Ops specifically

    Long research phases are not new to me: three months at Arizona Public Service, a year on Google Search Ads, and delivery on GE Healthcare's Better Health Study from the latter stages of data analysis to publication. What is new is the ops layer around it: participant recruiting, panels, incentives, consent and a repository. I have never partnered with a dedicated Research Ops practice, because none of my organizations had one. Product and engineering ops I can speak to from experience. Research Ops I would be learning.

    Back to the posting audit
  8. 8

    Operational budgeting

    I have managed vendors, partners and agency contracts from both sides of the table, and my stated strength is profitability through resource utilization and capacity management. I have not owned a formal procurement and finance cycle for a design organization's tool budget through a renewal season. That is a real gap and it stays marked partial. I would want a strong partner through the first renewal season, and I would say so on day one rather than discover it in month four.

    Back to the posting audit
  9. 9

    The Dow Jones figures

    These are counts I keep myself, and where my own tallies have drifted from my résumé I use the résumé. Eight core event and conference properties onto one design system, six of eight migrated, build time cut about 80%, about eight events and five launches over five months. Eight is the core-property count; more than ten event sites are in scope. The brand hub my team's system feeds is in progress and has not shipped. Relay is internal and has no public address, and the other two systems on this page are private.

    Back to the posting audit

Provenance and disclosures

  • Expedia Group's facts

    Every Expedia Group fact and figure quoted on this page comes from Expedia Group's own published material as of August 2026: the careers blog, the Expedia Group Developer Hub, the brands page, and press releases. Where a claim came from a designer's public case study and not from Expedia Group directly, I have not treated it as fact on this page. This page deliberately states no financial figures about Expedia Group.

  • The styling

    Built to read like Expedia Group's public product surfaces, as far as they are publicly readable. No Expedia Group logo, no Expedia Sans or Centra No. 1 font files, no copied code. The type is Inter, a free substitute chosen because it carries the tabular lining figures that make prices, dates and counts line up the way Expedia's do. Color values were sampled from public sources, not read from a specification, because the system is not published. Every chart here uses representative values and says so.

  • Not affiliated

    This is an independent page by Warren Velázquez, built as an application for one role. Every program described here is real work I have shipped. Only the styling is Expedia. Not affiliated with, endorsed by, or connected to Expedia Group, Inc. or any of its brands.