What to Look for When Hiring or Training an 'Ops Person' for a Growing Business

Most founders can name the exact week it happened. The calendar stopped making sense, three people asked the same question about who approves what, and a client query sat in an inbox for four days because nobody was sure whose job it was to answer it. This is not a hiring problem or a technology problem. It is the point where a business has grown past the size one person can hold in their head, and something has to change about who owns the how.

The instinct at that point is usually to buy software or bring in a consultant. Both can help. But before either does much good, most growing service businesses need a person, whether hired from outside or developed from inside the team, whose job is operations. Not admin. Not whoever happens to be free. Operations, as a defined role with a defined mandate: understand how work actually moves through the business, write it down, and keep it working as the business changes.

What the role actually needs to be good at

The instinct is to hire for technical skill: someone who can build a spreadsheet model, configure a CRM, or write an automation. Technical comfort helps, but it is rarely the core of the job, and it is rarely what predicts whether an ops hire works out.

Three things predict it far more reliably.

Process thinking. The best ops people can watch a task get done twice, by two different people, and notice immediately that it happened two different ways. They ask what triggers the task, what it depends on, and what breaks if a step gets skipped. This is a way of seeing work, not a technical skill, and it shows up as often in someone who has run a front desk or managed a warehouse floor as in someone with a project management qualification.

Documentation discipline. An ops person who understands a process perfectly but never writes it down has built nothing that survives their absence. The job includes making the invisible visible: who does what, in what order, using what, and what "done" looks like. This sounds like an obvious thing to screen for, and it is the single most common gap in candidates who otherwise interview well. People who talk fluently about process rarely produce a page of clear, usable documentation when asked to.

Comfort asking "why do we do it this way." This is the trait hardest to fake and the one that matters most. A good ops person treats every existing process as having a reason, even a bad one, and asks what that reason was before proposing a change. They are not attached to the current way of doing things. They are attached to understanding it first. That understanding is what separates a fix that holds from a fix that creates a new mess six months later.

None of this requires deep technical or coding skill. It requires curiosity, patience with detail, and the discipline to write things down before moving on to the next fire. A person with those traits can learn a tool. A person who only knows the tool rarely develops those traits afterwards.

The red flag that costs businesses the most

One pattern shows up again and again in ops hires and ops promotions that do not work out: the person who wants to rebuild everything with new tools before they understand why the current process exists.

This person is easy to like in an interview. They talk about automation, dashboards, and modern ways of working. They have opinions about which software the business should be using within the first month. What they rarely have is a question about why the current process looks the way it does, who it was built for, or what it was protecting against.

Every process that survives in a business, however messy, was usually solving a real problem at some point. A workaround exists because something broke once and someone patched it. Skip the question of why, and the rebuild recreates the same failure with a nicer interface. This is the exact pattern bolting automation onto a broken process produces: technology sits on top of a mess, and the mess simply moves faster, now with a subscription fee attached.

Other things to watch for during hiring, or when deciding whether to promote someone into the role:

• They cannot give a clear example of documentation they have written and someone else has used again later.
• They describe past roles in terms of the tools used rather than the problems solved.
• They get defensive when asked to explain a process step by step, as if being asked to slow down is a criticism.
• They have never asked a frontline team member how a task actually gets done, only assumed how it should.

Hire from outside, or develop someone already in the business

Both routes work. The right one depends on what the business already has.

Developing someone from inside works well when there is already a person on the team, often not in a formal ops role, who is the one others go to when they are unsure what to do next. That instinct for being the connective tissue of the business is hard to teach and easy to spot once you look for it. What that person usually lacks is not the eye for process, but permission and structured time to do the job properly, along with some coaching in documentation.

Hiring from outside makes more sense when the business needs someone with no attachment to the current way of doing things, because every internal candidate has been trained, informally, to accept the workarounds as normal. An outside hire notices what everyone inside has stopped seeing.

Either way, the mandate needs to be explicit from day one: this person's job is how work happens, not only whether it happens. Give them a real project early, something concrete rather than a vague instruction to sort out operations (see our guide to building operations systems that hold), and give them time with every team whose work they will eventually document.

Where this role meets a consultancy like Claro Builds

An ops person and an external consultancy are not doing the same job, and treating them as interchangeable is one of the more costly mistakes a growing business makes.

Claro Builds works through four stages, what we call the Claro Build Framework: Assess, Design, Build, Sustain. That work involves mapping a process from outside the business, with no history in it, no assumptions about how things are done here, and no stake in defending the current way of working. It is deliberately an outside view, which is what makes it effective at spotting what an internal team has stopped noticing.

The ops person's job starts where that project ends. Every build we complete is held to what we call the Adoption Standard: a structured 45-minute handover call, plus documentation written as the system is built rather than assembled afterwards. That handover is aimed at the client and the key people who will operate the system day to day, most often the ops person if one exists. It is the floor for a proper handover, not a substitute for the ops role itself, and not a stand-in for training the whole team, which is a separate, deeper engagement we deliver as a private workshop when a business wants its whole team equipped to work alongside what was built.

Without an ops person, or someone acting as one, a completed build has no internal owner. Small changes in the business, a new supplier, a new hire, a new service line, go unreflected in the system because updating it was never anyone's clearly assigned job. With an ops person in place, the system evolves with the business instead of quietly falling out of date within a year, a pattern we have seen consistently across the 100+ projects and 60+ businesses we have worked with across 10 industries, several of which are documented in our case studies.

The two roles reinforce each other. An external consultancy is best placed to assess and design without bias toward the existing way of doing things. An internal ops person is best placed to sustain what gets built, because they are there every day and everyone else already goes to them with questions. Common questions on how our handover and training options differ are answered in our FAQ.

If your business has reached the point where you are the only person who can answer how you actually do things, that is not a sign you need to work longer hours. It is a sign the business needs a defined owner for its systems, whether that is someone you hire, someone you develop, or a mix of both while you work with an outside team to get the underlying processes right first. If you want a clear read on where your operations stand before you make that call, book a discovery call with Claro Builds and we will work through it together.