I met with some fellow business owners recently, and the topic of procrastination came up. It was a quick conversation, so we didn’t get a chance to discuss it fully. My only contribution was to say “I don’t believe in procrastination”.
I misspoke. In fact, I do believe in procrastination.
Procrastination is simply when we intend to work on a project, and find that we can’t get ourselves to work on it.
That phenomenon clearly exists, and I’ve experienced it first hand many times.
What I don’t believe in is laziness. Or, more accurately, I don’t believe laziness is the primary cause of procrastination.
OK, so if laziness isn’t the primary cause of procrastination, what is?
My current thinking is that procrastination most often arises from one of two sources: 1) a legitimate need to take a break from the project, or 2) confusion.
Let me dispense with the first reason quickly for now. Whenever you catch yourself procrastinating ask yourself if you need a break. Sometimes you do. And when you ask the question, you’ll probably know if this is one of those times. If so, take a break.
With that said, I don’t think most procrastination arises from a need for a break. I think most of the time, when we find ourselves procrastinating, it’s because we’re confused — and we probably don’t even know it.
More than that, I think procrastination might actually be an adaptive response in the brain, forcing us to slow down and sort things out. Unfortunately, the “sort things out” part doesn’t always automatically follow, and we can sometimes just get paralyzed instead.
In this article I want to discuss how confusion can lead to procrastination, and how you can use this insight to overcome procrastination in the future.
The Fractal Nature of Your Projects
Brian Arthur has written a masterful book, “The Nature of Technology”. In it he discusses how technology has a fractal structure, and I think that’s something of a key to understanding procrastination.
Now, if you’re building a spaceship, or writing a computer program it might be easy for you to think of your project as one of developing a new technology.
But even if you’re writing an essay or a blog post, the way you go about completing your project shares some very important features with the way engineers go about creating more stereotypical technologies.
So, humor me for now, and tell yourself that all your creative projects involve creating a new technology.
Say it with me:
“I am creating a new technology”.
Now, in his book Arthur makes many observations about the nature of technology (a good thing given the title of his book).
Here is an important insight about technologies:
Insight #1. technologies are built from sub-technologies.
When we create a new technology, we have in mind to build something that will perform a function. Then we build something that will perform the desired function by putting a bunch of parts together. These parts are themselves technologies, or, in this context “sub-technologies”.
And each of those sub-technologies is built out of other parts — sub-sub-technologies.
And so on, often many levels deep.
If you’re writing a blog post, you want the overall post to perform a function.
If you’re like me, in order to create the blog post, you plan it out in big chunks first: (First I’ll discuss A, then I’ll discuss B, and that will allow me to discuss the relationship between A and B. And so on.)
Even if you write more free-form, you are probably being guided by a rough structure of parts relating to parts in your head.
Now, combine that insight with the next insight, and the picture starts to take shape:
Insight #2. it takes effort to combine sub-technologies into a technology.
You know how it goes. You sit down to plan out a new project, and your initial plan sounds quite easy and smooth. But then, when you start implementing it, you realize it doesn’t actually go as easily as you thought it would.
Imagine you’re a caveman, and you get the idea of combining a stick and a strip of bark with a stone to create a bludgeoning instrument. That’s only three basic pieces, and it might easily take a whole day of fiddling to get it to work the first time.
The projects we tend to work on these days have many many more parts and levels. And that can make it even more difficult to make all the parts fit together well.
For instance, imagine you’re writing an essay defending a certain tax policy, and the argument seems like a slam dunk. You think, “my policy of combining A, B, and C is superior because of X, Y, and Z.” But as you start to write about A and B, you see that parts of A are actually in practical conflict with parts of B. And, the thing is, you would never have seen this conflict without actually sitting down and describing A and B in detail.
Developing a website works like this, too. “We’ll just merge Affiliate Software W with Shopping Cart X with Payment Gateway Y with Content Management Software Z, and throw in some custom features in PHP. And it will all fit together like perfect little modules that play nice together.” Yeah, right!
The problem is that your sub-technologies interact with each other in ways you don’t foresee. And sometimes a sub-sub-sub-technology is interacting with a sub-sub-sub-sub-technology in a way you didn’t foresee, and that’s what prevents the whole thing from working well.
The big-chunk solutions always sound easy. Guess what. It NEVER works that smoothly in practice. At least practically never. You know there will be conflicts, but you don’t know what they will be. We can call this the “Law of Unforeseen Complications.”
It doesn’t matter whether you’re writing an essay, developing software, building a spaceship, or moving across town. Unforeseen complications (almost) ALWAYS crop up.
And the time needed to resolve these conflicts will range all over the map. Sometimes a resolution will actually turn out to be impossible, and you will need to re-think the whole project. Other times it will just take a quick little work-around. And most resolutions will be somewhere in-between.
And, . . . get this,. . . in order to make two sub-technologies work well together, we sometimes have to create another new technology to make it happen.
Perhaps all this complication would be less surprising if we changed our metaphor from one of “building blocks” to one of “building trees”. Creating a new technology out of building blocks sounds simple. The blocks are misleadingly easy to fit together in our minds. If we more accurately thought of ourselves building a new technology out of wildly branching tree-like sub-structures, we might appreciate more what we’re actually trying to do.
SIDEBAR: in software development and other fields the problems inherent in merging two many-tentacled sub-technologies together are well known. And measures are taken to make the sub-technologies work together more easily. The major tool for doing this involves making the sub-technologies as “modular” as possible. Increased modularity works spectacularly well when well-designed. And designing for modularity is one reason we are even remotely able to have a society as complex as we have today. However, designing for modularity comes with its own costs. For this reason and others, not every sub-technology is modular with respect to every other sub-technology you might want to combine it with. And even things that are designed to be modular don’t turn out to be as completely modular as intended, and unforeseen complications still crop up.
Now, as if that weren’t bad enough, consider this:
Insight #3. most technologies ARE themselves sub-technologies.
A new website is a technology. But so is your business. If you’re building a website, not only do you have to think about how its parts fit together to form the website, you also have to consider how the website itself fits together with the other technologies inside your business.
Because your website is itself a sub-technology many questions can arise as you’re working on it: Does this new website play nice with the other technologies you’re using in your business? Does the function of the new website align with the overall function of your business? Should you work on the website now, or should you work on something else first? And so on.
So, any project you work on has a tree-like structure, and is itself part of a larger tree. So you’re always working at some node in the middle of a tree. And any other node, anywhere else in the tree, can potentially interact negatively with the part of the project you’re working on now.
This is the main reason large projects can be a big headache, and it’s also why good project managers are easily worth every penny they earn.
Now, back to procrastination . . .
Here’s how a typical case of procrastination used to happen for me.
I’d be working on a project. It was planned in enough detail to start working on it (or so I thought). I’d work on it for a bit, and then I’d suddenly lose all motivation for working on the project. At that point I would suddenly find myself cleaning my office, checking email, or playing a game (or three) of minesweeper.
Now why did this happen? It doesn’t seem to make sense. I wanted to finish the project. Completing the project would typically have potentially huge ramifications for my future well-being. It was way more important to me than trying to win a game of minesweeper.
So why did I do it? Why did I procrastinate?
It seems so counterproductive.
And given that, on the face of it, procrastination seems like the kind of trait that might be selected against in terms of evolutionary fitness, another question comes to mind:
Does procrastination actually provide some hidden unexpected value to us?
Well, consider this. What if we are cruising along developing a project that’s actually going in a completely wrong direction relative to the rest of our business. It would be nice to have part of our brain detect this and slow us down, right?
Or what if our current plans have a fatal flaw that means any further work is likely to be wasted effort, because the thing isn’t going to function properly when we’re done. It would be nice to have part of our brain detect this and slow us down, right?
Could it be that this is what procrastination is mostly all about?
I’ve come to think so, and I have learned to trust my brain whenever I find myself procrastinating.
Let me explain.
“They” say something like 98% of our mental processing is subconscious. I don’t know how “they” would measure this, but I find the main idea quite plausible, and perhaps even grossly understated. Our conscious reasoning is just the tip of the computational iceberg. Given this, it seems likely our brains are frequently working on our projects in ways we are not conscious of — working through the tree-like structure that forms the technology we call “our life”.
And it makes sense to think that it will often detect points of conflict among parts of our new plan, or between a part of our plan and other features of our business or life — conflicts that we didn’t anticipate consciously the last time we did our planning.
And sometimes it uncovers points of “possible” conflict as well — blind spots in our plan where danger may or may not lurk.
In short, it could be that our subconscious processing is actually very good at detecting conflict hidden in our plans.
Unfortunately, it also seems that our subconscious isn’t very good at communicating. It serves up no detailed analysis clearly locating the conflict. It doesn’t even offer a vague suggestion that we should slow down because a possible conflict lurks.
No, instead we just get that uneasy feeling that makes us not want to work on the project.
So How Do We Overcome Procrastination?
My subconscious may not be very good at initiating communication, But I’ve learned that I can get stuff out of it by asking questions.
Whenever I find myself procrastinating, I’ve learned to ask two questions. These two questions start from the part of the project I’m working on now, and focus my mind up the tree and down the tree. Here are the questions:
1. Do I need to plan the parts of this project out in more detail?
2. What compelling bigger outcome is this project serving?
The first question tells me to search for conflicts among the sub-technologies — below the level my current planning has taken me to.
And the second tells me to search for conflicts between my project and the super-technologies my project is a part of.
And, you know what? Whenever I ask these questions, and work out my answers, it almost always turns out that there was a problem lurking somewhere in my plans.
And once I get clarity in both ways, about whether my project is serving higher purposes, and about whether and how the project can be completed, I discover something else.
I find my procrastination almost always goes away — maybe after a short break
Try it for yourself.
Anytime you find yourself procrastinating, try asking yourself those two questions, and work to get clarity on them.
Then see what happens.
P.S. Please let me know what you think of this post. Questions, comments? I’m very interested in this topic and will gladly engage on it.