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 — 6 of 8 core properties migrated, build time cut ~80% — I own the Asana implementation for reporting, capacity and resourcing, and I built the AI intake tool that triages requests from six teams so designers see a queue instead of a firehose.
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. On nights and weekends I've shipped four products solo — PACTO, LookLock, Vizor, PROPEL — teaching myself prompt and context engineering and agent orchestration properly. Not vibe-coding: the production foundations. 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 Asana (owner) and Webflow.
Because you said it out loud. "This is a moment of transition for the function, and you'll have a meaningful runway to shape what comes next," next to "energized by the work of building, not just running." That's not a maintenance posting. 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 the intake tool and the capacity model that didn't exist, 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 a production AI tool used by six teams that I wrote myself, four shipped products, 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. PROPEL is a co-creation network where creators collaborate under NDA/NCA protection from the first message, with an immutable record of who contributed what. I built it because friends in the emerging AI-film world had no trusted way to work together and get credit. 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.
1. The software should bend to the business now — not the other way around. 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. In the age of AI, software bends to the real business need — and once that's true, accepting a bad-fit process because "that's how the tool works" stops being pragmatism and starts being a choice.
2. So the honest first question is buy, adapt, or build. My job is to find the products that genuinely make creative teams more efficient — and when nothing on the market fits the actual need, to build it instead of contorting the team around a near-miss. That's not ideology; it's arithmetic. A niche internal workflow tool can sometimes be built in days, and 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 not a coincidence, it's where the unmet need has been.
3. And the difference is that I don't just vibe-code it. I build the traditional way: research the problem, define it, write actual requirements, then build. AI has 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, not less, 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 whole difference between a tool an org can depend on and a demo.
4. AI enablement fails when you teach it as tooling. 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 actually moves is picking two or three real, painful, recurring workflows in the team's actual 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.
5. The highest-leverage AI in a design org isn't generative — it's operational. Triage. Summarizing a research corpus. Drafting the first pass of a spec so a human starts at version two. Keeping a changelog current. Turning a messy intake request into a clear brief. That's where the hours actually go, and none of it touches anyone's craft. I know this because I built exactly that: the AI intake tool at Dow Jones triages requests from six teams so the ambiguity is resolved before it reaches a designer. Deeply unglamorous. Enormously useful.
6. Craft is the constraint, not the target. I would keep AI well away from the part of the work a designer is proud of, and I'd say that publicly and early — because 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.
7. Provenance and consent are design problems and they arrive earlier than you expect. I built PROPEL around precisely this: creators collaborating under NDA/NCA protection from the first message, with an immutable ContribLog recording who contributed what. 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.
8. Measure enablement like a program, not a vibe. 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 with them. Nothing gets changed in the first two weeks. A small team that has 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 a handful of 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: the Dow Jones intake tool 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 actual 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. Published results including what didn't work. This is the program I'd own personally, because it's the one where I can contribute craft rather than just coordination.
Done before: a production AI intake tool for six teams, and four products shipped solo. The point of view behind it →One leadership dashboard, one short changelog for the org, 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 — both because it's how practitioners grow into more senior work, 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.
I'd rather be visibly slow for four weeks and right afterwards than arrive with a framework. The fastest way to lose a small, central team is to fix something they'd already solved for reasons you didn't ask about.
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.
And a tool purchase without a named owner and a teaching plan. The most expensive tool in any org is the one that was bought, announced and never taught — you end up paying for it and for the thing half the team still uses.
Self-taught in agent orchestration and prompt/context engineering, four shipped products, and a production intake tool triaging six teams. 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.”
“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.”
“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.”
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