A Stoic examination of attachment to process reveals why selective automation outperforms comprehensive automation
Have a question about this? Bring it to Aurelius.
Ninety-seven automated processes. One engineer. Still at her desk past eight o'clock most evenings.
Sarah built scripts the way some people collect tools — each one justified, each one functional, each one quietly consuming a portion of her life she never budgeted. Her colleague Marcus automated twelve processes over the same eighteen months and walked out at five-thirty with the calm of someone who had already finished thinking.
The gap between them was not skill. It was not ambition. It was the question Marcus asked before writing a single line of code, and Sarah never asked at all: does this process deserve to exist?
Sixty-seven percent of data teams automate workflows that could simply be eliminated. That number is worth sitting with. Not because it indicts anyone, but because it names a pattern most of us recognize the moment we stop moving long enough to look.
Sarah's scripts worked. Her daily quality checks ran clean. Her weekly reporting refresh fired on schedule. Her monthly reconciliation closed without error. The machinery was flawless. The question she had not asked was whether the machinery served anyone.
Marcus spent three weeks before his first commit mapping every process to a decision someone actually made. He found that forty percent of his team's reports went unread — not skimmed, not filed, not referenced in meetings. Unread. He did not automate those reports. He buried them.
The executive receiving seventeen dashboards but acting on three is not informed. She is buried under the appearance of information. Automating the other fourteen faster would not have helped her. Removing them would.
This is the distinction between motion and progress — a distinction the examined life demands we make honestly, even when honesty is inconvenient.
In Book III of the Meditations, Marcus writes: "Confine yourself to the present." It sounds simple until you apply it precisely. He is not counseling passivity. He is naming the Stoic principle of the hegemonikon — the governing faculty, the part of you that directs attention and assigns value. When the hegemonikon is undisciplined, it latches onto effort rather than outcome, onto the comfort of visible work rather than the harder question of whether that work matters.
Sarah's automation attachment was a failure of the governing faculty. Having invested real effort in ninety-seven scripts, she experienced dismantling any of them as loss. The Stoic term for this is oikeiôsis in its corrupted form — a misidentification of the self with what the self has produced. She was not maintaining pipelines. She was defending herself.
This reveals something conventional advice about workflow efficiency consistently misses: the hardest processes to eliminate are the ones you built yourself. Not because they are technically complex, but because removing them feels like a confession. It feels like the months spent building them were wasted. Marcus did not feel this because he had never confused the script with the outcome. He held them separately from the start.
The Stoic dichotomy of control is useful here, but not in the way productivity culture applies it. It is not about accepting what you cannot change. It is about correctly identifying what is actually in your control in the first place. Sarah believed she was controlling her team's data reliability. She was, in fact, controlling the number of scripts she owned. Those are not the same thing.
Book IV, 3: "Our life is what our thoughts make it." Sarah's thoughts were organized around the automation infrastructure she had built. Her Monday mornings began with monitoring ninety-seven processes. Her Tuesday afternoons involved debugging edge cases in workflows that fed reports nobody opened. Her working life had become a maintenance contract on her own past decisions.
Therefore: the question is not how to automate more efficiently. The question is whether the thing being automated is worth the attention of a human life. Marcus asked this first. Sarah never asked it at all.
What most people miss is that this is not a technical problem. It is a problem of examined work — of whether you have looked clearly at what you are doing and why, or whether you are simply moving because movement feels like virtue. The Meditations were written by a man running an empire who still found it necessary to remind himself, daily, that busyness is not the same as purpose. He wrote those notes to himself because the mistake is that easy to make, and that costly to sustain.
If you are maintaining processes you built eighteen months ago without asking whether they still serve a decision anyone makes, you are not managing a pipeline. You are managing a monument to past effort. Aurelius would recognize this immediately. He spent years learning to dismantle his own.
Sarah recognized within six months that her automation wasn't reducing her workload. She continued building anyway. In teams we've spoken with, the average gap between recognizing this pattern and acting on it runs to fourteen months. That is not a technology problem. That is the weight of sunk effort pressing against clear judgment.
The scripts she had built required monitoring. Monitoring required decisions. Decisions required context. Context required meetings. The automation had not removed human attention from the pipeline — it had redistributed that attention into maintenance work with no visible ceiling.
Scalable Enterprise Data Workflows with AI addresses this directly: the architecture question and the elimination question must be asked together, or the architecture expands to fill whatever space you give it. A workflow that reduces processing time by seventy percent on a process that shouldn't exist is still waste — faster waste, but waste.
Marcus's three-week mapping exercise was not delay. It was the work. Every process he chose not to automate was a decision he made deliberately, with his eyes open, and did not have to revisit. His twelve scripts ran. He understood why each of them ran. He could have explained the business value of each one in a single sentence without checking his notes.
Sarah could not have done this for most of her ninety-seven. That asymmetry tells you everything about which engineer was flourishing and which was occupied.
Before you close this tab, open the list of automated processes your team currently runs — all of them, including the ones that "just work" and haven't been reviewed in months.
For each one, ask a single question: what decision does this process inform, and who made that decision last quarter because of it?
If you cannot answer that question in one sentence, the process is a candidate for elimination, not improvement. Use Run the Decision Test on Every Metric in Your Current Report to move through this quickly. It is not a comfortable exercise. It is not meant to be.
Then look at your reports. If you are generating summaries that reach executives but don't visibly change what those executives do, the issue is not the format or the frequency. The issue is that the report is not connected to a decision. Turn Raw Data Into Executive Summaries That Actually Get Read works through how to rebuild that connection before you automate anything further.
If your team is spending money on cloud infrastructure to run processes that fail the decision test, Pinpoint Which Cloud Cost Category Is Bleeding You Dry will show you where the spending is concentrated — and Tag Every Line on Your Cloud Bill Before You Cut Anything ensures you cut with precision rather than panic.
One week. One honest inventory. That is not a small thing.
Go deeper with Aurelius
Apply this to your actual situation. Aurelius will meet you where you are.
Start a session