The invisible work of Design Ops

Lessons on operational clarity, Perception, and servant leadership

This article is part of the A DesignOps Journal publication.

There is a particular kind of success in Design Ops that quietly erases its own evidence.

When the role is working well, hiring moves smoothly. Onboarding just happens. Tools exist and people use them. Governance doesn’t grind anyone down. The design team can focus entirely on design. Nobody pauses to ask why things are running well. They simply run.

And Design Ops — which made it happen — becomes invisible.

This is the central paradox of the role. The better you do it, the less anyone can point to what you did.

I’ve worked in Design Ops across several large organisations. What follows are lessons I wish someone had handed me before I had to learn them the hard way. Not methodology. Not theory. The organisational reality of doing operational work inside structures that often don’t know what to do with it.

1. The job profile doesn’t create the role

Early in my Design Ops career, I made the mistake of confusing a written job profile with actual role clarity.

At one large engineering organisation, my role was well-defined on paper. But in practice, there was never a real alignment conversation with leadership about what success would look like, what my priorities were, what authority the role carried, or where its boundaries should sit.

Without that conversation, I slowly drifted into what I’d now call servant leadership overload. I absorbed unfinished work that had no other owner. I stepped into hiring because it needed support. I picked up governance gaps, tooling coordination, and whatever fell through the cracks.

Some of it was genuinely valuable. But over time, the role became reactive — and because priorities were never explicitly documented, people could always reasonably question why I was working on something. Or whether something else should take priority instead.

What I needed was a written operational mandate for the first six to twelve months. Not as bureaucracy. As protection. Because once Design Ops becomes reactive without a documented scope, it gradually becomes an organisational overflow container. Everything nobody else owns eventually lands there.

Minimum viable steps:

• Write the mandate yourself, even if nobody asks for it. One page. What you will focus on in the first six months, what success looks like, and — critically — what is out of scope. Share it with your manager in your next one-on-one and ask for explicit sign-off. The conversation that follows is more valuable than the document.
• List the work you are currently doing that was never agreed on. If you can’t explain why something is your responsibility, it probably drifted there without anyone deciding it should. Bring that list to your manager and make the scope decision together — don’t carry it silently.
• Define “done” for your top three priorities. Reactive roles feel endless because there is no finish line. For each of your current major initiatives, write one sentence describing what done looks like. If you can’t write it, the initiative isn’t defined enough to execute.

2. Leadership changes mean re-contracting the role

In large organisations, leadership turns over constantly. I worked under three different Heads of Design at one company — including a long stretch with an interim lead.

Each time, I learned that the role needed to be actively realigned. Not assumed to carry forward on its own momentum.

The useful conversation is simple but easy to skip: “These were my responsibilities under the previous structure. Given where we are now, does this still make sense?” And later: “What does the team need most from Design Ops right now?”

Without that conversation, the role drifts. It fills with coordination overhead and emotional labor rather than work that actually moves things forward.

One specific mistake I made: when a new leader asked me to define the role, I started too close to a blank page. Better to arrive with something already prepared — the original job profile, current responsibilities, observed team needs, proposed priorities — and shape it together from there. New leaders don’t want to rebuild Design Ops from scratch. They want to understand what exists and whether it’s pointed in the right direction.

And always be explicit about what Design Ops won’t absorb. Because without that clarity, the role becomes responsible for everything nobody else claims.

Minimum viable steps:

• Request a re-contracting conversation within the first two weeks of any leadership change. Don’t wait to be asked. Bring a one-page summary: what you are currently responsible for, what is going well, what needs a decision. Frame it as alignment, not defence.
• Prepare a simple “start, stop, continue” proposal. What should Design Ops start doing under the new leadership context, what should it stop doing, and what should continue unchanged. Giving a new leader something concrete to react to is far more productive than an open-ended conversation about what the role should be.
• Get the “will not do” list agreed in writing. Even a short email confirmation is enough. When the boundaries blur later — and they will — you need something to point to.

3. Servant leadership is not invisible leadership

The purpose of Design Ops is genuinely to enable others. I believe that.

But there’s a slow trap embedded in the logic of it: if you spend enough time enabling, coordinating, and supporting — all behind the scenes — people begin to perceive the role as administrative. Useful, but not strategic.

