Operations from first principles

Operations are in an interesting place right now, and today I'll cover what I see working, what changes I expect to see in the near future, and how companies can use these to get an incredible competitive advantage.

The current ops model

With the proliferation of AI, and the improvements of these systems, I think it's time to rethink how we build modern ops systems and teams in organizations.

When you look at most ops roles, and what those roles do in terms of daily tasks and actions, you'll see that a large portion of their time is spent on low-leverage, low-judgement, repetitive work.

Things like updating the CRM in sales, sending and checking invoices in finance, generating reports across basically every department, following up with and scheduling candidates in HR, creating tickets in IT, moving information between systems, checking whether someone completed something, following up when they didn't, and so on.

All of these things need to be done. The problem is that they don't require particularly high levels of judgement, yet they consume an enormous amount of time.

And that's probably one of the bigger hidden costs here.

It's not only that you're paying someone to do work that could potentially be handled by a system. It's also that your good people are spending their time doing this work instead of solving problems, improving processes, talking to customers, thinking about what is going wrong, or doing basically anything else where their judgement actually matters.

I have yet to meet an SDR or an AE who loves updating their CRM, or an IT guy who loves manually creating tickets for everything, or someone in finance whose favourite part of the job is chasing people for missing documents.

Yet, most companies don't really question why humans are doing these things in the first place.

A different operating model

The way I think about it is fairly simple.

You want a relatively small number of extremely high-agency people responsible for the function, supported by a large machine that takes care of the repetitive execution underneath them.

Those people shouldn't spend their day operating the machinery manually. They should be responsible for making sure the machinery works, dealing with the cases where it doesn't, improving it over time, and making the decisions where judgement is actually required.

For the longest time, the leverage available in ops just wasn't that big.

We had SaaS, APIs, automation and increasingly better software, and all of those things helped, but there was still a fairly strong relationship between the amount of work coming into a company and the amount of people you needed to process that work.

If you had twice as many invoices, you generally needed more people in accounting.

If you had twice as many customers, you needed more people in delivery or support.

If you were hiring twice as many people, you needed more recruiters and coordinators.

If you launched another business unit, entered a new market or added another service line, you knew that a certain amount of additional headcount was going to come with it.

More volume meant more work, and more work meant more people.

But I think that relationship is starting to break.

Your finance department that used to have 20 people and some legacy system mostly acting as a place where information gets stored can potentially become an operation run by six people (who are very capable though - can't have B or C players), supported by systems that process invoices, collect documents, reconcile information, generate reports, follow up on missing items, identify anomalies and route the small percentage of cases where something doesn't look right.

Those six people can then spend their time on the things you actually need capable finance people for.

Exceptions. Fraud. Ambiguous situations. Controls. Cash planning. Understanding why something is happening. Improving the system itself.

The same idea applies far outside finance.

Throughput per operator

And I think the interesting metric here becomes something like **throughput per operator**.

• How much can one person actually be responsible for?
• How many customers can one delivery operator oversee?
• How many transactions can one finance person supervise?
• How many hiring processes can one recruiter run properly?
• How much revenue can one RevOps person support?
• How much of the business can a single extremely capable operator keep running?

Because if you can dramatically increase that number, the economics of the company start looking very different.

You can grow without your cost base growing at anywhere near the same rate. You can take on significantly more customers without destroying your margins by hiring another delivery team.

You can enter a new geography without immediately recreating the entire operating structure you already have somewhere else.

You can launch a new product or service with a handful of cracked people because a large portion of the infrastructure required to operate it already exists as systems.

You can experiment with things that previously might not have made economic sense because the fixed organizational cost of trying them was too high.

And you can develop features, or launch product lines, that were just hard to justify because they required additional human capital with ambiguous ROI but clear costs.

The competitive advantage

This is where I think the real competitive advantage starts appearing.

If two companies are competing in essentially the same market, but one of them needs another 20 people every time it adds a meaningful amount of volume while the other one can absorb most of that volume with the team it already has, those companies are eventually going to have completely different economics.

One has to keep adding organizational complexity as it grows.

The other gets leverage.

That doesn't only mean higher margins. It also means the company can move faster, experiment more, pay its best people more, enter markets faster and potentially survive opportunities or downturns that would be much harder for a company whose entire cost structure is tied directly to headcount.

Designing the function from the ground up

And that's why I don't think the interesting conversation is really about 'automation.'

Most companies that are currently implementing AI or some other technology are still thinking through the old lens.

They take the organization that already exists, look at the processes they already have, and ask where they can automate a step here or save someone a few hours there.

Before you get your pitchforks - I know, that's still useful...

But I think the more interesting question is what the company would look like if you designed the process from the ground up with the capabilities we have today in mind.

• If you were building the finance department today, would you design it the same way?
• Would your recruiting process have the same amount of manual coordination or steps?
• Would you have people preparing weekly reports if the underlying information could be continuously available?
• Would you have account managers spending half their day transferring information between systems?
• Would you have the same management structure if people no longer needed to spend as much time coordinating the movement of basic information?

Once you start looking at it this way, you stop asking which individual tasks AI can automate and start asking how the function itself should operate.

I've seen this myself a few times already, albeit mostly at smaller companies with fewer than 50 employees, where the ops team doesn't consist of five or ten people, but two extremely high-agency operators who oversee a surprisingly large machine running underneath them.

And I think we're going to see a lot more of that.

I don't particularly believe in the idea, at least not right now, of some completely autonomous AI workforce where humans suddenly disappear and agents make every important decision in the company.

Where I would start

So what would I do, practically?

The first thing I would remove is the work people already hate doing. Stuff like data entry, follow-ups, or other repetitive and well-known processes (client onboarding, for example).

The test to figure out what this low-hanging fruit is: Sit down with someone, ask them to explain exactly, step-by-step, what they're doing, write down a clear set of steps and rules that cover the majority of cases.

Then, just let the systems deal with that, and let people spend their time where the answer isn't obvious.

Over time, those systems will probably take on more judgement as well, but there's already an enormous amount of leverage available before you ever get there.

And that leverage manifests in the fact that one capable person can start having the throughput that previously required a small department - that's how you know you're on the right track.

The condition: trustworthy systems

One important thing though...

There's a condition, which you have to meet.

And that is that the systems have to be trustworthy.

Because if you have fewer people manually touching the process, you need significantly better visibility into what the system itself is doing.

If the system fails loudly, aka throws an error that you can see, it's just a bit annoying.

If the system fails silently for a couple of months, you might be living in the illusion that everything is fine, but the consequences can be catastrophic.

So this type of company needs very good controls and observability around the machinery.

You need to know what happened, what information was used, why a particular decision was made, what the system was confident about, what it wasn't confident about, and where a human needs to become involved.

If the system receives something that clearly fits within its guidelines, let it handle it.

If something is ambiguous, unusual, high risk or outside those guidelines, escalate it to the expert who has the judgement and the responsibility.

And for the important processes, you should be able to trace backwards and understand exactly what happened when something eventually goes wrong.

That's why I think human-in-the-loop systems make much more sense than trying to blindly maximize autonomy.

Because at the end of the day, our goal isn't to replace all humans with some machines, it's to put humans where humans where they create the most value, while letting the machines handle the grunt work.

The future

This is what ultimately decouples headcount from throughput.

For most of the history of business, if you wanted substantially more output from the organization, you eventually needed substantially more people.

I don't think that will remain true to anywhere near the same extent.

And companies that figure this out early are going to have a massive advantage.

Ops are extremely important and will become more important over time.

But I think the best companies are going to do ops very differently.