.png)
When a manufacturer decides to automate, the first instinct is to hand it to the operations manager. They know the processes better than anyone. They have the credibility with the floor team. They understand what needs to change and why. They are the obvious choice.
That logic is exactly wrong.
The operations manager is the most expensive person to pull off their actual job. And automation ownership, done correctly, is a full-time job. Giving it to someone who is already responsible for running production creates a conflict that automation loses every time production has a problem, and production always has a problem.
This is not a criticism of operations managers. It is a structural argument. The role of running operations and the role of owning automation are in direct competition for the same resource: this person's attention and time.
The reasoning is understandable. The operations manager:
All of that is true. None of it makes them the right automation owner.
When production runs smoothly, the operations manager has time to think about automation. When something breaks on the floor, when a major customer order is expedited, when a supplier fails to deliver, that time disappears immediately and completely.
Automation projects require sustained, focused attention over weeks and months: scoping, reviewing builds, testing, managing adoption, monitoring after go-live. That kind of sustained attention is incompatible with a role where the primary responsibility is keeping production running.
In practice, the automation project advances during slow weeks and stalls during busy ones. Because manufacturing businesses are consistently busy, the project stalls far more than it advances. Most automation projects that are assigned to operations managers are still "in progress" eighteen months after they started.
The operations manager's expertise is in making the existing process work. Their institutional knowledge, their credibility with the team, and their performance evaluation are all built around the current state of operations.
Automation requires a different orientation: not "how do we make this process run better" but "which parts of this process should not exist in their current form at all." That is a harder question to ask when your performance is measured by the output of the current process.
This does not mean operations managers are resistant to change. It means the incentive structure pulls against the redesign mindset that effective automation ownership requires.
Owning an automation is not the same as using one. The owner needs enough technical context to evaluate whether a workflow is doing what it is supposed to do, to catch when an exception path is missing, to understand an error log, and to communicate clearly with a developer when something breaks.
This is not a deep technical skill set. But it is different from operations management expertise. An operations manager who cannot read a workflow diagram or interpret an API error message is dependent entirely on the developer's assessment of whether the automation is healthy, which is not a sustainable ownership structure.
Before identifying who should own automation, define what the job requires:
One person whose full-time job is finding, scoping, building, and maintaining automation workflows. They sit within operations, IT, or a dedicated function depending on the organization.
Best for: Organizations running or planning to run five or more automated workflows, with ongoing automation work. The economics justify a dedicated role when the output of automation is material to the business.
Watch out for: Hiring too broadly. The role requires both technical depth (enough to build in n8n or a similar tool) and process knowledge (enough to understand what they are automating). A pure developer without operational context builds technically correct workflows that solve the wrong problem. A process expert without technical fluency cannot maintain the workflows they design.
A partner (agency or consultant) scopes and builds the automation. At handoff, a named internal person takes ownership: monitoring the execution log, responding to exception alerts, and escalating technical issues to the partner under a maintenance agreement.
Best for: The first build, where no internal technical capacity exists yet. Also appropriate when the build is complex enough (custom ERP integrations, multi-system workflows) that building in-house is not feasible.
Watch out for: The black box problem. If the partner delivers a working automation without documentation, the internal monitor cannot diagnose issues, cannot train a replacement when they leave, and cannot modify the workflow when business rules change. Require a runbook and an error log structure as part of the handoff deliverable.
A senior operations leader holds strategic ownership: they define what gets automated, set the success criteria, and ensure adoption. A technically capable person on their team (a data analyst, a systems administrator, an IT team member with some development background) holds operational ownership: they build, monitor, and maintain the workflows.
Best for: Organizations that have a technically capable person with available bandwidth who is not already stretched across critical systems, and a senior operations leader who will actively sponsor the work.
Watch out for: The bandwidth problem. The technical team member in this structure is often being asked to own automation on top of their existing responsibilities. If their primary job has variable demands, they will face the same availability conflict as the operations manager. This structure works when the technical person has genuine protected time for automation work.
Who currently owns your automation initiatives? Is that person's job performance evaluated on automation outcomes, or on something else?
If the answer is "no one owns it" or "the operations manager owns it in addition to everything else," you do not have an automation owner. You have an intention.
Automation that is no one's primary responsibility becomes no one's priority when production pressure hits. That is not a people failure. It is a structure failure. The fix is structural: assign ownership clearly, protect the time, and evaluate the owner on outcomes that are specific to automation performance.
That conversation, deciding who owns it and what they are accountable for, is usually more valuable than the first build itself. The build without the owner fails. The owner without a build gets one built.
If you are still working out the ownership question, that is a good starting point for a call.
.png)