This created a moment I still think about.

During a high-level leadership visit, I had spent days preparing. Rooms arranged, boards ready, materials printed, narratives aligned. Before it started, I had a clear instinct that we needed a shared explanation of what Design Ops was and why it mattered. I raised it with my manager. The answer was essentially: “It’ll be fine. Just say something if it comes up.”

It came up. Within the first few minutes, a senior leader looked directly at me and asked: “So what exactly does Design Ops do?”

I improvised. Others added things. It wasn’t incoherent — but it wasn’t strategic either. A role I’d spent months building got explained on the spot, in a hallway, in a way that didn’t do it justice. My gut feeling had been right. I should have prepared anyway.

What to do next time:

• Prepare your standing narrative regardless of what your manager says. Two minutes. What problem does Design Ops solve here? What have you delivered in the last three months? What does it enable going forward? Have this ready before every high-visibility moment — not after.
• Ask the alignment question explicitly beforehand. “If someone senior asks about my role during this visit, how would you like me to frame it?” That’s not defensive — it’s alignment. And even if the answer is “it’ll be fine,” you still prepare.
• Treat every high-visibility event as a rehearsal for your operational story. Not an interruption to it.

4. Operational work needs to be connected to outcomes

One structural problem with Design Ops is that the work naturally appears fragmented. Onboarding software. Hiring coordination. Budget tracking. Governance improvements. From the outside, these can look like disconnected support activities with no obvious thread.

Get Roman Schoeneboom’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The thread has to be made explicit — and it has to be made by you, because nobody else will make it for you.

Not “I worked on hiring” but “we reduced onboarding delays, which helped teams scale faster.” Not “I worked on budgeting” but “we built a financial overview that gave leadership visibility into spend and reduced operational risk.” The activity matters far less than the organisational outcome it produced. When operational work is described only in terms of what was done rather than what changed, it reinforces the perception that Design Ops is support in the narrow, undervalued sense of the word.

Minimum viable steps:

• For every active initiative, write the outcome sentence now. Not what you are doing — what will be different when it is done, and for whom. If you cannot write that sentence, stop and write it before continuing. It will also sharpen how you execute the work.
• Reframe your next status update. Take whatever you were planning to send to your manager or stakeholders and rewrite every activity line as an outcome line. “Completed vendor review” becomes “Vendor review complete — we can now proceed with procurement and have the tool live within six weeks.” Same work, completely different signal.
• Keep a running outcomes log. A simple note, updated weekly. Three columns: what you worked on, what changed as a result, who benefited. This becomes the source material for every leadership conversation, every performance review, and every moment someone asks what Design Ops actually does.

5. Design Ops is also perception management

I resisted framing it this way for a long time. But it’s accurate.

Design Ops creates value mostly through systems, enablement, and infrastructure — things designed to recede from view. Which means the work is often invisible not because it failed, but because it succeeded. And invisible work generates a reliable question: “What is Design Ops actually doing?”

That question isn’t always hostile. Sometimes it’s just honest confusion. But it needs an answer, and that answer has to be maintained continuously — not delivered once and forgotten.

Practically, this means building small evidence over time. Saving messages from colleagues when something helped. Keeping examples where a friction point was removed. Not to self-promote in a tiresome way — but because qualitative operational impact is quickly forgotten once the friction disappears. The problem you solved stops existing, and nobody quite remembers it used to be there.

This is also why a good Design Ops dashboard becomes something more than task tracking. A kanban board tells you what’s in progress. What leadership actually needs to see is workload, capacity, initiative complexity, and the trade-offs embedded in prioritisation.

A good operational dashboard makes it possible to say: “Here are the active initiatives, here’s available capacity, here’s what we can absorb and what we can’t — which priority should shift?” That turns vague conversations about being overloaded into concrete conversations about trade-offs. And it creates operational memory, which matters more than it sounds.

Minimum viable steps:

