I used to treat structure and control as the same instinct.
Both meant deciding things in advance. A schedule instead of a fresh decision every morning. A plan instead of figuring it out as you go. If it replaced improvisation with something fixed, I filed it under the same idea.
That held until I watched a fairly careful planning process fall apart.
Where it broke
The phase in question looked disciplined from the outside. Detailed sprints. Careful estimation. Plans refined before any work started. For a while it felt like progress, like finally being systematic about something that used to be chaotic.
Then reality moved, the way it always eventually does. A change in requirements meant restructuring the plan, not adjusting it. A discovery mid sprint made the whole framework feel wrong rather than slightly off. I noticed I was spending more time maintaining the plan than doing the thing the plan was supposed to organize.
None of that was a structure problem. The plan had quietly stopped being a set of defaults and started being a prediction. It assumed it knew what the next few weeks would look like, and it kept that assumption right up until the moment it didn’t hold. I wrote about that cycle in more detail in Planning Without Predictability, the overcorrection from no plan at all into a plan that tried to forecast too much.
That’s control. Not a bad instinct, just a mismatched one. It tries to reduce uncertainty by getting the forecast right, and it only works for as long as the forecast holds.
What actually worked
Compare that to a few things that have quietly kept running for a long time.
I prewrite blog posts, not because it’s efficient, but because it means Sunday never turns into a negotiation about whether there’s enough time to publish this week.
Training happens on fixed days instead of getting reinvented each week based on mood or schedule.
Demos count as finished the moment they exist, so a song doesn’t sit around waiting for a verdict on whether the idea is good enough yet.
None of these decide what will happen next week. They just remove one decision that would otherwise have to be made fresh every time. I laid this out at more length in Designing for Future-Me, where the underlying idea was to ask less of future me rather than to make future me sharper.
That’s structure. It doesn’t know what’s coming. It doesn’t need to.
The actual difference
Structure and control both look like discipline from the outside. Rules, defaults, things decided ahead of time. That’s why it’s easy to file them under the same instinct.
But they’re solving different problems. Structure removes a recurring decision. Control tries to remove uncertainty about the future.
Removing a decision costs you almost nothing when circumstances change. The fixed training day either happens or it doesn’t, and either way there’s no plan to unwind. Removing uncertainty, on the other hand, means betting on a specific version of the future. When that version doesn’t show up, the whole apparatus built around it stops making sense, and now there’s a plan to unwind on top of whatever actually needs doing.
Structure stays adaptable because it never tried to predict reality in the first place. Control breaks because it did.
Closing
I don’t think the answer is to avoid planning or avoid rules. Some amount of both is clearly useful, and plenty of good systems are made of nothing but small, fixed decisions.
The question worth asking is narrower. Is this rule removing a decision, or is it quietly betting on how things will go? The first kind tends to survive contact with an ordinary, disrupted week. The second kind tends to need a rewrite the first time reality disagrees with it.
