Productive laziness and the new operating system for work

A lot of innovation starts with a simple internal reaction: "There has to be a better way."

Sometimes people call it laziness. I call it productive laziness. A low tolerance for unnecessary work, repeated manual steps, and "we've always done it this way." It's not avoidance. It's optimisation instinct.

For most of the last decade, progress in operations followed a familiar path. First we digitised. Then we automated workflows. Then we added better tracking, analytics, and KPI routines. In some places, we layered in ML for decisioning. All of that made organisations faster and more scalable.

AI feels like the next step, but not just because it's "new tech". It changes the operating physics. The biggest difference is iteration speed.

If you can prototype ideas instantly, you don't need a long runway to test how a workflow could work. You can get an initial draft in minutes, pressure-test it, refine it, and move again. That changes how quickly a person can learn, and how quickly a team can ship.

But the deeper change isn't speed. The deeper change is that the bottleneck moves.

When I started experimenting seriously, I assumed the biggest value would come from faster execution. Writing code faster. Producing documents faster. Creating dashboards faster.

What surprised me is that my biggest constraint became my own planning. The bottleneck isn't the tools anymore. It's me. My agents can execute faster than I can think. So the new skill isn't "working harder." It's thinking clearer.

If I gave the AI a vague instruction, I got vague output. If I started with a clear structure, crisp constraints, and a clean definition of "done," the results were dramatically better. The agents didn't need micromanagement. They needed a strong plan.

That's when it clicked for me: the leverage isn't in writing every line. The leverage is in acting as the "CEO of the work".

The stronger the initial architecture and operating rules, the more the agents can run independently. Your job becomes setting direction, defining constraints, and validating outcomes. Less time spent checking tasks, more time spent verifying results.

From a single assistant to a team of agents

We're already seeing the "team of agents" model appear in practice.

Imagine shipping something small like a website. One agent focuses on design and UX. Another proposes a basic architecture. A third writes code. A fourth tests and documents. A fifth keeps the plan coherent and resolves conflicts. The human doesn't disappear, but the role shifts. You start to feel like the client or CEO: you define the outcome, the constraints, and the quality bar.

The same pattern translates into operations almost too easily.

One agent drafts documentation and SOPs. Another maps processes and finds bottlenecks. A third pulls data, builds an analysis, and points to the 80/20. A fourth proposes automations and even helps implement them. You suddenly have leverage without hiring a big team.

This is not theory. It's already happening in small ways, and it's accelerating because tooling is improving fast. Claude Code, for example, has been positioned as a way for developers to collaborate with Claude directly in their workflow, including integrations with common IDEs.

And the "multi-agent" pattern is increasingly discussed as a practical design approach, not a futuristic one.

What this means for operations

If you run operations, this shift is both exciting and confronting.

Exciting, because many parts of ops work are repetitive by nature: reporting, documentation, process mapping, data exploration, QA checks, drafting internal comms, building simple tools.

Confronting, because it forces a question: if the "doing" becomes cheaper, what's the real role of ops?

My answer is simple: ownership and system design.

AI will reduce the cost of producing output. It won't remove the need to choose the right output, align people around it, and ensure the organisation can execute without breaking.

In fact, the more you automate, the more you need clarity on governance. Decision rights. Risk boundaries. Quality control. Escalation paths. Accountability for outcomes.

AI makes it easier to move fast. But moving fast without a clear operating model just means you can now create chaos faster.

Here's the uncomfortable truth: speed without expertise is just controlled chaos. A surgeon can make fast, confident decisions about a patient's care because they've performed thousands of operations. They understand human anatomy deeply. Not from reading textbooks, but from lived experience, from judgment calls made over a decade of practice, from knowing what "wrong" looks like before it becomes a crisis.

The same principle applies to operations and business systems. AI can accelerate your execution dramatically. It cannot replace the domain knowledge you need to guide it. If you haven't lived through your business model, spent years understanding your constraints, made hard calls yourself, and learned what actually matters then you'll move faster in the wrong direction. You'll have optimized something that wasn't worth optimizing. You'll have solved a problem that wasn't the real bottleneck.

I experienced this directly when I started coding with AI. I could generate code at scale. Functions, modules, entire features faster than I could have written them by hand. But without the experience of having built systems the hard way, I made architectural mistakes that a senior developer would have caught immediately.

The leverage of AI isn't that it removes the need for expertise. It's that deep expertise becomes even more valuable. Your judgment, your understanding of what matters, your ability to spot when something is dangerously wrong. These become the guardrails for how fast you can safely move. Without them, you're just giving powerful tools to someone who doesn't know how to use them.

The operator of the future

I recently came across a role description that captured a direction I think we'll see more and more: small teams, high autonomy, measurable financial outcomes, and AI-accelerated execution. The narrative wasn't "write decks and advise." It was "own outcomes, deliver impact, don't waste cycles on manual analysis."

Whether or not you like that style, it points to something real.

The future ops leader won't be judged by how many meetings they ran or how many documents they produced. They'll be judged by whether they can turn ambiguity into measurable improvements, repeatedly.

Think about the kinds of problems that now define "great operations" at scale. Preventing multi-million ARR churn every quarter by finding root causes and aligning product, support, and finance on fixes. Cutting cloud spend materially without hurting performance. Integrating an acquired business into a standard operating model in weeks, not months. These aren't "projects." These are transformation outcomes under constraints, with a scoreboard attached.

That shift changes the craft. Less "project management." More "system design + execution."

And AI becomes part of the operating toolkit the same way spreadsheets, CRMs, and BI tools became standard over time. You still need ownership, judgement, and accountability. But your default mode becomes AI-accelerated analysis, faster iteration, and tighter validation of results.

And the punchline is simple: in that world, the real bottleneck isn't effort. It's clarity: what to do, in what order, with what constraints, and what success looks like.

Co-pilot or autonomous

People ask whether AI becomes a co-pilot or autonomous. My view is: both.

For many workflows, co-pilot is already the default. Drafting, exploring, summarising, brainstorming, quick analysis. It's a powerful colleague.

But for certain domains, autonomy is close. Monitoring. Reporting. Routine data pulls. Maintaining documentation. Running standard checks. Suggesting next steps with an "approve?" loop. In my own small experiments, I saw how quickly it turns into "I can do X next, approve?" mode. That's the bridge from assistant to agent.

The pace of change is the only thing I feel confident predicting: it's fast enough that static job definitions and static org designs will break.

The uncomfortable takeaway

The part many people avoid is this: AI doesn't just make teams faster. It changes the economics of teams.

If a small number of humans can direct a large amount of agentic work, headcount growth stops being the default solution. The new advantage becomes your ability to design systems, set quality bars, and create accountability that scales.

This is why productive laziness matters. It's not about doing less. It's about refusing to do low-leverage work, so you can spend your attention on the few decisions that actually move the needle.

The organisations that win won't be the ones with the most tools. They'll be the ones that redesign their operating system around this new reality.

Next Steps

Book an execution mapping session — We'll diagnose where AI can unlock the most value for your team.

Related reading: 3+: The Meaning (and Why It Works) — The operating framework you need when clarity is your leverage. How to structure execution so teams deliver faster.

Also: Building with AI: speed, clarity, and the limits of craft — A practical look at what happens when you actually build something with AI, and why clarity becomes your real bottleneck.