Better DesignOps Starts With Smaller Jobs

You grew the design team. Now designers spend half their day chasing tools, timelines, and meetings instead of designing. That is the moment leaders reach for DesignOps, and it is also the moment they get it wrong. They hire one person, hand them everything, and call it done. Or they spread the work so thin nobody owns it. DesignOps is not a single hire. It is a deliberate split of program work, tooling, and team support, plus a real choice about who carries each piece.

The deep cut

• DesignOps is a split, not a hire. Salesforce runs Team Ops and Product Ops as two jobs, not one title.
• Handing everything to managers burns them out. Kate Kaplan warns that leaving all ops to design managers creates overload.
• Grow the discipline through community, not headcount. Spotify went from two service designers to fifty-plus without an army.

Ops work is already happening, just not on purpose

Before you hire anyone, know this: the operational work is getting done today. Someone is booking the tools, running the critiques, writing the onboarding doc. In a small team, that someone is your design manager or a design lead, and they do it between other tasks. Kate Kaplan at NN/g makes the point plainly. In a small, centralized team, managers and leads carry the ops load, and it works fine as long as everyone names it as part of the job.

The trouble starts when the team grows and nobody notices the load growing with it. Knowledge sharing that used to happen over a desk stops scaling. Tool sprawl sets in. The manager who used to do ops in the margins now has no margins left. That is your signal to make the work deliberate instead of accidental.

Name the three jobs inside DesignOps

DesignOps is not one job. It splits into program work, tooling, and team support. Airbnb built its team across program management, design tools, localization, production design, and coordination. Each is a distinct skill. Program management keeps initiatives moving. Tooling curates and licenses what designers use daily. Team support handles hiring, onboarding, and community. One person can start across all of them, but do not pretend they are the same work.

Kaplan gives you the vocabulary. A DesignOps lead is the generalist who spots pain and prioritizes fixes. A producer sits with one product team and drives delivery day to day. A program manager owns org-wide programs like OKRs, hiring, and tool licensing. The producer cares about project quality. The program manager cares about team-wide excellence. Different altitudes, different people.

Team-wide versus deep-in-the-team

When DesignOps gets stretched too thin, split it by altitude. Rachel Posman at Salesforce divides the work into Team Ops and Product Ops. Team Ops runs org-wide programs: culture, community, hiring, the standards that hold across every team. Product Ops embeds with product teams and gets deep in delivery. One owns the whole. One owns the work in front of a specific team.

This split answers a question leaders trip over: who owns culture versus who owns delivery. When one person owns both, one always loses. Usually it is culture, because delivery has a deadline and culture does not. Naming the two roles keeps both alive. If you cannot afford two people yet, at least know which hat you are wearing on which day.

Grow the discipline without hiring an army

Dedicated roles are not the only way to scale. Niamh Parsley's story of Spotify grew service design from two people to over fifty practitioners, and they did not do it purely by hiring. They built an internal community, a career framework, and tactics to spread the practice through people already there. That is DesignOps in a different shape: distributed responsibility, backed by structure.

The career framework matters more than it sounds. It tells people what good looks like and gives them a path to level up, so the discipline grows from the inside. Pair that with a community where practitioners trade what works, and you get consistency without a giant org chart. Kaplan calls out the same tension: even with dedicated ops roles, managers keep some operational work forever. Distributed and dedicated are not opposites. You will run both.

Three questions for your team

1. Where are designers blocked today, and who is quietly absorbing that work without the title? Answer this before you hire, so you buy the right role, not just any role.
2. Who owns culture and community versus who owns delivery? If it is one person, decide which one you are willing to let slip, or split the job like Salesforce did.
3. Could a career framework and an internal community grow the discipline faster than a hiring plan? Spotify scaled fifty-plus practitioners that way before reaching for headcount.