Home› About
Thirteen-plus years of program and operations work across agencies, start-ups and the Fortune 500, all of it building the infrastructure that lets other people's craft survive contact with an organization.
The clearest version 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. 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, the brand steward for all our product touchpoints and product-connected materials, partnering with the commerce and acquisition product design teams across WSJ.com, Barron's.com and MarketWatch.com. I resource my team and oversee their work across design, content design and copy. My team owns the brand guidelines and is wrapping up refinements to a visual system that will feed into a brand hub. I also lead the design system unifying our event and conference site builds into one, and I built Relay, my own AI intake and planning layer: six teams send quarterly plans in six formats, Relay turns them into one resourced plan, and I'm its only user. It 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, leading design and dev roadmap planning for android.com (including the Android 12 launch), tv.google and wearos.google.com, and 4–6 designers through a year-long exploration of the future of Google Search Ads alongside Google's Search UX Design Director. Then Vertic, taking a 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 three operations systems: Relay at Dow Jones, plus an agreements system and a resourcing tool for my own team on nights and weekends, all for problems I ran into in the workplace, not as ventures. That meant teaching myself prompt and context engineering and agent orchestration properly. So 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 I've built the operating layer from very little three times: Everyrealm from literal zero, Dow Jones by writing Relay and standing up the Asana execution and capacity model, Vertic by making a design system survive a 28-engineer handoff.
And on the seven months, before you count them. I'm about seven months into my current role and I'm not running from it. The work is real, I'm doing it well, and I'd be glad to keep doing it. What changed isn't the job. It's that thirteen years made the preference clear: I do my best work where the company's product is other people's craft, and where the infrastructure has to keep independent makers whole. Etsy is one of the few places where that is the business rather than a value on a wall, so when the right role appears you act on it instead of finding out in month four that you should have.
Now the question you'd ask in the interview. I have led a named operations function and managed its people, 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, and I don't have twenty years of operations behind me. A real step up, and pretending otherwise would be the wrong start.
What I'd offer instead is a different way of thinking about it. My M.A. was in digital media management at Hyper Island, built on design thinking and business innovation rather than management theory. It taught me to treat an operating model as something you design: research the real problem, prototype the fix, test it on people, throw it out when it doesn't work. So I don't arrive as a manager looking for a process to administer. I arrive as a problem solver and a builder with thirteen years in operations.
Why that's the more useful half here. A function that's already humming needs a steward: protect what works, tune the edges, keep the trust. A function in transition needs someone comfortable with no established answer, who will hire into a shape that doesn't exist yet and can do the work personally while the team is small. I've been the person with no playbook. I know what it costs, and it doesn't frighten me.
There's a genuine trade, and I'd rather name it than let you guess. Twenty years in operations buys pattern recognition I don't have yet, and I'd be learning the scale and politics of a 130-person org reporting into a CPTO. But part of what that experience used to be the only way to get, I've reached another way: I build the systems rather than specify them, and I've taught myself to work with AI well enough to compress research, modelling and a first version into days. That doesn't replace judgment earned over decades. It does mean I show up with working answers rather than proposals.
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. My credential is a resourcing tool I built for my own team, per-week capacity planning for design teams: I didn't just run design operations, I had to decide what a capacity model actually contains. There's also Relay, an AI planning layer I wrote for myself, absorbing six teams' inconsistent quarterly spreadsheets and returning a resourced plan. To be precise, Relay enables me rather than a team, and doing that at team scale is the program I'd want to own. Plus an agreements system, and an actual position, including strong opinions about where AI should not go. 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. My agreements system turns what people commit to in a working session into a reviewed, signed record, because independent people working together had no trusted, lightweight way to make the terms clear. Attribution, consent, credit: the boring infrastructure that lets 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 with the proof. 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.
Nine claims, shortest to longest commitment. Open any one.
For twenty years you found the closest tool, then reshaped your process to fit it. Every creative team I've worked in has a workflow with a strange kink in it 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 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, against 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 protects you from building the wrong thing matters more now: you can produce the wrong thing faster. The systems 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.
These are operations systems, built for specific problems I ran into in the workplace. Not ventures, not products I'm selling. Each is a real build: several tools integrated so 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. Real production deployments, not prototypes on my laptop.
I specify the system, direct AI agents to build it, review what comes back and send it round again, with staff engineer friends advising. I am not an engineer and I don't hand-write production code. The skill on show is knowing what to ask for and recognising when the answer is structurally wrong, the same skill that makes an operating model survive contact with a real org.
Run a prompting workshop and you'll get a usage spike, 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, 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 and incomplete, and returns one resourced plan, so ambiguity is resolved before work reaches a designer. Plan in Relay, execute in Asana.
Worth being precise: Relay enables me, not a team. I built it for myself and I'm its only user. I haven't yet run AI enablement across a design org, which is exactly why I'd want it as the program I own here.
This is the one I've had to make real, in the resourcing tool I built for my own team. The decision gets made out loud in the meeting, 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 meeting updates the plan, instead of someone updating the plan after the meeting. The payoff is that an over-capacity week shows up before the work is promised away, a conversation rather than an apology.
A policy is a promise. That is the same promise, made structurally, where nobody has to remember it. And the honest limitation stays honest: it is built for and used by me and my own planning, not deployed across my employer.
I'd keep AI well away from the part of the work a designer is proud of, and say so publicly and early. The fastest way to lose a design org is to let people believe the enablement program is cost reduction 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 an agreements system around exactly this: what people commit to in a working session becomes a reviewed, signed record, so a scope or a hand-off cannot quietly evaporate. Any organization putting AI into a creative pipeline will need a position on attribution and consent before it needs one 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 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 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, an AI intake and planning layer I built for my own planning against six teams' inputs, plus an agreements system and the resourcing tool 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, 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 stay close enough to catch it. 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.
Published up front so nobody has to guess.
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 three operations systems built. Relay is the planning layer I built for myself at Dow Jones, making sense of thousands of spreadsheet cells sent in by six teams each quarter. The resourcing tool is capacity planning for design teams, which is this job with a login screen. Not vibe-coding. The real 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.
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.
Four references from people I've shipped with are on the home page.
pr.wvelazquez@gmail.com · LinkedIn · warren.digital · New York, commutable to Brooklyn