---
title: "Your Automation Should Be Built by the Person Doing the Job, Not the One Who Can Code"
url: "https://cooinsider.com/insight/your-automation-should-be-built-by-the-person-doing-the-job-not-the-one-who-can-code/"
author: "Ankush Gupta"
published: "2026-10-01"
updated: "2026-10-01"
---

# Your Automation Should Be Built by the Person Doing the Job, Not the One Who Can Code

One morning our automation instance had 1,159 executions stuck in a queue. Nothing had crashed. No alert fired. Work went in and stopped coming out, which is how this tends to break in the cases we run, quietly, while everyone downstream assumes the last step ran. The person who traced it and cleared it was not an engineer. They run operations, and they had taught themselves the workflow tool because the alternative was doing the same task by hand every week.

That is not a story about one unusually capable hire. Across the internal automation we have built at FameNinja and inside the publishing network we run, the same pattern keeps showing up. Operations people who learn the tooling produce better automation than the developers we have brought in to build it for them.

### **The build was never the expensive part**

Picture a workflow that reads a submission, sends it to a model, scores what comes back, routes it and pings a human. A competent developer assembles that quickly. That part is cheap.

The expensive knowledge is the exceptions. Which client's drafts never go out without a human read. Which request looks routine and is not. What happens when a PR draft returns from AI-detection scoring at a borderline number and somebody has to choose between another rewrite pass and picking up the phone. In our own pipeline, every one of those rules came from the people producing the work, not from anyone who could write the API call.

You can hand the rules to a developer, of course. But to hand them over you first have to know them, write them down, and sit through the meeting where half of them are misunderstood. The person who knows them is the same person still doing the task manually while the specification gets agreed. The briefing becomes the bottleneck, and the finished workflow encodes whatever survived translation.

### **Operators instrument for the failure they have already been blamed for**

Developers build the happy path well. Our ops people build for the morning it broke and they had to explain it to a client.

One of our internal tools chases up unfinished tasks. A developer asked to build that would ship reminders. The version our team built escalates on a schedule, because they already knew which reminders get ignored, by whom, and at what point a nudge has to become a phone call. Nobody specified that. It was simply what the builder had lived through.

The same instinct shows up as manual overrides and off switches scattered through our workflows. From a distance that looks like a lack of confidence in the automation. It is not. It is what people install when they know they will personally be the one apologising.

### **What we do now**

Four rules, and they are close to the whole system.

The tool goes to whoever has the repetitive job. We do not route automation requests through a single central builder who then queues them.

Learning hours are paid operations time, sitting on the calendar like any other work, not something to pick up after hours.

A workflow does not go live until the person who built it can say out loud what happens when it fails and who hears about it first.

Whoever builds it keeps it. Ownership does not quietly transfer to a technical person once the thing is working.

### **The tradeoff**

This is slower. Builds take longer, the workflows look worse on the inside, and two people on a team of twelve to fifteen will occasionally solve the same problem twice without noticing. A developer would have produced something tidier and would have produced it sooner. If you are judging by the shape of the build, you will lose that comparison every time.

What you get back is that the person who can fix it is already in the room and never had to be briefed on the business to begin with. Key person risk does not disappear. It moves, and you document against it deliberately rather than pretending a contractor removed it.

There is a limit, and it is worth marking. This does not extend to anything with a wide blast radius. We have had a messaging outage land mid-deploy on a production service, and that was never going to be solved by an operations person with a workflow builder. Infrastructure still needs engineers. The territory this argument covers is the layer above it, the routing and chasing and checking that currently eats your team's afternoons.

So before you open a role for someone to come and automate your operations, look at who is already doing that work by hand. Ask what happens if you give them the tool, the hours and the authority instead. In the cases we run, the answer has been better than the job description we were about to write.

---

Ankush Gupta is a Fractional CMO at [FameNinja](https://fameninja.com), where he works on online reputation management, digital PR and marketing automation.