Why I’m changing how I work in ops in 2026 (with AI)

AI tools have changed how I work in ops.

Not because the fundamentals changed.

Process still matters. Ownership still matters. Judgement still matters.

What’s changed is the speed you can build useful things — and how much one person can now do without needing a whole chain of “spec it, build it, hand it over, wait”.

This is personal, by the way.

Ops used to look like: I spot the problem, I outline what’s needed, then I need other people (or a lot of time) to get it built, tested, shipped, adopted.

Now, if you understand how the business works and you’re a bit techie, you can often just… build the first version yourself.

The shift I’m seeing in ops

Historically, ops roles split into two shapes:

• someone strategic who oversees the whole system
• specialists who implement parts of it (rev ops, delivery ops, reporting, tooling)

That split still exists.

But the tools have blurred it. The “full package” ops person is becoming more common: someone who can see the whole system and ship improvements without weeks of hand-offs.

And yes, I’m cheating a bit because I’ve got a developer background, but I’m not suddenly smarter than I was a year ago. The tools are just far more capable.

It’s similar to what’s happened in development.

If you’re junior and your role is basically “implement what someone else designed”, the ground is moving under your feet.

If you’re senior and you can design the solution, build it (with help from tools), and maintain it long-term, you’re in a very different position.

The difference is knowing what you don’t know.

Two examples from delivery teams (not theory)

Here’s a couple of things I worked on recently for an event marketing client that changed how I think about ops completely.

1) Event activation brief generation

Delivery teams were building event activation briefs for touring event managers and brand ambassadors.

It took a huge amount of manual effort:

• 3–4 people were doing it around their main jobs
• then during peak season, two more people were brought in full-time just to get briefs out the door

The system I built generates consistent briefs from the same inputs, in the same format, every time. Oh, and you literally click a button and it just does everything. Many, many hours saved, and it took me around a week to build… solo.

The point isn’t that it’s clever.

It’s that I could build a working version fast — days, not weeks — then iterate in tight loops with the team.

The impact isn’t “nice to have”. It’s weeks of man-hours back, and less chaos for the people who still have to deliver.

2) Van booking management (the unglamorous money leak)

Van bookings were being managed across multiple people, multiple email chains, and zero shared view of what was actually needed.

So the supplier did what suppliers do: assumed we were using the vans… and charged us.

Result: vans sat on driveways, unused, being paid for. Not ideal!

I built a simple system that centralises bookings and changes stops that happening. Not by “working harder”. By making it obvious what’s booked, what’s cancelled, and who owns the decision.

Again: the standout thing here is how quickly you can go from “this is a mess” to “here’s a single place we work from”.

Build fast, ship early, then keep tightening based on real usage.

The new bottleneck isn’t building — it’s adoption

The biggest friction now is rarely “can we build this?” It’s getting teams to actually use it.

The good news is adoption gets easier when the first version is genuinely helpful, and ticks 9 out of the 10 boxes that the team wanted.

You can ship a small thing, get feedback, tighten it up, then ship the next thing. Fast.

And because you’re not waiting weeks between iterations, you don’t lose momentum (or trust).

The paradigm shift: quick wins buy breathing room

This is the bit that still feels backwards if you grew up in the old world.

Instead of spending months designing the perfect process, you can now:

1. remove the repetitive manual pain quickly
2. buy the team time and headspace
3. then fix the edge cases properly (usually upstream in the process, not in another spreadsheet)

It’s a different way of thinking about improvement.

You’re not avoiding the “real work”. You’re creating the conditions to do it.

What I think this means for founders, ops leads, and delivery leads

If your ops function is mostly meetings, workshops and documents, you’ll get outpaced by teams who can ship improvements quickly.

Not speed for its own sake - speed that removes friction from day-to-day delivery.

If you want a sensible starting point, don’t try to design the perfect roadmap. Pick one painful weekly admin loop and make it smaller.

Then use the breathing room to tackle the structural stuff that creates exceptions in the first place.

If you’re seeing this in your world

If you’re in a scale-up and you can feel you’ve got too many edge cases, too much manual effort, too much “it depends” - drop me a message.

I’m happy to sanity-check where the quick wins are, and what you’d fix next once you’ve got some headspace back.