When I walk into a business that feels operationally messy, I don't usually start by looking for the biggest problem.
There are usually plenty of obvious ones. People are overloaded. Projects are slipping. Customers are escalating things. Everyone seems to be using a different system. The founder is involved in far too many decisions. There are probably a few spreadsheets that nobody is quite sure who owns anymore.
Those things matter, but they're often symptoms.
The more useful question is what is causing them.
I've worked in businesses where the problems were relatively easy to see but much harder to untangle. Sometimes the issue was a process that had never been properly defined. Sometimes the business had grown faster than its original way of working. Sometimes the right people were there but nobody had clearly defined who owned what. And sometimes several perfectly reasonable processes had gradually accumulated until nobody could explain why things were being done that way anymore.
I tend to start by watching how work actually moves through the business.
Not how the organisation chart says it moves. Not how the SOP says it should move. I want to see what happens when someone actually needs to get something done.
I want to know where work gets stuck
One of the first things I look for is where people are waiting.
A project might be waiting for an approval. A customer issue might be waiting for someone with the authority to make a decision. A team member might be waiting for information from another department before they can continue. A founder might be waiting for someone to bring them a problem before they can make a decision.
Those delays can look completely different on the surface, but they often have the same underlying problem: the business hasn't made it sufficiently clear how the work should move from one person or stage to the next.
At Melewi, where I managed digital projects across different clients, teams, countries and time zones, this was particularly important. We used timeboxed design sprints, shorter mini-sprints and frequent reviews partly because projects couldn't afford to sit waiting for the perfect moment to make a decision. The work needed a rhythm that allowed it to keep moving while requirements and priorities inevitably changed.
That experience shaped how I look at operations now. If work repeatedly stops at the same point, I don't immediately assume that the people involved aren't moving quickly enough. I want to understand what the process is asking them to wait for.
Sometimes the solution is straightforward. A decision needs an owner. Information needs to be available earlier. A handoff needs to happen differently. A team needs authority to make a decision without escalating it.
You don't necessarily need a new tool to fix any of those things.
I pay attention to the workarounds
Another thing I find useful is watching what people do when the official process doesn't work.
People are very good at finding ways around problems.
Someone keeps their own spreadsheet because the company's system doesn't give them the information they need. Someone has a private document containing answers that should technically be available to everyone. A team member knows to message a particular colleague whenever a certain type of problem appears because there isn't a clear escalation path.
Those workarounds are often what keep a business functioning.
They are also some of the best evidence you can get about where the operation isn't working as intended.
I don't think the answer is to immediately tell people to stop using their workaround. If something is keeping customers happy or helping a team get through the day, removing it without replacing the underlying function can make things worse.
I'd rather understand why the workaround exists.
If three people have independently created their own way of tracking the same information, there's probably a reason. If everyone asks the same person for help with the same problem, there's probably a gap in ownership or documentation. If a process requires a series of manual steps that people keep forgetting, maybe the process itself needs to be reconsidered.
The workaround is the clue. The underlying problem is what needs fixing.
I look at who owns the decision
A surprising number of operational problems are really ownership problems.
Not because nobody cares about the work, but because two or three people are involved and nobody is quite sure who has the final say.
That can create a strange kind of paralysis. Everyone is responsible for contributing, but nobody feels comfortable making the decision.
The opposite can happen too. Someone has technically been given responsibility for something but doesn't have the authority to act without going back to someone else.
I've seen this particularly clearly in customer support. As I scaled the Feline Skinscience support team from one person to eight, it wasn't enough to add capacity. The team needed clearer workflows, escalation processes and enough information to make decisions without constantly depending on one person.
That is a very different problem from simply needing more staff.
The same principle applies to project teams. If a project manager is accountable for delivery but has no authority over priorities, timelines or scope, eventually every difficult decision will travel upwards. The founder or senior manager becomes the bottleneck, and the project manager becomes responsible for chasing decisions rather than managing the project.
When I see that happening, I start asking where the responsibility actually sits and whether the authority sits in the same place.
I want to understand what the numbers are telling me
I also want data, but I don't want to start with a dashboard just because dashboards look reassuring.
The useful numbers depend on the business and the problem.
In customer support, ticket volume, first-contact resolution and response performance can tell you a lot about capacity and customer experience. At Feline, Freshdesk reporting gave us visibility into the support operation as it grew, including more than 50,000 tickets in 2026 YTD and a 64.5% first-contact resolution rate.
But I wouldn't look at that number in isolation.
If a metric changes, I want to know what changed in the business around it.
A drop in first-contact resolution could be a training problem. It could be a change in the type of enquiries customers are sending. It could be a policy change that the team hasn't had enough guidance on. It could be something completely unrelated to the support team itself.
The number tells you where to look. It doesn't necessarily tell you what to fix.
That's why I prefer to combine the data with conversations and observation. The people doing the work usually know things the dashboard can't tell you.
I look for the difference between a people problem and a system problem
This is probably one of the most important distinctions in operations.
When something goes wrong repeatedly, it is tempting to look for the person who made the mistake.
Sometimes there genuinely is a performance issue that needs to be addressed. But if several people are making the same mistake, I'd be much more interested in the system around them.
Maybe the instructions aren't clear. Maybe the process has changed but the documentation hasn't. Maybe people don't have the information they need. Maybe the tool makes the correct action harder than the incorrect one.
Blaming the person is often the quickest response because it gives you somewhere to point.
It doesn't necessarily prevent the problem from happening again.
I've found that asking whether the system is making the right behaviour easy is often a much more useful starting point.
That doesn't remove accountability. It makes it possible to understand what kind of accountability is actually needed.
I don't try to fix everything at once
This is probably where experience has made me more cautious.
When you start looking closely at an operation, you will find a lot of things that could be improved.
You can redesign the project workflow, reorganise the documentation, change the tools, rewrite the SOPs, restructure meetings and create new dashboards. You can spend months improving things and still not have addressed the problem that is actually affecting the business most.
I would rather identify the few problems creating the most friction and start there.
If customer support is overwhelmed because order information is unreliable, hiring more agents might increase capacity but won't necessarily solve the reason customers are contacting support.
If project managers spend half their time chasing updates, another project management tool might not help if nobody has agreed on what needs to be updated or who owns the information.
If the founder is involved in every decision, a leadership workshop isn't necessarily the first thing I'd recommend. I would want to understand which decisions are reaching them and why.
The objective is not to make the business look more organised. It's to make the business work better.
The best starting point is usually closer to the work than people expect
I think that's what I enjoy most about operations.
You have to be willing to get into the details.
Not because the operator should be doing everybody else's job, but because you can't understand how an organisation works purely from the top.
You need to see what the customer experiences, what the support team deals with, how a project actually moves, where people are waiting, which information gets duplicated and which decisions keep travelling upwards.
Then you can start connecting those things.
That's often where the real picture appears. The support problem turns out to be connected to fulfilment. The project delay is connected to unclear ownership. The founder's workload is connected to decisions that were never properly delegated. The team's constant busyness is connected to information being scattered across several systems.
Once you can see those connections, the fixes tend to become much more obvious.
And sometimes the fix is surprisingly small.
A clearer owner. A better handoff. One source of truth. A decision that no longer needs approval. A process that gets removed rather than improved.
That's the kind of operational work I find most useful. Not adding structure for the sake of structure, but understanding how the business actually works and then making it easier for the people inside it to do good work.