The First AI Hire Is a Worse Bet

For the owner of a $5–20mm company who has already decided they are behind on AI.

I keep having the same call. Owner of a company somewhere between five and twenty million. Twenty to a hundred people. They have already decided they are behind on AI. The decision they want help with is the hire. Head of AI. AI lead. Someone who can own this. The req is usually written before anyone has named the process.

That hire is the expensive way to not choose.

The room

The conversation starts with a feeling and tries to end with a person.

Revenue is fine. Margins are tighter than they were two years ago. The owner is in the operation more than they want to be. Support, or scheduling, or the inbox that still lands on them after 7pm. They have seen a demo. A peer told them they hired an AI guy. A vendor told them the model can do the job of three people. Somewhere in that pile, a sentence forms. We need someone to figure this out.

Ask what this is and the room gets quieter. Not because they are stupid. Because the hire is standing in for a decision they have not made. Which work stops being done by a person. What that is worth. Who owns the thing when it is wrong at 11pm. Those are operating questions. A req is not an answer to them. It is a way to move them onto someone else's calendar.

I sell the other side of this. I run GoZupees. We put AI agents on live work for companies this size. Voice, intake, the repetitive service jobs. Read this knowing I would rather you spend the money on a system than on a seat. The bias is declared. The pattern is still what I see when I am not the one selling.

What the first hire actually becomes

At this size you do not have an AI function. You have an owner, a handful of managers, and a set of processes that still depend on one person remembering how they work.

Drop a new hire into that and they have three bad options.

They become a prompt librarian. They write things for the sales team, summarize meetings, and produce a monthly note about tools. Useful, sometimes. It is not a strategy, and it will not show up in the number the owner actually cares about, which is usually cost, coverage, or a role that has been open too long.

Or they become a pilot manager. Six weeks of a tool, a slide, a we learned a lot. Nothing carries real work. Nobody gets paged. A pilot is how a hire stays employed without changing the operation.

Or they leave. Not because they are bad. Because they were hired to own a function that does not exist, in a company where the only person who can change a process is the owner, and the owner hired them so they would not have to.

The companies that make this work do not start with the person. They start with a process that already has an owner and a number. Then the person, if they hire one, is the person who runs that system. Reviews it. Catches the edge cases. Decides what escalates. That is a real job. It is also the job you can design after the process exists. Not before.

Why the second process, not the first

The first process people want to automate is the one that is loud. The one a vendor demoed. The one that makes a good story at dinner. It is rarely the one they already have a number for.

The second one is quieter. It is the queue the ops lead has been complaining about for a year. The after-hours line. The intake form that still gets retyped. The job they have failed to fill for eight months, so the owner is covering it on Sundays. They know the volume. They know what it costs when it slips. They know who gets the angry call.

That is the process that should go first. Not because it is the most impressive. Because the business case is already written, in the owner's head, in units they already manage. Containment. Cost per contact. Hours after 6pm. A req that can stay closed. If you cannot say the number, you are not ready to hire someone to find it. You are ready to go count.

And the second process has another advantage. Someone already owns it. The ops lead. The office manager. The founder, unfortunately. Automation does not need a new department. It needs that owner to stay the owner, with the repetition taken out and the judgment left in. I have watched a receptionist become the person who runs the agent. That only works if the process was theirs before the software showed up.

The first process often fails for the opposite reason. It is chosen because it is automatable, not because anyone owns the outcome. Then it breaks, and there is no one to page except the new hire, who does not have the authority to change the process, which was the actual work.

The spreadsheet, and the hour it ignores

The words that get a budget signed, at this size, are not transformation words. They are cost words and coverage words. What does a contact cost. What happens after 6pm. What do we stop hiring for.

What almost never gets modeled is the freed hour. The hour the person gets back when the process no longer needs them for the repetitive half. That hour has three uses. You bank it. Margin up, headcount drifts down through attrition, and you have chosen the cost case you signed. You reinvest it. The person works the thing you have been postponing, the one that actually needs a human. Or you split it, which is what most companies do, without writing it down.

The AI hire is often a way to avoid that meeting. If someone else owns AI, the owner does not have to decide what the hour is for. The hour then gets decided by default, usually by the accountant, usually as cost. That is a legitimate choice. It is a bad one to make by not making it.

I do not think every company this size should automate something this quarter. I think the ones that should can already name the process and the number. If they can, they do not need a head of AI to start. They need the owner of that process in the room, and a decision about the hour, written down before the tool is.

If they cannot name the process, the hire will not find it for them. They will find a pilot. Pilots are how you spend a year feeling modern and still answering the same inbox at 7pm.

What to do Monday

Do not open the req.

Take one process you already have a number for. Not the loudest one. The one you could explain to your bookkeeper in a sentence. Write three things on a page. What it does today. What it costs, or which role it is covering. What you will do with the hour if the repetitive half goes away. Bank, reinvest, or split. Pick one before anyone sends you a proposal.

If you cannot fill in the number, that is the work. Counting. Not hiring.

If you can fill it in, you already know whether you need a person. Most of the time you need the person who already owns the process, plus a system, plus a written answer to the hour. The specialist comes later, when you have a second and a third, and the question is how they share an operating model. That is a different hire. It is also a better one, because the job exists.

Four issues of this newsletter were about what AI does to jobs in the abstract. The argument that kept surviving was smaller than the headlines. The decision is not made in a lab. It is made in a room like yours, by someone who has to sign the spreadsheet and then live with the hour.

That is the beat from here. Not the future of work. The next process, and what you do with what it gives back.

Tell me the process. If you want, tell me the number. I read the replies.

Sandeep Bansal is the founder of GoZupees. He sells the systems this essay is about, which is why the hire looks expensive to him, and why you should check the argument against your own spreadsheet rather than his.