17 February 2026 · 5 min read

Most operational problems are people problems in disguise

Where coaching meets operations, and why the systems that look broken are usually pointing at something human.

When a founder tells me their operations are broken, I always start by asking one question before we touch a single system or tool or process. Is this actually an operational problem? Or is it a people problem wearing an operational hat?

Nine times out of ten, it's the second one.

This matters enormously, because if you treat a people problem like a systems problem, you will rebuild the system and the problem will come back. Maybe in a slightly different form. Maybe with a different tool involved. But it will come back, because the root cause hasn't been touched. You've replaced the packaging without addressing what's inside it.

I've seen this play out more times than I can count. A founder invests in a new project management platform, migrates everything across, trains the team, and six weeks later the same operational chaos has simply relocated to the new tool. A founder documents all their processes meticulously, hands them to the team, and finds that nothing has actually changed in how the work gets done. A founder restructures the business, redefines the roles, and discovers that the same friction and the same bottlenecks have followed the people into the new structure.

The operational mechanics were never the real problem. They were the visible symptom of something sitting underneath.

What this actually looks like in practice

Let me give you some examples that will probably feel familiar.

The project management tool isn't working

Nobody can quite explain why. Tasks are falling through the cracks, deadlines are being missed, the founder is constantly having to chase updates. The obvious conclusion is that the tool is wrong, or the setup is wrong, or they need a different system. So they switch tools, spend weeks migrating and configuring, and within a month they're back in the same position. Except when you look more closely, the tool was fine. The real issue was that it was implemented without proper training, the team wasn't involved in the setup so nobody bought into it, and when it felt clunky in the first week, people quietly went back to WhatsApp and email because it was easier. The tool failed because the people side of the implementation was skipped. Fix the people side and the tool works.

Switch the tool without fixing the people side and the new one will fail just as predictably.

The content system keeps breaking down

Deadlines are missed, quality is inconsistent, the founder is constantly frustrated that things aren't landing the way they should. The obvious conclusion is that the system needs to be redesigned, the briefs need to be tighter, the workflow needs more structure. But when you look underneath it, the system is actually sound. The real issue is that the founder hasn't fully handed over the content decisions. They're still the final approver on everything, but they're inconsistent about when they review things and what feedback they give. The team is always waiting, never quite sure what good looks like in the founder's eyes, producing work tentatively because they've learned that it might be rejected at the last minute for reasons that are hard to predict.

The content system isn't broken. The delegation is.

The operations feel chaotic

There's a general sense of things not running smoothly, of fires being put out constantly, of the business being reactive rather than proactive. The obvious conclusion is that the processes need to be better, the systems need to be tighter, the team needs more structure. But the chaos isn't coming from the processes. It's coming from a founder who is overwhelmed and making reactive decisions, who is unconsciously creating instability because their own nervous system is in a constant state of low-level alert. A founder in that state changes priorities frequently, gives unclear briefs, approves things and then changes their mind, and inadvertently undermines the very systems they asked someone to build. The team picks up on it and mirrors it back.

The chaos is real. But it originated with the person at the top, not with the processes underneath.

Systems don't fail in a vacuum. They fail because of the humans using them.

Why the people layer is so often invisible

There are a few reasons this keeps happening and why it's so consistently underdiagnosed.

First, systems are concrete and people are not. You can look at a workflow and identify what's wrong with it. You can audit a tool and find the gaps in the setup. You can read a process document and spot where it's unclear. The problems are visible and the solutions are actionable. People problems are messier. They require more nuance, more observation, more willingness to name things that are uncomfortable.

Second, naming a people problem feels personal in a way that naming a systems problem doesn't. Telling a founder that their operational chaos is partly a reflection of their own state is a conversation that requires trust and care. Telling them their project management tool is set up wrong is much easier for everyone. So the easier conversation happens, the tool gets fixed, and the underlying issue stays unnamed.

Third, most operational consultants and OBMs aren't trained to see the people layer. They're trained in systems, tools, and processes. They're good at the mechanics. The human dynamics underneath are outside their scope, so they focus on what they can see and fix what they can fix and the results are partial as a consequence.

