Someone who has built one, and hired it
The creative operations function at Everyrealm, its team and its methodology did not exist until he built them. A function with runway wants a builder, not a caretaker.
Home› Design Operations› Design & Research, 130+ people› Head of Design Operations
13+ years
Warren Velázquez · New York
Based in New York, commutable to the Brooklyn hub. The 1–2×/week in-office cadence works.
Reports to the VP of Design and Research. Leads a small team of DesignOps practitioners.
Every program on this site is real work he shipped.
I build the operating system, then I build the people who run it.
Head of Design Operations
Design & Research · 130+ people · reports to the VP of Design and Research
- He has built the function before, and hired it. At Everyrealm, as Director of Creative Operations, he sourced and built the team himself (3D, UI/UX, motion and visual designers), then defined the operating model they worked inside. From zero.
- AI enablement is already shipped, not theorized. He built Relay, his own AI intake and planning layer, and he is its only user: it turns 6 teams' inconsistent quarterly spreadsheets into one resourced plan, chasing the missing pieces itself, then transfers through Asana's API. Improving intake, capacity and creative ops is his current remit, behind ~8 events and 6 launches in five months, alongside his standing job as brand steward for product touchpoints. His point of view is about buying designers back their hours.
- He built the DesignOps tool, not just the practice. A resourcing tool he built for his own team, where the resourcing meeting updates the plan instead of someone updating it afterwards. Capacity is computed rather than assumed, with standing meetings, PTO and partial weeks coming off the top before anything is promised. Building it meant deciding what a capacity model contains.
- 13+ years inside product and creative organizations for a 10+ ask: Google, GE Healthcare, Vodafone, SAP Ariba, Microsoft, Merck. Plus a design-ops-shaped role right now.
The fit
The requirements, matched, with receipts.
What the role asks for, and what backs it up. The rows that matter most come first, and where the match is partial it says partial.
The fit
Head of Design Operations · Design & Research
requirement → proof
RequirementLead and grow the DesignOps team: coaching practitioners, shaping the discipline, hiring as the team evolves.
Proof · EveryrealmDirector of Creative Operations. A named operations function, a team he sourced and hired himself (3D artists, UI/UX designers, motion and visual designers), then handed the methodology rather than the instructions. On Google Search Ads he led a Huge-side team of 4–6 designers, embedded alongside Google's Search UX Design Director and his designers.
RequirementA builder's mindset: launching or evolving operational systems, not just maintaining established ones.
Proof · three buildsEveryrealm: the whole creative operating model from zero. Dow Jones: he built Relay, the AI intake and planning layer, and stood up the Asana execution, reporting and capacity layer rather than inheriting either. Relay, an agreements system and the resourcing tool were all shipped solo. There is no maintenance résumé here.
RequirementOwn one or two high-leverage programs personally: AI training and enablement, scaling intake and capacity, evolving how work is reviewed and shipped.
Proof · all three, alreadyAI enablement: Relay, built for his own planning, makes sense of 6 teams' quarterly spreadsheets, chases the gaps and allocates capacity before anything reaches Asana. Intake & capacity is his current remit. Review & ship is the design system that took 8 event properties to one and cut build time ~80%, plus the visual system his team is refining now to feed a brand hub. As brand steward for product touchpoints he resources his team and oversees design, content design and copy.
RequirementLead a DesignOps function inside a 130+ person design org, managing other DesignOps practitioners.
Partial, stated plainlyHe has built and staffed an operations function and managed its people, but at a start-up, called Creative Operations, and his reports were makers rather than ops practitioners. This is a step up and the site says so. Why the build experience is the more useful half →
Since 2013
Thirteen-plus years, one throughline: making other people's work land.
Every era is the same job in a new organization: build the operating layer, staff it, and make a standard survive contact with a dozen teams.
2013 · where it started
2026 · Dow Jones, Relay and the systems he builds
What this role needs
Three things a function in transition needs
Because you're hiring a working leader
A leader who can still do the work
A working leader has to own a program personally. He'd take AI enablement, because he has built the thing, not read about it.
Visibility that outlasts one calendar
One dashboard for leadership, one changelog for teams, one adoption metric per surface. Each is owned by a member of the team, so visibility survives his calendar.
13+ years
Click any card for the detail
Selected work: programs that shipped
Flagship
Quick look: the detail
Everyrealm · Director of Creative Operations
A function and its team, built from zero
He sourced and hired the 3D, UI/UX, motion and visual designers, then defined the processes and rituals they worked inside, across 12 platforms at a $50M+ startup.
Function leadershipHiringZero → system
Quick look: the detail
Dow Jones · Relay · Asana execution
AI enablement, already built
He built Relay for himself: it reads thousands of spreadsheet cells from 6 teams and returns one resourced plan, which transfers into the Asana execution layer he owns, behind ~8 events and 6 launches over five months.
AI enablementIntakeCapacity
Quick look: the detail
Google · Huge
Leading designers, and a design director
A year-long UI/UX research and design phase: 4–6 designers on his side, in partnership with Google's Search UX Design Director and his team. Earned entirely without authority.
People leadershipSenior partnership
Quick look: the detail
Dow Jones · UX Program Manager, Brand
Evolving how work gets reviewed and shipped
Eight property-specific build processes replaced by one system: 6 of 8 migrated, build time cut ~80%, each migration proved on a live event date. Plus a visual system now being refined that will feed a brand hub.
Review & shipAdoption
Quick look: the detail
Arizona Public Service · Vertic
An operating model at partner scale
Eleven months of research and design, then into production with Infosys and 28+ engineers, plus the review cadence that kept skeptical executives inside the process.
CadenceExec alignment
Quick look: the detail
Everyrealm · The Row
Vendors, contracts and a standard held
Owned the Monaverse relationship through implementation and platform testing to launch, plus external motion, 3D-rendering and video vendors.
Vendor mgmtQuality gate
Quick look: the detail
GE Healthcare · Freelance
Making impact visible to leadership
Built the executive-level visualizations that kept a global campaign's leadership aligned on a cadence, while hundreds of assets flowed underneath through gated review.
Exec reportingReview gates
Quick look: the detail
NYU Langone · via Moving Brands
Diagnosing why adoption stalls
A UX/IA audit strengthening an existing design system. The question was never what to build, it was why what existed wasn't being used.
AdoptionAgency side
Also built by him
One of them is a DesignOps tool. The resourcing tool, below.
AI tools I've built: all serving operations
These are operations systems, built for specific problems I ran into in the workplace. Not ventures, not products I'm selling. Each one is a real build: integrated tools so the work doesn't get re-typed between them, a custom database underneath, AI where it earns its place, permissions and access designed in, and infrastructure I keep running. I specify the system, direct AI agents to build it, then review and send it round again. The skill is knowing what to ask for and recognising when the answer is structurally wrong.
The point isn't the building. It's what stops costing a person's week: intake triage, capacity math, chasing incomplete briefs, status reporting. That's the difference between an operations hire who administers the function and one who has the hours left to change it, and why the work I take on covers more ground than the headcount suggests.
1
6 teams, 6 formats
Quarterly plans and requests, incomplete
2
Reads thousands of cells
Six shapes normalised into one
3
Chases what's missing
Automated follow-ups and check-ins
resolved
4
Allocates capacity
A resourced plan, not a wish list
MR
JL
SP
Plan in Relay Execute in
Asana via API
Built at Dow Jones · AI-directed
Relay
My own AI intake and planning layer, built for me and used by me alone. 6 teams' differently structured quarterly spreadsheets in, thousands of cells read, gaps chased by automated follow-ups, capacity allocated, and the finished plan out into Asana via its API.
Solo build · AI-directed
An agreements system
Turns what people commit to in a working session into a reviewed, signed record, so a scope or a hand-off cannot quietly evaporate.
Built for a real problem
Andre's already at 110% next week, let's move Brand guidelines to Hay.
Decision captured
Reassign
just now
Move Brand guidelines from Andre to Hay · w/o May 25
Confirm
Not yet
Hay's w/o May 25 now holds
Brand guidelines 3d
Solo build · in weekly use
The resourcing tool
Capacity planning for design teams. A per-week grid where one cell is one person times one week, and a resourcing hour where the decision made out loud is captured and staged for a one-click yes. Full breakdown below.
DesignOpsIn weekly use
The one that's literally this job
A fully built tool, in real weekly use
I didn't just run DesignOps, I built the tool for it
A resourcing tool I built for my own team. The same hour goes wrong in every creative team I have worked in: agencies, a startup, in-house teams. The resourcing meeting happens, real decisions get made out loud, and then somebody has to remember them and write them up afterwards, usually late and thinner than what was said. The plan drifts until the next meeting rediscovers it.
So I built the thing I kept re-deriving in a spreadsheet: the meeting updates the plan, instead of someone updating the plan after the meeting.
One cell is one person times one week
1d equals 20 percent of a five-day week, so a designer's week is five things you can spend, not a vague sense of busy. Standing meetings, PTO and partial weeks are first-class, so effective capacity is computed rather than assumed. A week with three recurring meetings and a Friday off is not a five-day week, and a plan that pretends otherwise will be wrong by Wednesday.
| Designer | w/o May 11 | w/o May 18 | w/o May 25 |
|---|---|---|---|
| Andre | 3d | 4d | 5.5d |
| Hay | 2d | 3d | 3d |
| Mira | 3d | PTO | 4d |
| Team total | 53% | 88% | 104% |
Under 80% Amber at 80% Red over 100% PTO, out of the maths
Representative numbers, not a screenshot. The real grids hold other people's staffing.
The meeting updates the plan
The resourcing decision gets made out loud in the meeting. It is captured as it happens and staged for a one-click yes, so nothing changes unless a human confirms it. Once confirmed, the capacity view and the team's plan of record update themselves.
The resourcing hour
In the meetingThe meeting updates the plan, instead of someone updating the plan after the meeting.
An over-capacity week shows up before the work is promised away
The week that would have gone wrong is visible while it is still a conversation, rather than an apology later, and the plan everyone works from is the one the meeting agreed.
Nobody builds this from a product spec. You build it after watching the same hour go wrong for thirteen years.
Where the line is drawn
The tool holds the planning conversation. It does not hold judgment.
A tracker is good at recording state and bad at holding the argument about whether next month is even possible. So the resourcing conversation gets a home of its own, the decision made in it is staged rather than applied, and nothing changes unless a human confirms it.
The reason I'd bring this to a DesignOps function isn't the software. It's that building it made me commit, in writing and in code, to what a capacity model contains and what it refuses to guess. Most people arrive at that conversation with opinions. I'd arrive with a schema. Happy to walk through it live.
The reference. Clare Smythe, Design Lead at Dow Jones: “It turned our weekly planning meeting from a doc-readout into a real conversation, and now the conversation updates the board itself.”
The honest status. A fully built tool, in real weekly use. It is built for and used by me and my own planning, not deployed across my employer. And Relay has exactly one user, me, and hasn't been hardened for a team. Both are true and neither is a reason to discount the work.
Why it belongs on a DesignOps application. Not because I want to be an engineer. Because a fuzzy operational problem became a working system without waiting for headcount. That's operating leverage, the same instinct I'd bring to a function with runway.
13+ years
Inside product and creative organizations, agencies through Fortune 500. The role asks for 10+.
1 function, built
Creative Operations at Everyrealm: team sourced and hired by him, operating model written by him, both from zero.
6 inputs, 1 plan
Six teams' mismatched quarterly spreadsheets become one resourced plan, through Relay, the planning tool he built for himself. He's its only user.
8→1 properties
Event and conference sites unified into one system: 6 of 8 migrated, build time cut ~80%.
A point of view, as requested
The software should bend to the business now, not the other way around.
For twenty years you found the closest tool and reshaped your process to fit it. That constraint is gone. Once software can bend to the real business need, accepting a bad-fit process because "that's how the tool works" stops being pragmatism and becomes a choice.
Software bends to the business now. Not the reverse. A bad-fit process is a choice, not a constraint.
Buy, adapt, or build, asked honestly. If nothing fits the real need, build it. Every tool I've built serves an ops function.
Specified before written. Research, define, requirements, then build. Robust and secure, not vibe-coded.
Teach workflows, not tools. Aim at the operational hours: reading thousands of spreadsheet cells, chasing missing answers, summaries, first drafts. Never at craft.
Propose, don't act. In the resourcing tool the decision is staged and nothing changes unless a human confirms it. Human-in-the-loop by architecture, not by policy.
Provenance and consent arrive early. I built an agreements system so what people commit to in a working session becomes a reviewed, signed record. Credit before models.
Measure it like a program. Hours returned per workflow, adoption per surface, quality held. On a cadence, negatives included.
References
A DesignOps lead, a director, an IC designer and an exec director
What people I've shipped with say
★★★★★
“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
Worked together on: Design operations partnership
★★★★★
“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
Worked together on: android.com roadmap, content & localization
★★★★★
“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 (ex-Vertic / APS)
Worked together on: APS design system → production
★★★★★
“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
Worked together on: Large-scale program management
Available now
A function in transition wants a builder.
You've said this is a moment of transition with real runway to shape what comes next. That's the job I've done three times: build the operating layer, staff it, and get the routine of it running on its own so the team's hours, and mine, go to the work that moves the needle. I'd like to do it for 130+ people who make things for people who make things.
The other half is that I care about this work in a way that's hard to fake. Process is the craft for me, not the overhead: the intake that makes a brief answerable, the review that catches drift early, the plan that tells the truth about who has room. And I'd rather point that at Etsy than anywhere else. For a lot of independent makers this is the first place they go and the reason the work pays, and there's more the company could be doing for them. I want to be part of that next part.
On the timing, since you'll do the arithmetic anyway. I'm about seven months into my current role and I'm not running from anything. The work is real, I'm doing it well, and I'd happily keep doing it. What's pulling is the preference above, and it took thirteen years to get clear rather than seven months. Etsy is one of a very small number of places where the thing I care about is literally the product, and that's worth acting on when the right role appears rather than discovering in month four that it was never going to be there.
pr.wvelazquez@gmail.com · LinkedIn · warren.digital · New York, commutable to Brooklyn