When not to hire: a founder’s test

The uncomfortable default

As founders, we’re rewarded for action. Revenue grows, incidents spike, a new opportunity appears—and the reflex is to open a role. Headcount feels like control. I’ve learned to resist that reflex. The most expensive hires I’ve made were not the people; it was the decision to use a person to hold together a system that should have held together on its own.

This essay is the test I use before I add a seat. It’s not anti‑hiring. It’s pro‑leverage: make sure the system (and now, agents) carry the load so people can do the work only people should do.

Questions I ask before I open a role

Is this work recurring or is it a spike? If it’s a spike, redesign the system so the spike is absorbed once and doesn’t recur. If it’s recurring, ask whether the recurrence exists because we normalized a workaround.
Is this outcome better as a product improvement than as a person? If I can change a flow, a definition, or an interface and remove 70% of the effort, that’s better than scaling effort with bodies.
Would a person here become glue between tools? If the primary output is moving information from System A to B, that’s a system problem. Don’t hire glue. Remove the seam.
Is the work decision‑heavy or decision‑light? Decision‑light tasks are automation’s home turf. Decision‑heavy work is where human judgement pays for itself.
Do we own this work, or are we renting it from a vendor process? If we don’t own the core behavior, a hire ends up negotiating exceptions forever. Fix ownership first.

When these answers point to the system, not the seat, I don’t hire. I change the architecture and instrumentation until the work is boring enough to disappear or valuable enough to need judgement.

Signs a hire is masking an architecture problem

Over the years, a few patterns reliably tell me we’re about to hire a human patch:

Tickets that describe movement, not outcomes: “reconcile,” “follow up,” “check status,” “re‑key.” These are descriptions of drift between systems, not customer value.
Incidents that start with “Could you just…”: The request is small because the system doesn’t make the behavior possible. A person will make it possible once; the system should make it possible always.
Heroic individuals holding knowledge in their heads: If one person can “make it work,” the work hasn’t been made legible to the system.
Roadmaps that add features to cope, not to improve: If we design around noise, we enshrine it.

In each case, the temptation is to protect the team with more capacity. The right move is to protect the team with clarity—make the system responsible for the behavior so people aren’t.

Roles to hire early—and gladly

There are roles I’ll hire for without apology because they compound.

Judgement: People who can name the problem behind the problem and make choices under uncertainty. They prevent a hundred bad tasks from existing.
Customers: People who sit close to the market, listen well, and turn messy input into shaped demand. They help us ship what matters.
Taste: Builders and designers who raise the standard and remove friction. They eliminate entire categories of confusion.

These roles change the slope of the company. They don’t carry buckets; they alter the terrain so fewer buckets are needed.

How agentic AI changes the calculus

Small teams used to accept that certain classes of work required people. Today, agentic automation moves the line. Tasks that are structured, observable, and bounded by clear outcomes can be handled by agents that watch for conditions and take safe actions. That doesn’t replace judgement; it makes judgement more available where it matters.

The key is ownership. At ElkanIO we built a coherent core for our travel platform—I call it Synapse—but the name matters less than the posture: decide what the system is responsible for, and make it legible enough that an agent can operate confidently. When that’s true, adding a person is no longer the default answer to every exception. The system learns; the team leads.

The price of hiring to cover patchwork

Hiring into a messy stack looks like relief and behaves like debt. Here’s what I’ve paid in the past when I’ve reached for headcount too early:

Coordination drag: Each new person creates more edges. Meetings multiply to explain context the system should have made obvious.
Loss of signal: When humans carry state, leaders hear anecdotes instead of seeing reality. Decisions get slower and more political.
Reduced learning: Manual work hides the places the product needs to change. You can’t instrument what lives in someone’s spreadsheet.
Cultural tilt toward coping: Teams get good at firefighting and less good at design. “How do we handle this?” replaces “Why does this exist?”

I wrote earlier about the “patchwork mentality”—when a business grows by stitching together tools and adding bodies at the seams. If that’s familiar, this piece is the counterweight: a check against hiring your way into a maze. See: The patchwork mentality in travel tech.

A simple test I use

Before I approve a role, I run a quick test:

If this person started tomorrow, what would they do on day one? If the answer is “connect these two tools” or “watch this queue,” I’m not hiring; I’m redesigning.
What would have to be true for this role not to exist in six months? If I can name two product or process changes that erase most of the workload, I’ll make those changes first.
If an agent could do 60–80% of this safely, what remains that truly needs human judgement? I’ll define that human part and scope the role to it—or, if what remains is small, I won’t open the role at all.

This test sounds austere. It isn’t. It’s generous to teams. It refuses to hand them problems the system can and should own. It creates space for people to do the work only people can do: decide, design, lead, and build with taste.

What changes after you stop default‑hiring

When the company stops treating headcount as a reflex, three good things happen:

You get clearer about outcomes. Roles are written around decisions and results, not chores.
Your product gets better. Every non‑hire forces clarity about where the product needs to hold more of the work.
Your pace improves. Less glue means fewer meetings and faster loops between customers, product, and engineering.

That’s when hiring becomes a real investment again. You hire because there’s compounding work to do—not because the system needed another pair of hands to hold it together.

If you want a quick sense of my background and what I’m building, the About page has more.

Closing

I don’t avoid hiring. I avoid hiring to cover for patchwork. When I do add a seat, it’s because the person will widen our judgement, deepen our taste, or get us closer to customers—never to become glue. If you’re working through similar decisions and want to compare notes, I’d love to talk.

Get in touch →