Podcast Script: January 23, 2026

Hey, it’s Paul. January 23rd, 2026.

Here’s something I’ve been thinking about: the steps that don’t feel like steps.

You know the kind. The thing that takes thirty seconds. Checking a box, copying a file, running a quick command. Individually, each one is nothing. You barely notice doing it. But collectively? They’re the reason half the things you mean to do never actually happen.

I was working on some automation this week—doesn’t matter what specifically—and I noticed a pattern. There was this task I’d been meaning to do for weeks. It wasn’t hard. Maybe five minutes of actual work. But it required remembering to do it at the right moment, then doing three small preliminary things, then the actual thing, then two follow-up things to make sure it stuck.

Seven steps. None of them difficult. Total time maybe eight minutes.

I’d been putting it off for three weeks.

This is the thing about friction that I think we dramatically underestimate. We talk about friction like it’s a minor inconvenience. A speed bump. Something that slows you down a little but doesn’t fundamentally change your behavior.

That’s wrong. Friction doesn’t slow you down. Friction stops you entirely.

There’s research on this—behavioral economics stuff about how adding even one step to a process dramatically reduces completion rates. Make people click one extra button to donate to charity and donations drop by half. Require one additional form field and signups crater. The step itself is trivial. The effect is not.

What’s interesting is why this happens. It’s not that people are lazy, exactly. It’s that every step is a decision point. And decision points cost energy. Not physical energy—mental energy. The kind that’s finite and depletes throughout the day.

When you have a seven-step process, you’re not really asking someone to do seven things. You’re asking them to make seven micro-decisions. Should I start this now or later? Did I do step two correctly? What was step four again? Each decision is tiny, but they accumulate. By step five, you’re not thinking about the task anymore. You’re thinking about whether this is worth the effort.

And increasingly, the answer is no.

So here’s the thing about automation that I think most people get backwards.

The common framing is that automation saves time. You take something that takes ten minutes and make it take ten seconds. Great. You saved nine minutes and fifty seconds. Multiply that by however many times you do it, calculate your hourly rate, feel good about the efficiency gains.

This framing is technically correct and completely misses the point.

The real value of automation isn’t the time saved. It’s the decisions eliminated.

When you automate something properly—and I mean properly, not just “wrote a script that mostly works”—you’re not just making it faster. You’re removing it from the list of things you have to think about. You’re taking a seven-step process and collapsing it into zero steps. Not one step. Zero. It just happens.

And here’s what’s interesting: the difference between one step and zero steps is bigger than the difference between seven steps and one step.

One step still requires remembering. One step still requires deciding when. One step still requires checking that it worked. One step is still a thing on your list, taking up mental space, creating low-grade anxiety about whether you’ve done it yet.

Zero steps is freedom. Zero steps means you can forget the task exists entirely, because it’s handled. The infrastructure does it. You don’t have to.

I think this is why so many productivity systems fail. They’re designed to help you manage your steps more efficiently. Better task lists. Smarter reminders. More sophisticated prioritization schemes.

But the problem isn’t that you’re bad at managing steps. The problem is that steps exist at all.

The most productive people I know aren’t the ones with the best systems for tracking what they need to do. They’re the ones who’ve systematically eliminated the need to track things in the first place. They’ve built environments where the right thing happens automatically. Where the infrastructure handles the routine so their attention can go to the interesting problems.

This sounds obvious when I say it out loud, but I don’t think it’s how most people approach their work. Most people, when they notice friction, try to push through it. They add the task to their list. They set a reminder. They commit to being more disciplined.

And then they don’t do it, because discipline is a finite resource and friction is relentless.

The other thing I’ve been thinking about is what makes automation actually work. Because there’s a lot of automation that doesn’t. Scripts that break. Systems that require babysitting. Tools that save time in theory but create new problems in practice.

What I’ve noticed is that good automation has a specific property: you can run it twice without breaking anything.

This sounds like a technical detail, but it’s actually a design philosophy. When you build something that’s safe to repeat, you’re building something that doesn’t require you to track state. You don’t have to remember whether you already ran it. You don’t have to worry about what happens if it gets triggered accidentally. You can just… run it. Whenever. However many times. It figures out what needs to happen and does that, or figures out nothing needs to happen and does nothing.

This is the difference between automation that reduces your cognitive load and automation that just moves it around. If you have to remember whether you’ve already run the script, you haven’t actually automated anything. You’ve just traded one thing to remember for a different thing to remember.

The goal isn’t to have better things to remember. The goal is to have fewer things to remember.

There’s a broader point here about how we design systems generally.

Most systems are designed for the happy path. They assume you’ll do things in the right order, at the right time, with the right inputs. When that happens, they work great. When it doesn’t—when you forget a step, or do things out of order, or run the same thing twice—they break in confusing ways.

This is backwards. Systems should be designed for the realistic path. For humans who forget things. For processes that get interrupted. For the same action happening multiple times because someone wasn’t sure if it worked the first time.

When you design for the realistic path, you end up with systems that are resilient. That recover gracefully from mistakes. That don’t punish you for being human.

And crucially, you end up with systems that people actually use. Because the system that works perfectly when used perfectly but breaks when used normally… doesn’t actually get used. People learn to avoid it. They route around it. They go back to the manual process that’s slower but at least predictable.

I’ve been noticing this pattern in a lot of places lately. The gap between how systems are designed and how they’re actually used.

Documentation that assumes you’re reading it from start to finish when actually you’re searching for one specific thing. Onboarding flows that assume you have uninterrupted time when actually you’re doing this between meetings. Approval processes that assume everyone’s available when actually half the approvers are on vacation.

In each case, the system works fine under ideal conditions. And in each case, ideal conditions almost never exist.

The fix isn’t to demand ideal conditions. The fix is to design for real conditions. To ask: what happens when someone does this wrong? What happens when they do it twice? What happens when they start and then come back three days later?

If the answers to those questions are “it breaks,” you don’t have a robust system. You have a system that only works when everything goes right. Which is another way of saying you have a system that doesn’t really work.

So where does this leave us?

I think the practical takeaway is to get suspicious of steps. Especially the small ones. Especially the ones that feel trivial.

When you notice yourself not doing something you meant to do, don’t assume the problem is motivation or discipline. Ask instead: how many steps does this actually require? How many micro-decisions? How many things do I have to remember in the right order?

And then ask: can any of those steps disappear entirely? Not get faster. Not get easier. Disappear.

Sometimes the answer is no. Some things genuinely require human judgment at multiple points. But often—more often than you’d expect—the answer is yes. The steps exist because someone designed the process without thinking about them, or because the tools weren’t available to eliminate them, or just because that’s how it’s always been done.

The steps that feel inevitable often aren’t. They’re just familiar.

And familiar friction is still friction. It still stops you. It just stops you so gradually that you don’t notice it happening.

That’s what I’ve been thinking about. The weight of small steps. The value of zero. The difference between systems that work and systems that work for humans.

I’ll talk to you tomorrow.