We Hired a Developer to Automate Our Work. The Operations Team Did It Better.

We hired a developer to automate a reporting job that was costing our operations team two afternoons a week. Six weeks later we had clean code, a developer who had never once seen that report used for a decision, and a coordinator still checking every output by hand because the exceptions had never made it into the brief.

So we tried it from the other end. The coordinator who actually ran the process learned the automation tool and rebuilt the thing themselves. That version went into production and stayed there.

At FameNinja we have now watched this play out often enough that I have stopped calling it a fluke. The people who already do the work tend to build better automation than the people hired to automate it, and the reason has very little to do with technical ability.

The knowledge is in the doing, not in the brief

The developer wrote better code. That was never the problem. What a developer cannot have is the list of exceptions living in the head of whoever runs the process every week: the client who sends the file in the wrong format every single month, the step that fails quietly when a holiday shifts a date, the approval that is mandatory on paper and skipped in practice.

None of that reaches a requirements document. It cannot, because the person being interviewed does not experience any of it as knowledge. It feels like just doing the job.

So the brief describes the process as it is supposed to work, the build matches the brief, and then reality turns up. Someone has to sit and supervise the tool that was meant to remove work. That is how a business ends up with automation that adds a checking step rather than deleting one.

Tool literacy is easier to teach than process knowledge

The standard advice is to hire the technical person and have them interview the operators. We did that. It creates a translation problem running in both directions, and the losses are worst exactly where the process is messiest, which is the part you most wanted automated.

Turn it around and the translation disappears. An operations person learning a workflow tool is not learning to program in any serious sense. They are learning to describe a process they already understand to a machine, using a tool built for that specific purpose. In our team, the people who took to it fastest had no technical background at all. They were simply the ones who had grown impatient with their own repetitive work.

That impatience turns out to be the real hiring signal. It is also visible in people you have already employed, which is cheaper than a recruitment round.

What this changed about how we manage

Two things, both unglamorous.

The first is that the time has to come out of the working week, not out of evenings. If you tell an operations person to learn automation in their own time, you have not funded a capability; you have made a wish. We block the hours, and we accept that output dips while somebody is learning.

The second is that the first build has to be small and owned by the person who built it. Not the biggest bottleneck in the business. Something irritating, contained, and theirs, where a failure costs an afternoon rather than a client. Confidence with these tools comes from shipping something that works, and the fastest way to kill the whole idea is to hand a beginner the process that everything else depends on.

The failure mode is real and it costs you

One morning our automation stack simply stopped. Nothing had been deployed and nothing obvious had changed. There were 1,159 executions sitting stuck in a queue that should have been empty, and work several people assumed was happening quietly in the background had not happened for hours.

The uncomfortable part was not the incident. It was how few people could open the thing and look.

When operations staff build the automation, knowledge concentrates in whoever built it, and small businesses are already too dependent on individual people. Our correction is deliberately low effort. Every workflow has a second person who has opened it and walked through it once, and every workflow has a plain language note at the top saying what it is supposed to do and what should happen when it fails. Neither of those is technical work. Both get skipped constantly, right up until the morning they are needed.

The tradeoff

You get slower first builds. You get less elegant ones, and occasionally you get something a professional would wince at.

In exchange, the automation matches the job as it is actually performed, and the person maintaining it knows why every branch exists. The capability also stays inside the business rather than walking out when a contract ends. For a company running a remote team of twelve to fifteen people, that last point decides whether automation compounds or quietly rots.

There is a version of this argument that overreaches, so I will be precise about where it stops. Some work genuinely needs an engineer, and pretending otherwise is how small companies build fragile things they cannot support. The claim is narrower. For the repetitive internal processes that consume a small team's week, the constraint has almost never been access to technical skill. It has been that the person who understands the work was never given the tools or the hours to fix it themselves.