Not long ago, I was designing a system to help me publish consistently. There was a strategy. Then came product requirements, information architecture, technical architecture, possible integrations, workflows, approval boundaries, and plans for a future control panel that would eventually help me manage the whole thing.

If that sentence made your eyes glaze over a little, I understand. The folder was impressive.

There was just one increasingly awkward problem.

I had not yet established the publishing rhythm the system was being designed to support. The system was becoming more sophisticated while much of the work it existed to support was still theoretical.

None of that work was pointless. I will eventually need some version of those systems, and much of what we developed will probably make the future system better. We uncovered real requirements, risks, questions, and possibilities.

I wasn't wasting time. I was working.

That was what made the problem so easy to miss.

I eventually reached a point where the sequence no longer made sense. I was getting farther into designing how the work would operate before I had spent enough time actually operating it. We could keep deciding what the future software should track, automate, display, and remember, or I could start publishing manually and find out which of those things mattered by doing it.

So I stopped the architecture work.

I didn't throw it away or decide systems were unnecessary. I stopped extending a system built around assumptions and went back to the work it was supposed to support: create the content, publish it, pay attention, and see what happens.

That decision led to the publishing process I am using now. The first article is published. The next one is the one you are reading. Along the way, I have already run into things I would not have designed correctly from a conference room full of diagrams, even if the conference room happened to be my desk.

I needed more production runway than expected. The publishing platform has quirks I couldn't have predicted. Some parts of the article-development process clearly deserve more structure. Others get cumbersome when I try to structure them too early.

Doing the work has been answering questions that planning couldn't.

And this isn't exactly a new pattern for me. I have a remarkable ability to work very hard near the thing that matters.

There is almost always something useful I can do around the central work. I can research it, organize it, improve the tools, refine the plan, or build a better system for managing it. None of those are fake tasks. Sometimes they really do need to be done.

That is why this kind of avoidance can be so convincing.

The research really might help. The folder really is a mess. The system really could be improved.

The question is whether any of that is what needs my attention now.

I could have spent several more months designing a beautiful publishing system without publishing much of anything. At the end of those months, I would have had plenty of legitimate work to point to, while the thing I said mattered was still sitting there waiting for me.

That has made me much less impressed by productivity for its own sake. Finishing a task tells me I finished a task. It doesn't tell me whether I moved anything important forward.

I can answer emails all morning and have an empty page at noon. I can spend an afternoon improving the tool I use to organize a project and never touch the project itself. I can keep researching a decision after I already have enough information to make the next responsible choice. I can refine a system that hasn't encountered enough reality yet to deserve much refinement.

The activity itself isn't necessarily the problem. It may just be happening at the wrong time.

So instead of asking whether something is productive, I have started paying more attention to what that productivity is serving.

Sometimes I genuinely do need more information before I can act responsibly. Sometimes the disorder is getting in the way and I need to clean it up. Sometimes the tool really is creating enough friction to justify replacing it. Sometimes a repeated problem has finally earned a system.

Then there are the times when I am preparing the runway for an airplane I keep refusing to fly.

I can always make the runway a little longer. There is another book to read, another process to improve, another question to answer, another condition I can satisfy before placing myself in direct contact with the thing that matters.

Preparation can keep me close enough to the work to feel productive without getting close enough for the work to answer back.

And real work does answer back.

Publishing does. Starting the business does. Making the call, having the conversation, submitting the proposal, beginning the project, doing the first workout. Once I act, reality gets involved. It may confirm what I expected, surprise me, expose a weakness, or show me that the plan was wrong.

A system on paper is much more cooperative.

My content operating system looked orderly while it existed mostly in documents. The moment I began using the simplest version of it, reality started rearranging the furniture.

That didn't make the planning useless. It finally gave the planning something real to respond to.

By doing more of the process manually now, I am probably collecting the information that will make the future system much better. I am seeing what I repeatedly need and what I forget. I am finding the places where I slow down, the decisions that actually require me, the steps that consistently improve the work, and the ones that looked important in theory but add very little.

I am also finding the repetitive parts that may eventually deserve automation.

I could have guessed at all of that.

Now I have evidence.

Preparation still has a place. The difference I am paying attention to is whether it helps me enter the work or keeps giving me another reason to stay outside it.

The same activity can even change roles. Research may be necessary at one point and avoidance later. A system that would have been premature six months ago may become necessary after the same problem has shown up week after week.

There isn't much value in trying to sort every activity into two permanent piles labeled productive and procrastination. What matters more is the purpose, the circumstances, what I already know, and what the work requires next.

So when I notice that I am extremely busy but the work I care about hasn't moved very far, I ask:

What is the thing that actually matters here?

Then I look at everything I have been doing around it. Is this helping me engage it? Is it preparing me for something that genuinely has to happen first? Or have I built an impressive collection of useful tasks that lets me stay safely beside the work?

I don't always enjoy the answer, but I am getting better at recognizing it.

And when I do, the next step is usually much simpler than everything I built around it.

Do the thing that matters.