The Accountability Nobody Assigned
When work moves from people to systems, execution may transfer cleanly. Judgment, context, and accountability often do not.
We tend to talk about accountability as though organizations designed all of it.
We draw the org chart. We write the job descriptions. We assign approvals, define reporting lines, and decide who signs off on what. When something goes wrong, we expect to trace responsibility back to a box on that chart.
But I have come to believe that some of the accountability that keeps an organization working was never explicitly designed at all.
It came bundled with the work.
The person who processed the transaction was also the person who noticed when a number looked wrong. The person who handled the case knew which exceptions mattered and why. When something went sideways, someone could explain what happened because they had been close enough to the work to understand it.
The task was visible. The judgment around it was not. Until now, it rarely had to be.
That is becoming consequential. More work is being handed to systems: workflows that route themselves, integrations that run overnight, automation that reconciles and updates without a person performing each step. AI is now beginning to interpret, recommend, coordinate, and act inside those workflows as well.
Consider one example.
A staff member at a union has spent years reconciling dues remittances from employers each month. She processes them, but she also knows them. When one employer’s remittance arrives noticeably lower than usual, she picks up the phone before closing the month. Usually, it is nothing. Occasionally, a payroll file dropped a group of members, and she catches it before the members are affected.
Now the reconciliation is automated. The system completes the routine matching faster, applies its defined controls consistently, flags the mismatches it was designed to flag, and closes the month on time.
But the system only knows what it has been taught to notice.
If an employer sends an incomplete file, the system may reconcile that incomplete file perfectly. Nothing fails. Every programmed step succeeds. The outcome is still wrong, and the first person to discover it may be the member.
Automating the reconciliation was still the right decision. She was spending days on work a system could do. The problem is that part of what she contributed had never been recognized as part of the process.
A technologist could reasonably respond that the system should simply flag any remittance that falls materially below its normal range. I agree. A system can perform that check every month, consistently and without fatigue.
But only if someone knows to ask for it.
Her judgment was never written down as a rule, so it never became a requirement. The limitation was not the automation. It was the organization’s incomplete understanding of what the work actually contained.
Most organizations have their own version of this. In a small business, it may be the bookkeeper who knows a particular customer always pays differently, or the operations manager who looks at a report and immediately says, “That can’t be right.” In a membership organization, it may be the coordinator who knows which request deserves a second look before anyone else sees it.
The Hidden Controls Inside Routine Work
Look closely at what that staff member was doing, and the job contained at least three responsibilities nobody had written down.
She was noticing. The system applies the checks it was given. She was doing something more contextual: deciding whether the result was plausible based on what normal looked like for this employer, this local, and this time of year.
She was resolving. When something did not fit, she often handled it herself: a call, a correction, a sticky note for next month. Many of those exceptions never became visible to the rest of the organization, because she quietly kept the process working.
And she was explaining. If an officer or member asked what happened with a particular remittance, she could answer, because she had touched the work and understood the path it took.
When reconciliation moved to a system, the execution transferred cleanly. Those responsibilities did not. Exceptions may now land in a queue, but a queue is not an owner. And when someone asks what happened, “the system processed what it was given” may be accurate without being remotely sufficient.
That is the gap leaders need to see.
The Better It Works, the Less We Look
There is an irony in successful automation: trust can reduce scrutiny.
When a new process goes live, people watch it closely. They compare results and keep the old spreadsheet open just in case. As the system proves itself, attention reasonably moves elsewhere. That is part of the capacity the organization wanted to recover.
But confidence can quietly become dependence. The question “does this result make sense?” is often not a formal control. It is something an experienced person asks almost unconsciously because they know the business, the customer, the member, or the history behind the data.
When that person stops touching the work, the quiet, habitual controls can disappear even though nobody decided to remove them.
Why the Org Chart Misses It
Redrawing the org chart will not solve this risk, because the chart was never where these responsibilities lived.
An org chart describes positions, reporting lines, and formal authority. It does not show the tacit controls embedded in the work itself: who notices the anomaly, who understands the exception, who knows when to escalate, and who can explain why the outcome makes sense.
Two people with the same title can carry very different amounts of this institutional judgment. Someone who has done the work for years notices things a new hire will not. The organization benefits from that difference over time, every day, often without recording that it exists.
There is also a structural mismatch. The work that systems carry forward increasingly moves across functions — from membership to finance to field staff and back again. The org chart is organized vertically. The work is increasingly executed horizontally.
So, when a workflow is automated, the governance around that workflow has to move with it. Otherwise, responsibility can simply fall between the boxes.
Ask What They Catch, Not Just What They Do
Most automation efforts begin with a reasonable question: What does this person do?
The answer becomes the requirements: steps, inputs, outputs, rules, and whatever exceptions someone remembered to mention.
I would add a second question with equal weight: What does this person catch?
That is harder to answer, because the person may not consciously know. Noticing that something looks wrong rarely feels like a task for an intuitive person. It feels like familiarity. Asked to describe their jobs, people naturally describe what they do, not the problems their experience prevents.
Draw it out. What would we stop knowing if this person stopped doing the work? What do they resolve that never reaches anyone else? What makes them suspicious? What do they know about “normal” that is not written anywhere? When something goes wrong today, who do we call, and who will own that answer once the system takes over?
Once identified, much of that judgment can be made explicit and handed to the system. The variance check our staff member performed by instinct can become a validation that runs every month. An exception she recognized from experience can become a rule, threshold, or escalation path.
Some of it will remain human. Recognizing when an unusual exception reflects a real problem, weighing competing consequences and tradeoffs, or explaining an outcome to the person it affects may still require human judgment. If so, that judgment needs an explicit owner, because the person who used to carry it by default is now doing something else.
That is the uncomfortable part. Some of what looks like routine administrative work is actually an unrecorded control. Automate the work without identifying the control, and an organization can become faster and less aware at the same time.
Governance Has to Move With the Work
More work inside organizations will move to systems, and, for the most part, it should. The purpose is not to preserve repetitive work for people. It is to give people the capacity to do the work where their judgment, relationships, and experience create more value.
At Arrayworks, this is one reason we think about a Digital Twin of an Organization as more than a map of intelligent workflows. If automation and AI are going to act on behalf of the enterprise, the model also has to capture what makes execution trustworthy and contextual: decision rights, thresholds, exceptions, escalation paths, ownership, and the evidence needed to explain and perform an outcome.
The moment work moves from a person to a system is, therefore, a rare opportunity. It is when the organization can most clearly see the knowledge, judgment, and informal controls that were hiding inside the work. Once the transition is complete, that knowledge tends to leave quietly.
The autonomous age will expose more than bad rules. It will expose the rules, controls, and institutional judgment we never realized we were relying on.
So, before the next workflow moves from a person to a system, I would ask one question that rarely appears in an automation project:
