What Is an Operations Designer?

Last year someone asked me what I do. I said "operations designer" and they looked at me like I'd made it up.

Fair enough. It's not a title you'll find on most org charts. There's no certification. No LinkedIn category. No degree program. I started using it because every existing title described a fraction of the work — and the fractions are exactly where organizations fall through the cracks.

The title zoo

There's no shortage of people who'll help you fix your operations. The question is what "help" means.

A workflow consultant maps your processes, identifies bottlenecks, and recommends improvements. Good ones are sharp diagnosticians. But the deliverable is usually a document — a process map, a set of recommendations, a prioritized list. Implementation is your problem.

A fractional COO embeds in your organization part-time to manage operations. They're valuable when you need ongoing executive capacity you can't afford full-time. But they're operating within your existing systems, not designing new ones. When they leave, the systems they managed need someone else to manage them.

A management consultant works at the strategy layer. They analyze your market position, organizational structure, competitive landscape. The output is a strategic plan. The gap between "strategic plan" and "Tuesday morning" is where most of that work dies.

None of these are bad. I've hired some of them. But they all share the same structural problem: they separate the thinking from the building.

What an operations designer actually does

An operations designer for nonprofits — or any small organization running on fumes and determination — does the diagnosis and the construction in the same engagement.

I find the pattern. I design the system. I build the tools. I hand over the keys.

Not a report. Not a recommendation deck. A working system your team uses Monday morning.

The word "designer" is doing real work in that title. A designer doesn't just identify what's broken — they make something. An architect doesn't hand you a list of structural problems in your house. They draw the building and oversee the construction. Operations design is the same idea applied to how work flows through an organization.

Why the distinction matters

"Consultant" implies temporary advice. Someone comes in, tells you what they see, and leaves. The value is in their perspective. That's legitimate, but it creates a gap. Their perspective sits in a PDF. Your team still needs to figure out how to act on it.

"Designer" implies something gets made. A thing exists after the engagement that didn't exist before — a system, a tool, an automation, a workflow that runs without anyone remembering to push it forward.

For small nonprofits, this distinction isn't semantic. It's the difference between knowing what's wrong and having it fixed.

I run a 120-year-old performing arts venue with three staff. We do over 200 events a year. There is no room in that equation for a recommendation that requires a six-month implementation timeline. When I identify that volunteer coordination is eating six hours a week, I don't write a memo about it. I build the notification pipeline that cuts it to forty-five minutes. Same week. Same person.

That's operations design. The diagnosis and the build are one motion.

What the work looks like

Here's a pattern I see constantly in nonprofit operations: information lives in someone's head.

The development director knows which donors prefer phone calls. The executive director knows which board members need advance warning before votes. The program manager knows the caterer's real lead time versus the one on their website. None of this is written down. None of it survives a resignation.

A workflow consultant would flag this as a knowledge management problem. They'd be right. A fractional COO would start documenting it themselves. Also useful. But an operations designer asks a different question: what's the minimum system that captures this knowledge at the point of action and makes it available to whoever needs it next?

Sometimes the answer is a simple structured form that feeds a shared database. Sometimes it's an automation that pulls context from past interactions and surfaces it at decision time. Sometimes it's a custom tool built around how that specific team actually works — not how a software company imagined they might work.

The point isn't the technology. The point is that someone designed the system around the real workflow, built it, tested it against actual operations, and handed it to the team ready to run. No translation layer. No implementation consultant. No "Phase 2."

The pattern underneath

Every operations design engagement I've done follows the same shape.

First, I map how work actually flows — not the org chart version, not the board presentation version, the Tuesday-at-2pm version. Where does information enter? Where does it stall? Where does someone have to remember something for the system to work?

Second, I identify the pattern. Most operational problems aren't unique. They're the same handful of structural failures wearing different costumes: cascade failures where one input should trigger multiple outputs but doesn't, knowledge silos where critical information lives in one person's head, manual bridges where a human is doing what a system should do, and decision bottlenecks where everything waits for one person because the criteria aren't codified.

Third, I design and build the system that eliminates the failure. Not a workaround. Not a band-aid. A structural fix that runs without depending on any single person's memory or heroics.

Fourth, I hand over the keys. Documentation. Training. The system belongs to the organization. If it only works when I'm in the room, it's not done.

Who needs this

Not everyone. If your operations are running and your team has capacity, you don't need an operations designer. You need a vacation.

But if you're a small nonprofit running 200 events with 3 people, or a mission-driven org where everyone's job description is "whatever needs doing," or a team that's tried three project management tools and none of them stuck — the problem probably isn't discipline. It's design.

Your operations weren't designed. They accumulated. One process got taped to another, a workaround became permanent, and now you're running your organization on a system nobody planned and nobody can explain.

That's the work I do. Not advice about operations. Not management of operations. Design of operations — diagnosis through construction, pattern through tool, assessment through working system.

The title is operations designer because that's what the work is. I design how operations work. Then I build it. Then it's yours.