• Start a feedback file today. A note, a folder, a Slack saved messages channel — it doesn’t matter. Every time a colleague says something worked, a process improved, or support helped, save it. Review it before every leadership conversation. This is your evidence base, and it takes thirty seconds to maintain.
• Build the simplest possible dashboard that shows capacity. You don’t need a sophisticated system. A single view that shows what is active, what is on hold, and what you cannot take on right now is enough. The goal is to make trade-offs visible so leadership can make decisions rather than simply adding to your load.
• Send a short operational update every two weeks. Three to five lines to your manager: what moved forward, what is blocked, what decision you need. Not a status report — a signal that Design Ops is active, intentional, and outcome-oriented. Over time this becomes your most powerful perception management tool.

6. When feedback feels vague, Move toward evidence

One of the hardest situations I faced was receiving repeated feedback that I needed to be closer to the team, support people more, and become more available.

The difficulty: I was already doing those things. I reached out individually. I offered support. I ran check-ins by chat and call. I kept them short to respect people’s time. And when designers said they didn’t need anything right now, I took that at face value and moved on.

But the feedback kept coming back through my manager — you need to be more available, more present, more connected. And I felt caught in the middle. The effort existed. The perception didn’t match it.

Looking back, the problem wasn’t the outreach. It was that the outreach was invisible. Support that isn’t documented can be interpreted as support that doesn’t exist.

What to do next time:

• Make support interactions visible and repeatable. Set up a lightweight pulse in Teams — an automated weekly prompt asking team members if they need anything. A simple signal: support needed / not needed right now. This isn’t surveillance. It’s operational clarity.
• Log the pattern, then share it upward. “This week I reached out to all team members. Everyone indicated no immediate support needs.” Sent as part of a short end-of-week note to your manager. Simple. Consistent. Impossible to misread.
• When there’s still a gap between perception and reality, investigate it rather than react to it. Ask the operational question: Is visibility the issue? Is the support too passive? Are people hesitant to ask? Is the expectation defined somewhere you haven’t seen? That transforms emotional ambiguity into something you can actually work with.

7. Guide the systems. Don’t disappear inside them.

The last trap worth naming is also the subtlest.

Enterprise Design Ops involves a lot of complex operational work — procurement, legal reviews, GDPR assessments, governance classification, vendor coordination. Each individual piece is legitimate. The danger is what happens cumulatively: Design Ops gradually becomes the organisation’s coordination layer for everything that doesn’t have another obvious home.

I experienced this particularly around tooling. Onboarding a research tool required GDPR analysis, vendor communication, governance review, legal approvals, and internal coordination across multiple teams. Necessary work. But at some point I stopped asking the ownership questions that should have been there from the start: Who is responsible for the rollout? Who trains the team? Who maintains this long-term? Who owns support?

Those questions sound bureaucratic. They’re actually strategic. Without clear answers, Design Ops absorbs indefinite operational maintenance — which crowds out the actual work of understanding and improving how design teams function.

Minimum viable steps:

• For every new initiative or tool rollout, run the ownership checklist before you start. Five questions: Who owns the rollout? Who owns ongoing support? Who trains the team? Who maintains it? Who coordinates procurement? Write the answers down and get them agreed before the work begins — not after it’s already yours by default.
• Audit your current responsibilities for inherited maintenance. Look at everything you are doing right now and ask: did anyone decide this was mine, or did it just land here? For anything that landed without a decision, bring it to your manager with a proposal for who should actually own it long-term.
• Make “this is temporary” explicit when you step into gaps. When you pick up work that doesn’t belong in Design Ops permanently, say so at the time: “I’ll cover this for now — let’s agree on who owns it by the end of the quarter.” That single sentence prevents indefinite ownership more than any other habit.

Final thought

The biggest misconception about Design Ops is that it’s “just support.”

The second biggest is that the solution is simply doing more visible work.

The real answer is harder: developing the discipline to make operational impact legible — continuously, without turning that visibility work into the whole job. Connecting outcomes to activities. Telling the organisational story of what’s working, why it’s working, and what it would cost to let it stop.

Because invisible operational work still needs visible operational clarity.

And the people doing this work deserve to be understood — not just useful.

#DesignOpsJournal by Roman Schoeneboom offers a practitioner’s perspective, sharing insights from learning through process, reflection, observing, and exchanging with industry leaders — merged into engaging stories to spark discussion.