Design Ops When You're the Whole Team

I learned what operations meant before I had a word for it.

Growing up, my family owned a Chinese and Thai restaurant. I watched the invisible labor behind running it every day. The inventory. The menu. Knowing what's available, what's running low, when to prep, how to time orders so everything hits the table together. None of that is glamorous. Most of it is invisible to the person eating. But without it, the kitchen falls apart.

As I got older I had the chance to experience restaurants at very different price points from where I grew up. The kind of places where every plate is timed to the second and the kitchen runs like a machine. The precision was different. More details at stake, more moving pieces, more choreography. But underneath, the need was the same. Smooth operations. My parents' restaurant wasn't less skillful. It was the same underlying system at a different scale. The difference was resources, not capability. I think about that a lot when I think about design.

Being a team of one was familiar to me. As a graphic designer and marketing manager at a university, I was used to running the whole operation myself. I handled intake, production, vendor relations, brand governance, all of it. At some point I realized I needed to build a moat. So I created a project tracking system from scratch. Intake forms, status tracking, the whole workflow. By the end of that year we had a record of 85 projects completed, and I could point to every single one. The sheer measure of service delivery count told the story of design's impact because we had the proper intake and tracking to prove it. That system didn't just help me work. It made the work visible.

Then I moved to an agency and saw what operations looks like at scale. Onboarding was smooth. Documentation existed for processes, projects, context. I was thrown into a fire and learned fast because the infrastructure was already there. I could find what I needed and pick up where someone left off. That's the power of operations when it's done well. It multiplies what people are capable of.

But I also saw what happens when too many people are involved without clear governance. At one corporate client, we spent an entire meeting debating the naming structure of a file path in Figma. How it might appear when someone searches for it. That's how much of a bottleneck things become when decisions get distributed across too many people without a system for making them. Delegation and governance matter whether you're a team of one or a team of twenty. At twenty it's even more critical because decisions can't stall over minute details.

When I moved to a smaller company and had to build the design team's foundations from scratch, I saw the other side again. No processes, no documentation, no shared understanding of how design work moves through the organization. In places like that, design can look stuck. It can look less capable. But it's not a skill problem. Designers are just dealing with the symptoms of organizational dysfunction. They're doing the work of many roles with none of the systems to show for it.

Leadership often views operations as fluff and bloat. Extra process. Overhead. But in my experience, the opposite is true. Every time I've built systems around how work gets done, the work got better and the people doing it got recognized. Not because they suddenly became more talented, but because the infrastructure made their impact measurable.

I don't think the gap in design is skill. I think it's infrastructure. Engineering teams have had their version of kitchen operations for decades. Sprints, standups, pipelines, retros. Product has roadmaps and prioritization frameworks. Design has a Figma file and whatever you can hold in your head.

The first week I tracked how I actually spent my time at my current role, I found that about 40% went to communication and coordination. Not designing. Not researching. Just making sure everyone knew what was happening. That's not a personal failure. That's a systems problem.

Design ops at a team of one isn't about borrowing enterprise frameworks and shrinking them down. It's about building something that fits the space you have. A simple way for people to tell you what they need. A short list you look at once a week instead of a backlog that grows until nobody checks it. A quick update that keeps people from asking "where are we on this?" A few words about why a decision was made so you don't explain it three more times.

What stays constant across every team I've been on, whether it was just me or twenty people, is that systems shape outcomes. Good ones create space. Bad ones (or no systems at all) mean talented people burn out doing invisible labor that nobody recognizes. The scale changes. The need doesn't.