Hire an Operations Manager or Fix the Workflow First?

The real question behind the hire

Most owners consider an operations hire when they feel overwhelmed and conclude they need someone to take things off their plate. That instinct is reasonable, but it skips a diagnosis. There are two very different problems that both feel like "I need help running this."

The first is a leadership-capacity problem: the system is sound, the roles and rules are clear, but there is genuinely more management work than one person can do. This is a real reason to hire.

The second is an operating-design problem: responsibilities are fuzzy, handoffs are undefined, authority is unclear, and decisions have no rules. This feels like a capacity problem, but hiring will not solve it. Drop a manager into an undefined system and they inherit accountability for outcomes they lack the structure to control. They spend their first months trying to figure out who is supposed to do what, the same problem you have, now with a salary attached.

Telling these two apart before you hire is the entire game.

Symptoms that the problem is the workflow, not the headcount

The problem is usually operating design, not leadership capacity, when:

You cannot write a clear job description for the role because you cannot define where its authority begins and ends.
Different people give different answers about who owns a given decision or step.
Work regularly falls through the cracks between people, not within any one person's area.
Decisions are inconsistent because there is no agreed rule, only individual judgment.
A previous manager or senior hire "did not work out," and the same struggles reappeared with the next person.
Your instinct is that you need someone to "bring order," which usually means the order does not yet exist to be enforced.

That last pattern is one of the most telling. When an operations hire fails and is replaced, and the replacement struggles in the same way, the constant is often the system, not the people.

Common failed approaches

Hiring for rescue. Bringing in a senior person to "fix operations" without first defining what operations should look like hands them your undefined problem. Their success depends on structure you have not built.

Hiring a title. Recruiting a COO because the company "should have one" adds cost and hierarchy without addressing why work is not flowing. A title does not create decision rules.

Over-specifying the person, under-specifying the role. Owners often obsess over the candidate's résumé while leaving the role's authority and boundaries vague. The best hire still struggles inside an undefined role.

Assuming the last hire was the problem. Concluding that a failed operations hire was simply the wrong person, and repeating the search, ignores the possibility that the role itself was unmanageable.

A framework to decide

Before you open a search, run this diagnosis.

Define the work the role would own. Try to write the actual responsibilities, handoffs, and decision authority for the position. If you can do this cleanly, you may genuinely have a capacity problem. If you cannot, you have found an operating-design problem to fix first.
Locate where work breaks down. Determine whether failures happen within a person's area (a capacity or skill issue) or between people, at the handoffs (a design issue). Between-people failures are not solved by hiring.
Test whether decisions have rules. Pick a few recurring decisions and ask whether there is an agreed rule or only individual judgment. Unruled decisions will not become consistent because a manager arrives; the rules have to be written.
Fix the design gaps you found. Clarify responsibilities, define the handoffs, assign authority, and write the decision rules. This is often enough to relieve the pressure that made you want to hire in the first place.
Then decide about the hire. With the system defined, either the overload is gone, or you now have a clear, manageable role that a good operations manager can actually succeed in, and a real job description to hire against.

The sequence matters. Fixing the design first either removes the need for the hire or makes the hire far more likely to work.

An example from my work

A sign manufacturing company, SignZoo, is one of the clearest cases I have seen of this exact fork. The owner came in convinced the company needed clearer employee job descriptions, essentially a structural-roles fix, and was oriented toward defining positions. When I interviewed the team using structured fact-finding, the real constraint turned out to be different: the owner was excessively involved in daily decisions, customer communication, vendor interactions, and installer coordination. The issue was not that the company lacked the right people or titles. It was that authority and decisions were concentrated in the owner and had never been distributed.

Had the company simply written better job descriptions or hired a manager to "take over operations," that person would have inherited a system where the owner still held the real decisions. The fix was to transfer specific daily authority and responsibility to the existing team, redesigning where decisions were made. After the owner implemented those changes, daily operational involvement dropped, the owner moved into growth and strategy, and the company expanded its installer network beyond Florida. The workflow was fixed first, and the need to hire a rescuer evaporated. The full account is on the SignZoo case study.

There is a related lesson from a consulting firm, Midlin Consulting Group, that I grew from roughly $250,000 to over a million dollars in annual revenue while building and managing a 35-person international delivery organization. Scaling that team worked because the constraint was correctly identified as operational capacity and delivery structure, not simply the absence of a manager. When demand exceeds delivery, the answer is operating design first; headcount follows a structure, it does not substitute for one. You can read that account on the Midlin Consulting Group case study.

When outside help makes sense

The diagnosis above is one you can run yourself, and if you can cleanly define the role's responsibilities and authority, you may not need help to hire well. Outside help is worth considering when you keep trying to write the job description and cannot, when a prior operations hire failed and you are not sure why, or when you need an objective read on whether your pressure is a capacity problem or a design problem. Owners are often too embedded to see that the role they are trying to fill is not yet a role at all.

For structured next steps, the problems I solve page describes the operating problems that get mistaken for hiring problems, the case studies show how the workflow-first approach played out, and the Owner Bottleneck Reset helps you determine whether your constraint is leadership capacity or operating design.

For related reading, what an owner bottleneck actually is describes the dependency that makes many operations roles unmanageable, and why software does not fix broken business processes applies the same design-first logic to technology decisions.