At some point, every growing agency owner arrives at the same conclusion: I need an operations manager.
The reasoning is sound. The business is operationally chaotic. Processes are inconsistent. The founder is doing too much. An operations manager is someone whose job is to fix exactly this. Hire one and the chaos goes away.
Except it usually doesn’t. Not right away, and sometimes not at all.
Here’s why — and what actually has to happen first.
What an operations manager can and can’t do
An operations manager is excellent at optimizing and managing documented processes. Given a clear workflow, they can identify inefficiencies, improve sequencing, track performance, and hold people accountable to following it.
An operations manager is not good at creating processes from scratch — at least not quickly, and not without significant access to the founder’s time and knowledge. To document how your agency onboards clients, the ops manager needs to understand how you currently onboard clients. That means interviews, observation, and lots of questions. For every process.
In a business where most processes live in the founder’s head, hiring an ops manager means hiring someone to interview you extensively and then write down what you told them. That’s useful. But it takes months, requires significant founder involvement, and the result depends entirely on how well the interviews go.
Most founders who hire an ops manager expecting relief are surprised to find themselves answering more questions than before, at least for the first several months.
The sequence problem
The standard agency scaling advice runs like this: revenue grows → hire people → delegate → founder gets time back → revenue grows more.
The problem is step three. Delegation requires something to delegate *to*. Not just someone — a process. You can hand off a documented workflow to almost anyone reasonably capable. You cannot hand off “how we do things” because that’s not a thing that exists separately from the person who does them.
Agencies that scale past $1M have usually figured this out, often the hard way: the right sequence is document first, hire second. Build the process so it can be handed off, then hire the person to run it.
This feels backward. It feels like building infrastructure before you have the revenue to justify it. But the agencies that hire first and document later consistently find that the hire produces limited leverage. The ops manager is managing chaos rather than running systems. They become another person the founder has to coordinate with, rather than someone who reduces the founder’s operational load.
What happens when you document first
When the core processes exist in documented, executable form before the hire, something different happens.
The new ops manager doesn’t need months of knowledge transfer. They can read the documentation, ask clarifying questions about edge cases, and be productive in weeks rather than months. The documentation is the onboarding.
More importantly, they can improve the processes rather than just learn them. An ops manager who inherits a blank slate spends their capacity building from scratch. An ops manager who inherits working documentation spends their capacity optimizing and extending it. The leverage is completely different.
The documentation problem
The reason most agencies don’t document first is that documentation takes time the founder doesn’t have, produces no immediate revenue, and gets deprioritized every week in favor of things that feel more urgent.
This is rational in the short term. It’s the reason the ceiling exists.
The practical solution is to make documentation a byproduct of operations rather than a separate task. When a process runs — payroll, client onboarding, project kickoff — the documentation gets built as part of running it, not afterward. The first time something runs, you’re building the SOP. The second time, you’re refining it. The third time, someone else can run it.
This doesn’t require an operations manager. It requires a decision that processes will be documented before they’re delegated, and a format simple enough that documentation takes 20 minutes rather than a full day.
When the ops manager hire actually works
Hiring an operations manager works well when:
The business has documented at least the 5–8 most frequently-run processes. The ops manager can orient themselves, understand how the business operates, and identify where to focus first.
The founder has accepted that the first 60–90 days will still require significant access. The ops manager will have questions. The transition still takes time.
The hire is made to *optimize and extend* existing systems, not to *create* them. The clearer this mandate is going in, the more likely the hire is to produce the expected leverage.
Skip those conditions and the ops manager hire produces incremental improvement at best. Add them and it compounds.
The actual order of operations
1. Document the processes that run most frequently 2. Identify which of those require the founder’s direct involvement and which don’t 3. Remove the founder from the ones that don’t, by handing the documented process to an existing team member 4. Hire an ops manager when the documented processes are ready to be managed rather than created
Most agencies start at step 4. The ones that start at step 1 get somewhere different.
---
*The documentation layer is the foundation. Adela Ventures builds it as part of every Agency OS engagement — every system we install comes with a complete SOP library. [See how it works](https://adelaventures.com/agency-os) or [take the free audit](https://adelaventures.com/founder-audit) to see where your biggest gaps are.*