Decide what the role owns before writing the advert
Most disappointing operations hires are scoping failures rather than selection failures. Decide, in writing, which of these the role owns — and which it merely supports:
- Process design and documentation across at least two functions.
- The operating cadence: which reviews exist, who attends, what decisions they produce.
- Systems ownership — usually the CRM plus the workflow and reporting layer.
- Operational reporting, including the authority to change what is reported.
- Capacity planning and the ability to escalate when volume exceeds it.
Signals that predict performance
| Strong signal | Weak signal |
|---|---|
| Can describe a constraint they found and how they proved it | Lists tools used |
| Talks about wait time, ownership and exceptions unprompted | Talks mainly about meetings coordinated |
| Has removed a process, not only added one | Has built extensive documentation nobody references |
| Can name a change that failed and why adoption did not happen | Presents an unbroken record of successes |
| Explains a trade-off they took deliberately | Describes best practices in the abstract |
The interview exercise that actually works
Ninety minutes, one real flow, with the messy details left in. Give the candidate a short brief and let them work.
Provide raw material
A described process with three or four genuine defects: an unowned step, a manual handoff, missing measurement, an exception path nobody follows. Anonymise but do not tidy it.
Ask for the questions first
Give them fifteen minutes to list what they would need to know. The quality of the questions separates operators from process enthusiasts more reliably than any answer.
Ask for a constraint hypothesis
Where do they think throughput is lost, and how would they verify it with data available in a week? Confident diagnosis without a verification plan is a warning sign.
Ask for the first thirty days
Look for measurement before intervention, one flow rather than five, and a named stakeholder they would win over first.
Probe adoption
'The team ignores your new process in week three. What do you do?' The good answer investigates why the old way is still cheaper for the user.
Questions worth asking
- Tell me about a process you removed rather than improved. What made it removable?
- How do you decide whether a problem is capacity, process or ownership?
- What is the smallest change you have made that had the largest effect?
- How do you get a change adopted by a team that does not report to you?
- What do you measure in the first two weeks of a new operations role?
- When have you decided not to automate something, and why?
Levelling, briefly
- Coordinator
- Runs an existing process reliably. Needs a defined system to operate inside.
- Operations manager
- Designs and changes process within a function; owns documentation, cadence and reporting for that area.
- Head of operations
- Owns the operating model across functions, including systems ownership and capacity decisions.
- COO-level
- Owns the operating model plus commercial accountability for its outcomes, usually with budget authority.
Related reading
If the boundary you are hiring for is unclear, read operations manager vs project manager. To see what the work looks like in practice, the operations audit playbook is the exercise a strong candidate should recognise immediately.
