Home› About the shop
Thirteen-plus years of program and operations work — agencies, start-ups, Fortune 500 — and the thing I've actually been doing the whole time is building the infrastructure that lets other people's craft survive contact with an organization.
The clearest version of that was Everyrealm, where I was Director of Creative Operations at a start-up that had raised $50M+ from a16z and others and had no creative operating model at all. I sourced and hired the team myself — 3D artists, UI/UX designers, motion and visual designers — then wrote the processes and rituals they worked inside, delivering across 12 platforms. The function, the headcount and the methodology did not exist until I built them.
Right now I'm UX Program Manager, Brand at Dow Jones, partnering with the commerce and acquisition product design teams across WSJ.com, Barron's.com and MarketWatch.com. I lead the design system unifying our event and conference site builds into one, and I built Relay, the AI intake and planning layer that turns six teams' differently structured quarterly spreadsheets into one clear, resourced plan instead of a firehose. It then transfers into the Asana implementation I own for execution, reporting, capacity and resource management. Plan in Relay. Execute in Asana.
Before that: Google via Huge, where I led design and dev roadmap planning for android.com (including the Android 12 launch), tv.google and wearos.google.com, and led 4–6 designers through a year-long exploration of the future of Google Search Ads alongside Google's Search UX Design Director. And Vertic, where I took a comprehensive design system through eleven months and into production with Infosys and 28+ engineers.
M.A. in Digital Media Management, 2014 — Hyper Island (Sweden) / Teesside University (U.K.). B.S. in Advertising Communications. I've built Relay, PACTO and Vizor — Relay at Dow Jones, PACTO and Vizor on nights and weekends — teaching myself prompt and context engineering and agent orchestration properly. Which is why when I say I'd build a tool rather than file a ticket for one, I mean it literally.
Location: New York — commutable to the Brooklyn Office Hub. The 1–2×/week cadence works.
Tools: Figma, Jira, Notion, Cursor, Claude, Google Workspace — plus Relay (built it), Asana (owner) and Webflow.
Because you said it out loud: a moment of transition, with runway to shape what comes next. That's a build job with a leadership title, and building the operating layer from very little is the thing I've done three times — at Everyrealm from literal zero, at Dow Jones by writing Relay and standing up the Asana execution and capacity model, and at Vertic by making a design system survive a 28-engineer handoff.
Now the question you'd ask in the interview, so let's do it here. I have led a named operations function and managed the people in it — but at a start-up, called Creative Operations, and my reports were makers rather than DesignOps practitioners. I have not run DesignOps inside a 130-person design organization. That's a real step up and pretending otherwise would be the wrong start.
Here's why I think the build experience is the more useful half for this particular opening. A function that's already humming needs someone who can steward it — protect what works, tune the edges, keep the trust. A function in transition needs someone who is comfortable when there's no established answer, who will hire into a shape that doesn't exist yet, and who can do the work personally while the team is small. I've been the person with no playbook. I know what it costs and I know it doesn't frighten me. What I'd be learning is the scale and the specific politics of a 130-person org reporting into a CPTO — and I'd rather learn that than teach someone else how to start from nothing.
Because the AI part isn't a stretch for me, and for most candidates it will be. You've named AI training and enablement as a candidate program, asked for a point of view, and put Claude and Cursor in the tool stack. I have Relay — a production AI planning layer I wrote myself, absorbing six teams' inconsistent quarterly spreadsheets and returning a resourced plan — plus PACTO and Vizor, and an actual position — including strong opinions about where AI should not go in a design org. That combination is not common and it's the part of this job I'd be most immediately useful on.
Because I like the unglamorous half. The intake form nobody wants to design. The prioritization principle that takes three weeks to socialize and then saves a year of arguments. The tool renewal nobody read. The meeting I have to kill knowing I'll be mildly unpopular for a fortnight. Creative organizations fail on operations far more often than on craft, and operations is what I'm actually good at.
And because Etsy is a marketplace of makers, and I keep building for makers. PACTO is legal-tech for agreements, NDAs, clauses and signatures — so the terms of a collaboration are explicit and recorded from the start rather than reconstructed later. I built it because independent people working together had no trusted, lightweight way to make the terms clear. Attribution, consent, credit — the boring infrastructure that lets independent people trust each other enough to make something together. Keeping Commerce Human is a claim about who infrastructure is for, and that's the part of this company I'd be glad to work inside.
Nine bullets under “Qualities that will help you thrive.” Each one with the proof, and where it's a partial match it's marked ◐ Partial — because the two things I'd be learning here are more useful to you as facts than as adjectives.
Eight claims, shortest to longest commitment. Open any one.
For twenty years the deal was that you found the closest tool, then reshaped your process to fit what it could do. Every creative team I've worked in has a workflow with a strange kink in it that exists purely because some product's data model demanded it. That constraint is gone. Once software bends to the real business need, accepting a bad-fit process because "that's how the tool works" stops being pragmatism and becomes a choice.
My job is to find the products that make creative teams more efficient — and when nothing on the market fits the real need, to build it rather than contort the team around a near-miss. A niche internal workflow tool can sometimes be built in days. The alternative is often a five- or six-figure annual SaaS line item that still requires the team to work its way. Every AI product I've built serves an operations function. That's where the unmet need has been.
I build the traditional way: research the problem, define it, write requirements, then build. AI collapsed the cost of implementation, not the cost of thinking — so the discipline that used to protect you from building the wrong thing matters more now, because you can produce the wrong thing so much faster. The products I've shipped are robust and secure because they were specified before they were written. That's the difference between a tool an org can depend on and a demo.
Run a prompting workshop for a design team and you'll get a usage spike, a flurry of enthusiasm, and no measurable change in output. What moves the needle is picking two or three painful, recurring workflows from the team's real week and rebuilding those — with the designers who own them, not for them. Enablement is a program with a before and an after. It is not a session.
Triage. Summarizing a research corpus. Drafting a first-pass spec so a human starts at version two. Turning a messy request into a clear brief. That's where the hours go, and none of it touches anyone's craft. I know because I built it: Relay takes six teams' differently structured quarterly spreadsheets — messy, incomplete, inconsistent — and returns one resourced plan, so ambiguity is resolved before work reaches a designer. Only the finished plan transfers into Asana for execution. Plan in Relay, execute in Asana. Organisational chaos in, an actionable plan out.
I'd keep AI well away from the part of the work a designer is proud of, and I'd say so publicly and early. The fastest way to lose a design org is to let people believe the enablement program is a cost-reduction program wearing a friendly hat. The job is buying people back the hours that don't require judgment, so more of the week goes to the hours that do.
I built PACTO around exactly this — legal-tech for agreements, NDAs, clauses and signatures, so the terms of a collaboration are explicit and recorded from the start rather than reconstructed later. Any organization putting AI into a creative pipeline will need a position on attribution and consent before it needs a position on models. Especially a company whose entire premise is independent makers owning their work.
Hours returned per workflow. Adoption per surface. Quality held or improved, judged by the people who own the craft. Reported on a cadence, with the honest negatives included — the pilots that didn't work are what make the ones that did believable. An enablement program with only good news in it isn't being measured.
The order is the argument. People before systems, subtraction before addition, and one thing shipped small before anything is rolled out wide.
One-on-ones with every DesignOps practitioner before I touch a single system. What they own, what they're proud of, what they'd fix if nobody argued. Nothing gets changed in the first two weeks. A small team that's been through a transition has usually already solved things for reasons a new manager won't think to ask about.
Also in this window: time with the VP on what "good" looks like from her seat — and with designers and researchers who are not fans of how ops currently works. Those are the useful conversations.Map every path work takes into Design and Research: where it enters, who bypasses the front door and why they're right to, and what the org is absorbing invisibly. The roadmap tells you what was promised. The queue tells you what's true.
Done before: Relay exists because I mapped six teams' request paths before writing any of it.Both are inventories of what the org has already said yes to. Every recurring ritual gets measured for signal per minute — kill or merge before adding anything. Same discipline on tooling: overlap, unused seats, renewal dates, spend against real adoption, before renewal season decides for us.
Done before: introduced review ceremonies at Everyrealm, then cut the ones — including mine — that stopped earning their slot. The stack and budget approach →Written, observable principles for how the queue is ordered — including when an urgent fix beats a long-term build, and when it doesn't. The test isn't whether leadership agrees; it's whether a designer can predict the answer without asking me. Once that's true, the loudest requester stops winning by default.
Done before: continuous reprioritization across three Google web properties against immovable public launch dates.Two workflows, chosen with the designers who own them, rebuilt together, with an honest before and after. Operational work only, and published results including what didn't work. This is the program I'd own personally, because it's where I can contribute craft rather than just coordination.
Done before: Relay, a production AI intake and planning layer for six teams, plus PACTO and Vizor shipped solo. The point of view behind it →One leadership dashboard, one short changelog, one adoption metric per surface — each in a format that audience already reads. And each one owned by a member of the team rather than by me, because it's how practitioners grow, and because visibility that depends on my calendar isn't a system.
Done before: the executive-level visualizations that kept a global GE Healthcare campaign's leadership aligned while volume flowed underneath.This is a job about people before it's a job about systems. Here's how I actually operate as a manager, including the parts I've had to learn the hard way.
Growth happens at the edge of what someone can currently do, so I delegate a little past comfort and then stay close enough to catch it. The alternative — delegating only what's safe — is how you end up with a team that's been busy for two years and hasn't grown.
At Everyrealm I hired 3D artists, motion designers and UI/UX designers — none of whose craft I could do — which forced me to get good at judging work I couldn't produce. That's the right muscle for hiring ops practitioners: hire the person who is better than you at the part you're weakest at, then get out of the way.
Most difficult conversations are difficult because they're late. Said in week one it's an observation; said in month six it's a verdict. I'd rather be the manager who mentions it immediately and slightly awkwardly.
Including the visible ones — especially the visible ones, since those are how practitioners build a reputation. The measure of an ops leader is how much of the function runs while they're on holiday.
Every ritual I add comes with one I remove or merge. Two uninterrupted maker days a week is a scheduling decision, not a value statement — and I'll be mildly unpopular for a fortnight to get it.
I don't bring leadership the news that a team feels stretched. I bring the news that the plan assumes 1.4× the capacity that exists, here are the three things I'd cut, and here's the one I recommend. A protected roadmap is an arithmetic argument.
I've cut ceremonies I personally introduced, in front of the team that had been dutifully attending them. It costs nothing except ego and it buys an enormous amount — mostly the ability to propose the next thing without everyone bracing.
Every Etsy shop publishes its policies so nobody has to guess. Same principle.
A library of 200 components at 40% adoption is a worse asset than 60 at 90% — and the same is true of a ritual, a template or a tool. Coverage is easy to report and easy to fake. Adoption tells you whether you have users or just outputs.
When a team builds their own version of what ops provides, that's information, not disobedience. Somewhere the central thing cost them more than it saved. Governance that treats it as a compliance problem loses slowly and permanently.
Prioritization principles, the definition of ready, the escalation path, the deprecation window. If it lives only in my head, I've become a bottleneck wearing the costume of a leader.
Self-taught in agent orchestration and prompt/context engineering, with Relay, PACTO and Vizor built — Relay being the AI intake and planning layer in production at Dow Jones, making sense of thousands of spreadsheet cells from six teams each quarter. Not vibe-coding — the production foundations. If a workflow is costing the team hours, it's often a tool-shaped problem.
DesignOps at this scale, and a formal Procurement and Finance budget cycle. Both are on this site in writing. I'd rather set the expectation myself than have someone find it out at the wrong moment.
“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.”
“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.”
Two more — an IC designer and an exec director — are on the shop home reviews.
Building the thing is how I explain myself — so this is a work sample as much as an application. I'd like to build the operating layer that lets 130+ designers, researchers and content designers do their best work, and I'm happy to start with the least glamorous part of it.
pr.wvelazquez@gmail.com · linkedin.com/in/w-velazquez · New York, commutable to Brooklyn