← Back

What I Stopped Noticing

Six months into running an AI-assisted workflow, I made a minor change to my publishing pipeline.

Adjusted a path. Updated a config. The kind of thing I’d done dozens of times before it was automated.

It took me four times longer than it should have.

Not because the system had gotten complicated.

Because I had.

The trade you don’t see coming

When delegation works, it disappears. The pipeline runs, the output arrives, the work gets done. You stop thinking about the mechanism and focus on the output. That’s the whole point.

But something else disappears with it: your live familiarity with how the thing works.

Not the knowledge. The intuition. The ambient sense of what’s probably running, and why, and what to check first when something breaks.

That intuition is built through repetition. When you successfully remove yourself from the repetition, the intuition quietly drifts.

I knew this in theory. I didn’t feel it until I needed to step back in.

What actually erodes

There’s a specific experience I’m describing here, and I want to be precise about it.

It’s not “I forgot how to do it.”

It’s “I remember how to do it, but I’m out of the loop on the current state of it.”

The config change you made three months ago. The workaround that lived in your head because you dealt with it every week. The small decisions that never made it into documentation because they didn’t seem worth writing down at the time.

Those details fade. Not catastrophically. Just enough to slow you down at the worst moment: when something breaks and you need to recover fast.

In most situations, this is a fine trade. You freed yourself from the repetition. You built headspace for other things. The system runs quietly and the output is good.

The risk is the outlier. The moment the system breaks — or needs to change, or needs to be handed off — and your mental model is months out of sync with how it actually behaves now.

When it matters most

The obvious case is operations. Automated systems that run quietly until they don’t, and then require someone with recent, hands-on context to fix them quickly. The gap between “we have automation for this” and “we can debug this under pressure” is often what turns a small incident into a long one.

But I notice it in leadership too. Delegate a process cleanly for long enough, and your ability to evaluate it accurately starts to erode. Not because you can’t understand it — but because you’re no longer close enough to feel when it’s drifting.

That’s a different blind spot than not knowing something. It’s the blind spot of someone who used to know, and let the model go stale.

What I’m changing

I’m not planning to step back into manual work “to stay sharp.” That’s usually a rationalization for not trusting the system you built.

But I am building in re-entry points. Periodic moments where I walk the process manually — not because automation failed, but because I don’t want to become a stranger in my own systems.

Once a month, maybe: do the thing by hand. Not to micromanage what’s working. To keep the mental model from drifting further than it needs to.

There’s a difference between trusting a system and being dependent on it. Trust means you could recover if you had to. Dependence means you hope you never find out.

I want to stay on the right side of that line.

The honest admission

Six months without hands-on contact with that pipeline was too long.

The cost was low — a slow afternoon, a little frustration. In a higher-stakes system, the same drift would be more expensive.

The lesson isn’t “don’t delegate.”

It’s: delegation changes your relationship to the thing. Not just your workload. Your context, your intuition, your ability to step back in cleanly when the system needs you.

That’s worth accounting for.

Not with anxiety. Not by holding back from automation that actually works.

Just by being honest about what smooth delegation quietly costs — and deciding in advance how much of that you’re willing to pay.