There is a particular stage of growth that I find more interesting than the early startup stage or the fully established company. It's the point where a business is clearly working, but the way it works internally is starting to become a problem.
I've been on both sides of this. At Melewi, I was part of a small digital business that grew from three people into a nine-person team working across seven countries, while the projects themselves became increasingly complex. At Feline Skinscience, the challenge was very different: a rapidly growing DTC business was generating an operational workload that the original team and processes simply weren't designed to handle.
Neither situation was solved by walking in with a giant operations manual and telling everyone to follow it. The work was much more practical than that. It was figuring out where things were getting stuck, understanding why, deciding what actually needed to change, and then getting people to use the new way of working.
That's what I mean when I talk about the "messy middle" between growth and operations. The business is already too complicated to run the old way, but it isn't necessarily ready for the layers of structure you'd find in a much larger organisation. You have to build enough structure to make the business work better without turning it into a bureaucracy.
When a business starts to feel harder to run
Growth itself is rarely the problem. Most businesses want more customers, more revenue, more projects and more opportunities.
What changes is everything that has to happen around that growth.
When there are only a few people involved, you can get away with a surprising amount of informality. Someone remembers a conversation. A quick message resolves a problem. Everyone knows roughly what everyone else is working on. If something falls through the cracks, somebody usually notices because there aren't that many cracks to begin with.
As the business grows, those assumptions start disappearing.
More people are involved in decisions. Customers interact with different members of the team. Projects have more moving parts. There are more handoffs, more information and more opportunities for something to get lost between people.
The work itself might not have become dramatically more difficult. There is simply more of it, and more coordination is required to get it done properly.
This is where I think businesses can misdiagnose what is happening. Everyone is busy, so the instinct is often to hire another person, add another tool or ask the existing team to prioritise better.
Sometimes those are the right answers. But if the underlying problem is that nobody is quite sure who owns something, or that the same information is being tracked in four different places, adding another person doesn't necessarily solve it. You've just added another person to the same system.
The first job is understanding where the friction actually comes from.
You can't fix what you haven't understood
I've always found that the most useful operational work starts with observation.
Before changing a process, I want to understand how people are actually working. Not how the process is supposed to work. Not what the SOP says. What actually happens when a customer asks a difficult question, when a project changes direction, when someone is off sick or when a decision needs to be made quickly.
Those situations tend to reveal much more than a process document does.
At Feline Skinscience, for example, the customer support operation was dealing with a much larger workload than it had originally been designed for. The obvious solution could have been to simply hire more people. We did eventually scale the team from one person to eight, but that wasn't the whole answer.
As the team grew, we also had to create the structure around it. That meant clearer workflows, escalation processes, SOPs and performance visibility. We needed to understand what the team was dealing with, where issues were getting stuck and how we could make the operation more consistent.
The point wasn't to make the team follow more rules. It was to give them a better environment in which to do their jobs.
That distinction matters because operations can very easily become a collection of rules that make everyone's day harder.
The systems have to fit the business
I think this is where experience matters.
There is no universal operations playbook that you can take from one company and drop into another. What worked for Melewi wouldn't have worked for Feline, and what worked at Feline wouldn't necessarily make sense for another DTC business.
At Melewi, I was managing digital projects and working with a distributed team across seven countries. The complexity came from coordinating people, projects and client expectations across different locations and time zones, while delivering work for large international clients including Visa and McDonald's across APMEA.
That environment requires a different kind of structure. People need to understand ownership, deadlines and expectations without relying on being in the same room. Projects need enough visibility that problems can be spotted before they become delivery issues. Communication needs to be deliberate because you can't simply turn around at your desk and ask someone a question.
The business was still relatively small, though. We didn't need layers of corporate process. We needed enough structure to support the way we were actually working.
That's something I think gets lost when people talk about "scaling operations." Scaling doesn't mean adding more process simply because the business is getting bigger.
It means identifying what the next stage of the business requires and building enough of it to support that stage.
There is a point where more tools make things worse
I've also become much more cautious about technology for technology's sake.
There are some fantastic tools available now, and AI has made it even easier to automate parts of an operation. But I've seen plenty of situations where a business adds another platform because the existing system feels messy, only to end up with information spread across even more places.
A tool can make a good process faster. It can make a bad process more complicated.
The same applies to AI. There are plenty of tasks where it can remove repetitive work, help teams handle information more efficiently or make certain processes faster. But if nobody has worked out who owns the process, what the desired outcome is or what should happen when something falls outside the normal scenario, automation isn't going to solve the underlying problem.
I would rather have a simple process that everyone understands than a sophisticated system that nobody trusts.
That might not sound particularly exciting, but in operations, boring is often a compliment.
If a customer issue gets handled properly without anyone having to chase three people, that's good. If a project manager can see what needs attention without asking five people for an update, that's good. If a founder can go away for a week without the business grinding to a halt, that's very good.
Knowing what not to fix
Another part of the job is deciding what doesn't need fixing yet.
There is always something that could be improved. If you let yourself, you can spend months redesigning processes, changing tools, rewriting documentation and reorganising information.
But not every inefficiency is a priority.
I'd much rather understand which problems are actually affecting customers, revenue, delivery, team capacity or decision-making and start there.
This is particularly important in smaller businesses because people are already wearing multiple hats. Every operational project takes time away from something else.
If I'm asking a team to change the way they work, there needs to be a good reason for it.
That doesn't mean avoiding change. It means being deliberate about it.
The best operational improvements I've been involved in haven't necessarily been the most complicated ones. Often they have been fairly straightforward changes that removed a recurring source of frustration or gave people clarity they didn't have before.
Once those changes are in place, you can see what the next problem is. And then you deal with that one.
The messy middle is where I like to work
This is probably why I enjoy operations work as much as I do.
I like the point where the strategy sounds straightforward in a meeting, but someone still has to figure out what that actually means on a Tuesday morning.
A business wants to grow. What does that mean for the team? What happens to customer support? Which processes will stop working? Where will the founder become a bottleneck? What information will people need? Which responsibilities need to move to someone else? What should be measured?
Those are the questions I find interesting.
The answers aren't always obvious, and they aren't always the same from one business to another. That's part of the job.
The goal isn't to create a perfect operating system that never needs to change. Businesses change too quickly for that to be realistic.
The goal is to build an operation that can change with the business without everything becoming chaotic every time it does.
That's the messy middle. It's where growth meets the reality of people, processes, customers and day-to-day execution. And for me, that's where the most interesting operations work happens.