The Productivity Dodge: Why Your Best Habits Feel Like Work but Produce Nothing

I once lost five days to a phone I didn’t own yet.

It’s the week before a big exam, and my textbook sits closed on my desk. I’m three hours deep into unboxing videos for a device that hasn’t even shipped, because somewhere in my head I’ve decided this phone is going to make me productive. So I don’t study.

I read about it, watch videos about it, refresh the shipping page. There’s a fair amount of League of Legends in there too, and more than a few movies. The most unproductive things I could have done, I’ve done. Something like 48 hours of it across five days.

If you’d stopped me and asked how any of this was going to help me pass, I couldn’t have told you.

I just knew that once I had the right tool, I’d finally be ready to do the work.

That’s the Productivity Dodge. It’s the move where you tune the system before you do the work that would tell you what to tune. And it feels like work. That’s the dodge.

Researching the phone felt productive. Building the perfect note-taking setup feels productive. Picking the right app, the right template, the right morning routine. All of it feels like progress, and at the end of it you’ve produced nothing.

Engineers have a name for it. In 1974, Donald Knuth called premature optimization “the root of all evil.” He was talking about code, about tuning parts of a program before you know which parts matter.

Most of us just do it with everything else instead of code. And the reason it’s a dodge and not just a mistake is this: the only thing that can tell you what your system should be is the very work you’re avoiding.

The system is downstream of the work. You can’t reason your way to it in the abstract. You have to produce some bad work first and let the work teach you.

So let’s walk this dodge up three flights of stairs: the personal system, the work system, and the organizational system. It’s the same at every floor.

The phone story is extreme, but the pattern is ordinary once you see it. You wait for the tool. You wait for the template. You wait to “level up” before you start, and leveling-up quietly becomes the thing you do instead of starting.

The answer isn’t a better tool. It’s reps. You pick a simple process, you run with it, and you let it teach you where it’s wrong.

The whole point of keeping the system simple is that it frees you from carrying so much in your head, so you can just focus on doing. The system gets refined through iteration, not through planning.

You don’t get fit by buying the membership. You get fit by showing up and doing the work. Fitness is the byproduct.

One caveat, so this isn’t “just grind mindlessly”: reps are not the same as mastery. Six years of repetition made me a fast technician, not an expert.

Repetition makes you fluent; it doesn’t make you an expert.

But you still can’t skip it: there’s no mastery that doesn’t pass through the reps first.

And here’s where perfectionism comes in, because for a long time I couldn’t do any of this. I had an abnormal perfectionism. I wouldn’t turn in work that was merely “good enough.”

It took a quantum physics professor, the first time I ran into something genuinely over my head, to say it plainly: understand what you can, and don’t let the perfect be the enemy of the good. The work doesn’t have to be perfect to be worth turning in.

In fact it can’t become good until you’ve turned in a lot of work that wasn’t.

If the personal version of the dodge is waiting for the tool, the work version is subtler and more seductive, because it’s masked as discipline.

The principle: The fastest way from A to B is a straight line. And the fastest route to a solution is usually the method you already know well, even if that method is objectively slower, rather than a faster-looking method you haven’t proven yet.

Engineers call this the explore/exploit tradeoff. Every shiny new system is “explore.” Your current known-good method is “exploit.” The mistake is to stop exploiting the thing that works so you can go explore full-time.

There’s a hidden cost to every new system, too.

Every new system charges a tuition before you can adopt it.

You don’t flip to the new tool for free. The tuition is the time to learn it, the things that break while you learn it, the output you didn’t produce while you set it up.

A system fits you when you adapt it to your work, not when you adopt it wholesale. The cost of that adaptation is what makes it last.

So what do you do?

You don’t stop using the method that works while you test the new one. You run them in parallel.

You keep producing with the known-good method, you test the new one on the side, and you let the actual results tell you whether the new one nets you anything. You do the test because you cannot know which method wins without the work. One size never fits, one method doesn’t hit, one route won’t suit all, and only the work can tell you which one is yours.

Take a concrete case from my work. We image computers with a tool called KACE SDA: it wipes a machine, loads the operating system, installs the scripted software, and joins it to the domain so it’s ready for a classroom.

That much was already automated, and it was my reliable straight line from A to B. Plenty still wasn’t automated, though. The base image was almost a year old, so every machine I built then sat through hours of updates, and the software KACE didn’t yet handle went on by hand. Slow and half manual, but it worked.

KACE could be pushed much further toward fully automated, and I didn’t stop imaging to go build that out. Imaging has dead time built in, long stretches where the machine churns and I don’t.

So I kept running the known process, and in that dead time, in parallel, I rebuilt the year-old image and reworked the scripts one piece at a time.

Rebuilding the image alone took those multi-hour updates down to about thirty minutes, and a focused day went from roughly ten machines to nearly forty. A to B became A to B to C: B still partly manual, C mostly automated.

The only reason I knew which pieces were worth automating is that I’d already done them by hand.

The third floor is where the dodge gets resolved because you can watch it done right.

At my district, projector support is reactive. A teacher’s projector goes down, the teacher reports it, we react.

We have no overview of how the projectors are behaving: their age, their bulb hours, how often they’re overheating.

We find out something’s wrong only once it’s already wrong.

And a down projector isn’t minor; it’s a classroom resource 20-plus kids depend on, the tool a teacher uses to run the room and teach. When it dies, the teacher has to improvise on the spot.

So over about three months I built a proof of concept, on the side and a little at a time, that shows at a glance which projectors across our 18 sites need attention.

The important part: it is not perfect.

There’s no alerting. There’s no “do this now” guidance. It’s still manual. If I’d waited to build the perfect version, with alerting and automation and runbooks, I’d have had to build it day in and day out, a huge engineering load while the district still needs me to do the support.

Continuous maintenance like that needs sustained engineering access, a retainer or an in-house maintainer, or the system silently degrades. So I didn’t wait.

I built the imperfect version on the side, and as awareness grows, the system grows with it.

It’s systemically imperfect, and it carries a real portion of the load anyway.

The win: a step up from no awareness to now aware.

I didn’t procrastinate the real support in order to perfect a tool that was already handing me information I’d never had before.

The projectors aren’t the only problem; the processes still have to be followed. But the system earns its keep precisely because I let the work define it, instead of the other way around.

Share

The phone arrived before the exam. I failed it anyway.

Over the two or three nights before it, I crammed in long stretches, the kind of heroics you only need when you’ve spent the previous five days waiting to feel ready.

The exam was never waiting on a phone. It was waiting on me to open the book, the notes, and the practice problem sets.

The phone-week version of me needed to hear one sentence:

The perfect system isn’t a prerequisite for the work. It’s a byproduct of it.

You don’t build the system and then start producing. You produce, badly, at first, and the work shows you what the system should be.

So do the work first. Let it build the system.

Your dodge will always feel like progress, that’s why it’s a dodge. What you produce is the only thing that isn’t lying to you.