This is where my background as a certified life coach and NLP practitioner changes what I'm able to do in an operational context. I'm trained to look underneath the presenting problem. To notice what's not being said in a meeting. To recognise when a pattern of behaviour is pointing at something the person hasn't named yet. To see the difference between a process that's broken and a person who's struggling, and to know what to do with both.

The most common people problems I see dressed as operational problems

Founder control issues dressed as a need for better systems

The founder says they need tighter processes so things don't fall through the cracks. What's actually happening is that they struggle to trust that things will be handled without them in the loop, so they stay in the loop on everything, which creates the bottleneck they're trying to solve.

Better systems won't fix this. Working through the underlying trust and control dynamic will.

Team communication breakdowns dressed as unclear processes

The team says they don't know what's expected of them. The founder says the processes are clear and the team just isn't following them. What's actually happening is that the communication style between the founder and the team is creating consistent misalignment. The founder communicates in a way that feels clear to them but doesn't land clearly for the team.

The processes are fine. The way expectations are being set and communicated needs to change.

Underperformance dressed as a recruitment problem

The founder has gone through multiple people in the same role and concluded they keep hiring the wrong person. What's actually happening is that the role isn't set up for success. The expectations are unclear, the support isn't there, the feedback loop is broken, and the founder's management style in that relationship is creating the conditions for failure.

A different person in the same broken setup will produce the same outcome.

Founder burnout dressed as an operational capacity problem

The founder says they need more systems so there's less on their plate. What's actually happening is that they're depleted, and depletion is affecting their judgment, their communication, and their ability to lead.

Systems will help, but they won't fix the depletion. The depletion needs to be addressed directly alongside the operational work.

What good operational support actually addresses

The best operational work I do sits at the intersection of the mechanical and the human. It's not enough to build a great system if the people inside it aren't set up to use it well. It's not enough to have a clear process if the team dynamics mean that process will always break down at the same point.

Good operational support looks at both layers simultaneously. What does the system need to look like? And what do the people inside the system need to be able to operate well within it?

That means honest conversations about what's actually going on, not just what's presenting on the surface. It means being willing to name things that are uncomfortable, with care and without judgment, because the thing that goes unnamed tends to be the thing that keeps causing the problem.

It means looking at the founder as part of the operational picture, not just as the person commissioning the operational work. The founder's state, their patterns, their relationship with control and delegation and trust, all of that shapes how the business runs in ways that no system can compensate for entirely.

And it means building operational solutions that account for the humans who will be living inside them. A process that looks perfect on paper but doesn't work for the actual team using it is not a good process. A tool that's technically optimal but that the team won't adopt is not a good tool. The human layer isn't separate from the operational design. It's part of it.

What this means for how you approach operational problems

The next time something in your business feels broken, before you reach for a new tool, a new process, or a new hire, sit with this question for a moment. Is this actually a systems problem? Or is there a people dimension here that I haven't fully looked at?

Ask yourself these five questions first.

Is this problem consistent across different people in the same role, which might point to the role or the setup?
Or does it seem to be specific to one person, which points to a fit or a management issue?
Has this problem persisted through multiple attempts to fix it at the systems level?
Has the same issue appeared in different forms even when the surface-level setup changed?
Is the team genuinely unclear about the process, or are they clear about the process but something else is getting in the way of following it?

The answers to those questions will start to point you toward what you're actually dealing with.

And if you're not sure, or if you've been going around in circles on the same operational issues without getting traction, that's usually a sign that you need someone who can look at the full picture. Not just the systems, not just the processes, not just the tools. The whole thing. Including the people inside it.

That's the kind of operational support that actually changes things. Not because it's more complicated, but because it's more complete. It addresses the root cause instead of the symptom. And that's the only kind of fix that actually holds.

If you're sitting with an operational problem that keeps coming back no matter what you do about it, the AI Operations Audit is a good place to start. Not because it has all the answers before we've looked at your specific business, but because it's a proper diagnostic. A real look at what's actually going on, at both the systems level and the people level, so that whatever we build or fix or change is addressing the right thing.

That's where durable operational improvement begins. Not with a new tool. With an honest look at what's really going on.

Book the Audit