Every founder and business leader has had this moment. A queue backs up somewhere, support tickets, onboarding, bookkeeping, and the fix that presents itself first is always the same one: hire someone to work through it. It's fast, it's visible, and the board doesn't ask hard questions about it. Six months later there's a person whose entire job is routing information between two systems that don't talk to each other, and nobody remembers deciding that should be a full-time role.
This article is not an argument that headcount is bad. It's a method for deciding, process by process, whether the next dollar of growth should be invested into additional headcount or build a system. Most businesses default to the person because it's easier to approve than it is to design a workflow. The businesses that scale without their coordination costs scaling alongside them are the ones that make that decision on purpose, with a process for it, rather than by default under deadline pressure.
The method in this article comes out of a specific field of management called systems thinking, which MIT Sloan Executive Education defines as understanding how the connected parts of a business, and the environment around it, interact to produce outcomes, rather than treating each problem as its own isolated event. A support backlog, a slow onboarding process, and a founder who can't take a real vacation usually look like three separate problems. Systems thinking treats them as symptoms coming out of the same wiring.
In practice, that means looking at a business through three lenses at once:
1. STRUCTURE (the processes, incentives, and rules producing the behavior you're seeing)
2. FLOW (how information and work actually move between people and systems, and where they get stuck)
3. FEEDBACK (the loops where one decision quietly reinforces or corrects the next one).
Most of the fixes in this article aim at one of those three. The four-step method later on is a structure-and-flow fix. The risk-tiering system is a feedback fix. The most common failure of all comes from ignoring feedback entirely, which is exactly the trap the next section walks through.
There's a well-documented failure mode in operations management, one of the feedback loops systems thinking is built to catch, sometimes called "shifting the burden". A problem shows up. Leadership has two options: a fast fix that treats the symptom, or a slower fix that treats the cause. The fast fix always wins, because it's available immediately and the slow fix requires upfront work before it pays off. So the team hires. The backlog clears. Everyone moves on.
The catch is what happens next. Hiring to clear a backlog solve this month's problem and it also quietly removes the pressure that would have forced someone to fix the underlying process. The team that built the workaround never gets asked to build the real fix, because the symptom is gone. A year later the business has three people doing work that a proper system would have made unnecessary, and undoing that is far harder than never creating it, because now there are salaries, management relationships, and institutional knowledge sitting on top of a process that shouldn't need a person at all.
None of this means never hire. It means treating "hire" as a choice you made, not a default you fell into. The rest of this article is a method for making that choice on purpose.
Look closely at the people whose jobs involve a lot of "checking two systems and updating a third," and you've found what's sometimes called "human middleware": the coordinators, project managers, and ops staff whose actual output is moving context from one place to another because the systems don't do it themselves. It's expensive, it's slow, and every handoff is a chance for something to get lost or misremembered.
The good news is that this particular tax is one of the more mechanical things to fix, and it doesn't require replacing anyone to start. Three moves tend to do most of the work:
Record what actually happens. Most operational knowledge lives in meetings and Slack threads that nobody can search six weeks later. An AI note-taker on every recurring meeting turns that into a searchable record instead of something three people half-remember differently.
Get decisions out of private DMs. If a pricing exception or a scope change gets approved in a direct message, it's invisible to everyone except the two people in that thread, including any system that might otherwise route around it. Moving approvals into a shared tracker costs a habit change, not a tool purchase.
Connect the tools you already pay for. A CRM, a support desk, and a billing system that don't share data force someone to be the human API between them. Basic integration tooling (Zapier, n8n, or a native integration your existing stack already supports) removes that job entirely for a huge share of routine handoffs.
This is also exactly the work covered in more depth in Orbflo's guide to mapping business workflows before automating them: you can't remove a handoff you haven't first written down.
Once a process is visible, the actual conversion into something automated follows a predictable shape, laid out in more formal terms in a recent methodology paper on agentic AI transitions. It doesn't require a platform team or a six-month engineering roadmap. It requires doing these four things in order, and not skipping the first one because it feels slower than just building something.
Write down every step someone currently takes to get from trigger to outcome, including the annoying manual ones nobody likes admitting to (checking a shared inbox, copying numbers between spreadsheets, texting a colleague to confirm something). The goal is a complete, unglamorous list, not a polished diagram.
Some steps in that list require real judgment: reading an angry customer's tone, deciding whether an exception is worth making, weighing a legal or financial risk. Most steps don't. They're pattern matching against structured data: checking availability, reconciling two records, formatting an output the same way every time. Only the second category is ready to hand to an agent today.
Each repeatable step becomes a narrow, bounded task for a specific agent rather than one system trying to do the whole job. This matters more than it sounds: a single agent asked to "handle onboarding" will be unreliable, while five agents each handling one well-defined step of onboarding will be boring and dependable, which is exactly what you want from infrastructure.
The person who used to do this work manually doesn't disappear. Their job changes from executing every step to supervising the system and handling the cases it flags as uncertain. That's a better job, and it's also the safety mechanism that keeps this from becoming the mistake in the next section.
Orbflo's practical blueprint for redesigning business processes for AI walks through this same sequence with more detail on step two, which is usually the one teams rush.
It's easy to assume this only works at companies with an engineering team to spare. A documented case study of a small tourism operator suggests otherwise. The business ran a manual daily scheduling process: reading booking emails, checking activity and guide availability, assigning customers to vehicles, resolving conflicts, and publishing a final plan to the field. All of it by hand, every day, under time pressure.
A single engineer, using agentic coding tools including Claude Code and Codex, rebuilt the process as a small network of narrow agents rather than one monolithic system: one agent read incoming booking emails, another reconciled changes against the reservation system, another checked third-party availability, another handled vehicle and route assignment, and a final agent compiled and published the daily sheet. Each agent did one job. None of them tried to do the whole thing.
What used to take hours of manual coordination each day now runs in minutes, with the humans who used to do the work supervising the output and stepping in on the exceptions the system flags rather than touching every booking by hand. Nobody on that team needed a platform team or a six-figure automation budget. They needed the process mapped clearly enough to split into agent-sized pieces, which is the part most businesses skip.
Orbflo's roundup of SME workflows with verified ROI covers three more examples in this same size range, if you want to see what's realistic before you commit engineering time to your own version.
This is the step that determines whether the whole exercise works or blows up in public. Not every process deserves the same amount of automation confidence, and treating a customer dispute the same way you treat a routine inventory reorder is how a good idea turns into a bad headline.
A useful way to sort processes is by how expensive a mistake would be, and how confident the system is in a given case:
The mechanism that makes this work in practice is confidence-threshold routing: the system scores its own certainty on each case and only acts alone above a threshold, handing anything below it to a person with full context attached rather than a cold handoff.
Klarna's 2024 AI push is worth studying precisely because it produced one clear success and one clear reversal inside the same company, in the same year.
On the marketing side, Klarna built an internal "Copy Assistant" that took over roughly 80% of marketing copywriting at a 70% cost reduction, cut image production time from six weeks to seven days, and eliminated a chunk of external agency spend on translation and social media management. Combined, the company reported around $10 million a year in savings, alongside a marketing team that shrank from 200 to 100 people while producing more campaigns, not fewer.
Source: Chief AI Officer's reporting on Klarna's marketing AI program.
That worked because a bad marketing draft is cheap to catch. A human still reviewed the copy before it shipped. The system removed repetition, not judgment.
The customer service rollout looked similar on paper and behaved very differently in practice. Klarna's support assistant handled 2.3 million conversations in its first month, roughly two-thirds of total chat volume, doing work the company estimated would otherwise have required around 700 additional agents, with a projected $40 million in annual savings. But roughly 15 months in, during 2025, Klarna walked part of it back. The assistant handled routine tier-one questions well and struggled on complex, emotionally charged, or dispute-heavy conversations, the exact cases where a wrong answer is expensive and hard to reverse. Klarna rehired specifically for disputes, fraud, and hardship cases, keeping the AI on the high-volume, low-risk work it was actually good at.
The lesson here is that the marketing program kept a human checkpoint exactly where mistakes were costly, and the first version of the support program didn't. Same company, same year, same underlying technology. The difference was where the checkpoints sat.
If you stop measuring success by team size, you need something else to measure. Three numbers, tracked together rather than in isolation, give a much more honest read than any one of them alone.
Sources for the targets above: SaaStr on the new revenue-per-employee benchmark, David Sacks on the burn multiple, and Aleph's 2025 CAC payback benchmarks.
Watch these three together, not one at a time. A business can post an eye-catching revenue-per-employee number while quietly burning cash on compute or contractor spend that never shows up in the headcount line. That's exactly the distortion a Subscript analysis on why revenue per employee is misleading in 2025 warns against: treat it as one input, never as the whole scoreboard. Track your API and infrastructure spend as its own line item too, separate from generic software costs, because that's usually where the hidden burn is actually hiding once headcount stops growing.
For a sense of how far this can go at the extreme end: Midjourney has run at roughly $500 million in annual revenue with a team in the range of 11 to 15 people, an outcome that says more about a product doing unusually much of its own operational work than it says about any specific headcount target you should aim for.
None of this requires a transformation program. It requires picking one real process and running it through the method above before you approve the next hire meant to patch it.
Pick the process that's already causing the most complaints. Not the most interesting one to automate, the one someone on your team is already unhappy about doing manually.
Map it in full before you touch any tooling. Every step, including the embarrassing manual ones. If you can't describe it in writing, you can't hand pieces of it to an agent.
Decide your risk tiers before you build anything. Know in advance which parts of this process get a human checkpoint and which don't, rather than discovering the answer after something goes wrong.
Put a review date on the calendar the day you launch. Klarna's mistake was going too long without revisiting the customer service version once volume and complexity outgrew what it was tested on.
Where to start
Before you map a single process, it helps to know where your business actually stands across the capabilities that make this kind of transition work. Orbflo's AI Operating System Scorecard scores that in about ten minutes.
Take the AI Operating System Scorecard →
No. It means treating each hire as a decision rather than a reflex. Some work genuinely needs a person, especially anything involving judgment, relationships, or the exceptions your automated systems flag. The goal is to stop adding headcount purely to move information between systems or clear backlogs that a workflow fix would have prevented.
The one generating the most internal complaints, not the most technically interesting one. It's usually high-volume, repetitive, and coordination-heavy rather than customer-facing and judgment-heavy. Map it fully before deciding what to automate; Orbflo's guide to mapping workflows before automating them walks through exactly how.
Smaller than most founders assume. The tourism scheduling example above was rebuilt by one engineer using off-the-shelf agentic coding tools. What made it work was a process mapped clearly enough to split into narrow, well-defined pieces.
The AI Operating System Scorecard is a diagnostic tool that measures whether your business is structurally built to make AI compound, across nine dimensions including how decisions get made, how clearly your processes are defined and how your team is using and integrating AI.
The output is a clear view of where your biggest leverage gaps are and where to focus first.
One practical AI operating-system insight bi-weekly.
No fluff, no spam.
© 2026 AV Ventures Limited trading as Orbflo | All Rights Reserved
