Some of the best operational work I've been involved in has been almost invisible.
Nobody celebrates the project that finished on time because everyone knew what they were supposed to do. Nobody sends a congratulatory email because a customer issue went to the right person without three people having to ask who owned it. Nobody notices when a meeting didn't need to happen because the information was already available somewhere everyone could access.
That's usually a good sign.
In operations, the things that work well often stop attracting attention. They become part of the way the business runs, rather than something people have to actively think about.
I've worked in businesses where there was a lot of visible activity around projects, teams and customers, but the less visible operating structure was doing just as much work. At Melewi, for example, we were managing digital projects across clients, countries and time zones. The finished work was what clients saw, but getting there depended on a lot of planning, communication, reviews, ownership and small decisions happening consistently in the background.
The interesting part is that most of that work wasn't particularly exciting.
It just made everything else possible.
The work nobody sees is often what keeps things moving
When people talk about project management or operations, they often focus on the more visible parts of the job. Meetings, deadlines, roadmaps, dashboards, launches and deliverables are easy to point to because they produce something tangible.
A lot of the actual work happens between those things.
It's checking that everyone has the information they need before a project starts. It's noticing that two people have made different assumptions about the same requirement. It's making sure a decision from a client review doesn't get lost in a conversation and then become a problem two weeks later. It's looking at a deadline and realising that the current plan doesn't leave enough time for testing.
None of those things are particularly impressive on their own. But if you consistently do them, they prevent a lot of problems from appearing later.
That was particularly important at Melewi because our projects could move quickly. We used two-week design sprints and shorter mini-sprints, with frequent reviews and iteration. That gave us a structure for moving projects forward without pretending that everything would remain exactly as planned from beginning to end.
The structure itself wasn't the interesting part. It was what the structure allowed the team to do.
People could see what was happening, decisions could be made regularly, and the work could change direction without the whole project having to be rebuilt around every new piece of information.
Good systems don't need to announce themselves
I think there's sometimes a temptation to make operations look more sophisticated than it needs to be.
A business introduces a new platform, creates a complicated dashboard or builds an elaborate process and then feels that it has made an operational improvement because there is now a system in place.
But a system isn't useful because it looks impressive. It's useful because people can actually use it.
If a project manager needs to spend twenty minutes explaining how to update a project tracker, the tracker isn't necessarily helping. If a team needs three different documents to work out which process applies to a customer, the documentation probably needs another look.
I've become much more interested in whether a process reduces friction than whether it looks sophisticated.
The same applies to tools. There are plenty of good project management, customer support and collaboration platforms available now, and I've worked with a lot of them over the years. But the tool itself is rarely the thing that makes the operation work.
The important questions are usually much less exciting. Who owns this? Where does the information live? What happens next? Who needs to know? When does something need to be escalated?
If everyone knows the answers, you don't necessarily need a complicated system.
Boring is often a sign that something has become reliable
When something goes wrong, people notice the process.
When something works consistently, they usually don't.
That's why operational work can be difficult to demonstrate. A lot of its value is measured in things that didn't happen.
A project didn't miss its deadline because someone spotted a dependency early. A customer didn't need to contact support three times because the first person had the information they needed. A founder wasn't pulled into an issue because the team already knew who had authority to resolve it.
There isn't always a dramatic before-and-after story.
Sometimes there is just less friction.
I've seen this in customer support as well as project delivery. When I scaled the Feline Skinscience support team from one person to eight, the visible change was the size of the team. But adding people was only one part of the work. We also needed workflows, escalation processes, SOPs and performance visibility that could support a much larger operation.
Those things aren't particularly glamorous.
But without them, eight people would simply have been trying to manage a growing workload inside a system that had originally been designed for one.
The best processes leave room for judgement
There's another reason I don't think good operations should be overly complicated.
People aren't machines, and businesses don't operate in perfectly predictable conditions.
Customers do unexpected things. Clients change their minds. A supplier misses a deadline. Someone is unavailable. A project turns out to be more complicated than it looked at the beginning.
A process should give people enough structure to deal with those situations without requiring them to ask for permission every time something falls outside the standard scenario.
That means good operations isn't about documenting every possible outcome.
It's about making the common things easy and giving people enough context to handle the uncommon things sensibly.
This was particularly important when working across different projects and clients at Melewi. We could have tried to create a rigid process for every possible type of project, but that wouldn't have reflected the reality of the work. Different clients had different requirements, different products had different complexities, and priorities could change.
The operating structure needed to be consistent enough to give people stability while remaining flexible enough to accommodate the work.
That's a balance I still think about now.
You know an operation is working when people stop talking about the process
One of my favourite signs that a process is working is when nobody is particularly interested in discussing the process anymore.
People just use it.
A new team member can understand how something works without needing a long explanation. A customer support agent knows where to look for the answer. A project manager knows what needs attention. A founder can see what actually needs their involvement rather than being copied into every decision.
At that point, the process has become part of the business rather than another thing the business has to manage.
That's where I think operations starts becoming genuinely useful. The goal isn't to create more operational activity. It's to make the existing activity easier to coordinate.
There will always be businesses that need more structure and businesses that have too much of it. The right level depends on the size of the organisation, the type of work, the people involved and how quickly things are changing.
I've never believed in adding process simply because a company has reached a particular size.
I'd rather look at where work is getting stuck and fix that.
Sometimes the answer is a new system. Sometimes it's a clearer owner. Sometimes it's better documentation. Sometimes it's removing a process that nobody actually needs.
And sometimes the best operational improvement is something so small that nobody notices it happened.
That's probably why good operations looks boring.
When it works, people get to spend less time thinking about the machinery of the business and more time doing the work the business actually exists to do.