Happy New Year!
I'm Jesse Alford, and you're reading Nonlinear Garden. Last issue, I described Problem Zero - "what should I be working on right now?" Problem Zero feels to me like my most important idea. I've been using it conversationally for years. One of the surprising things about Problem Zero is how hard it is to keep solved, and how difficult it is to get anywhere without a the ability to produce stable solutions.
In this issue, we're going to get into some more detail about my personal first-recourse approach to stabilizing solutions to Problem Zero - slicing.
At Pivotal, we often talked about this in terms of "story slicing." Pivotal Tracker called its basic planning objects "Stories" after the XP concept of "User Stories." But sometimes we'd slice within stories, into "tasks." And then we'd slice within tasks, into tests, into commits, all the way down to the steps of "red, green refactor," a sort of set of standard grooves to fit programming slices to. I've talked about how fractility feels like evidence of truth/value to me before; take this as another case.
It's not just planning or prioritization or testing or programming that this slicing process applies to. It's anything requiring sustained effort. My favorite Book About Programming That Is Not About Programming is Several Short Sentences About Writing by Verlyn Klinkenborg. From the title alone you can infer the basic shape of the wisdom imparted. But let me belabor this for a moment for you.
Why short sentences?
They'll sound strange for a while until you can hear
what they're capable of.
But they carry you back to a prose you can control,
To a stage in your education when your diction—–your vocabulary——was under control too.
Short sentences make it easier to examine the properties of the sentence.
They help eliminate transitions.
They make ambiguity less likely and easier to detect.
Short Solutions Carry You Back To A Plan You Can Control
For all these reasons and more, modulating the size of steps - generally down - allows for more stable solutions to Problem Zero. Problem Zero becomes unsolved so easily. It becomes unsolved when you realize you don't actually know why you're doing what you're doing. It goes out when you reach an ambiguity or stumble, and, in momentarily expanding your mental scope in order to reorient, notice something, anything else.
Problem Zero becomes an open question when some part of you notices that you aren't satisfied, and starts volunteering and soliciting other parts to volunteer things that might satisfy you.
A stable solution to Problem Zero either doesn't hit many of these interruptions, offers fast/instant recovery, or both.
Solutions to Problem Zero that aren't stable, aren't efficient, and at some point, fully don't work. Smaller answers to "what should I be working on right now" are answers that are easier to control. Easier to chose to move into. Easier to recognize as complete. Easier to chose to move out of.
You will do different things, when you slice thin. A spaciousness opens up; some trade-offs begin to feel easier to balance. It is easier to tidy, to keep things clean, to notice and resolve problems as you go, when you are accomplishing your intended work at a tempo that lets you pause often, victorious, and shift intentions to things you have noticed as you worked.
You can fear interruptions less, because they're more often able to wait until you're done, and because smaller work is easier to resume your place in. You can fear commitment less, because you're more likely to be able to live up to it. You can fear the unknown less, because your decision is less exposed to it.
The trick keeps working as your setting's chaos becomes formidable, and as your resources run low. At some point you are writing down tasks like "read one email," checking it off, and deciding what to write down next. Can that be too thin? Yes, of course. But it can also be just what's needed. You gather experience with determining how thin you need to go, before the overhead outweighs the benefit.
This is very much like what we do in Test Driven Development. I don't want to go to deep on that just now, but I have read accounts from senior, experienced TDD'ers about programming when loved ones are in the hospital, or under insane deadline pressure without sleep - non-ideal conditions anyone would try to avoid. They reported becoming more detailed and "disciplined" about writing a test for every change before the change itself, because TDD provided for them the tiny, clear cognitive steps they were up to, despite it all. (If anyone knows of stories like I describe, email me!)
Slice smaller, finish, reorient. Feed your intention with victory. Let the parts of you that are afraid you will never progress see that it is not true.
And No Smaller
All of this assumes you need to go smaller, because, you probably do. I can imagine counterexamples, and if you have a real example, email me.
As you go smaller, planning overhead does increase. You can jump straight to absurdity, and end in a bad place - but what if you take a step smaller at a time? Certainly at least one step seems plausible? And then, another?
How do you evaluate if it's an improvement? We've already argued the virtue of shorter duration, thinner slices, smaller scope, whatever you want to call it. So let's just let "smaller" be "better" as long as it doesn't cross the line into absurdity and waste.
I want you to be careful that you don't draw that line so arbitrarily close to what you are doing now that you start to think that you don't need to slice thinner after all. It's possible, but, everyone must think that, right?
Here's some good heuristics:
- if writing down the intention takes as long as doing the thing, you could have just done it. This may be too thin, unless the record of what you did is itself worth it, which, it often is. If writing it down takes significantly longer than doing it, you have likely gone too far. I must stress that even here there are exceptions, as learning to slice also takes time, and that is time well spent, which you should take care not to count against this threshold.
- if doing the thing you have described has no benefit, or is worse than doing nothing when separated from its other steps, you might have a bad slice. It might be bad because it's too thin. It might be bad because it's awkwardly shaped, and that may in turn be because of a contorted workflow. It is worth noting that steps, clearly held together inside a container, may fail this and still be a good slice, because of the surrounding container. "Bake a cake" may contain "add the baking soda" and "beat until smooth." These may be two steps, even though it would be bad if you added the baking soda to a wet batter and walked off for half an hour. Note how most recipes will slice this; baking soda is generally added to a dry mix, so its chemical activation does not immediately intensify time as a factor.
When do you know you have gone small enough? One simple test out of many: When you have thought of three ways to slice thinner, and all are worse than your current slice. If you practice with this test for a while, you will come to usually know how you could have gone thinner, and why you didn't. As that experience accumulates, explicit tests become less important.
Be clear with yourself what you are doing. Do not confuse steps identified for consistency or for repeatability, with slices for gaining control over the cadence of your own attention.
There are many good reasons to write things down. Know which problem you are writing things down to solve. Choose your approach and sizing based on your understanding of the problem, not on what you imagine of your grasp of the solution.