Someone has been trying to introduce me to a woman we'll call Yuka-chi. It should be simple: pick a date, book a café, invite both of us. Two years later, it still hasn't happened — not because she's a bad planner, but because she keeps planning around a fixed date while the real variable, me, keeps changing. Somewhere between a birthday party that never happened and a UN medical convoy rerouting around a closed corridor in Gaza, I found the same failure pattern: the target isn't standing still.
Part 1 — Planning Works... Until Reality Starts Moving
Imagine someone wants to introduce me to Yuka-chi. Sounds simple. Pick a date. Create an event. Invite both of us. Done. Except — I'm the problem. Not because I dislike Yuka-chi. Not because I dislike the people arranging the meeting. But because I'm simply not interested in meeting anyone right now.
If I'm tired, I'll probably stay home. If I'm annoyed, I'll disappear. If I'm busy, I'll postpone. If I'm enjoying a quiet day with my motorcycle, I probably won't trade it for a social gathering. The organizers don't know which version of me they'll get. Maybe I'll come. Maybe I'll cancel. Maybe I'll vanish without saying much.
The result? After almost two years, they still haven't managed to make the meeting happen. Not because they are bad planners — but because they keep planning around a fixed date while the real variable keeps changing. The target isn't standing still. It's moving.
Most people believe planning fails because the plan wasn't detailed enough. I think the opposite is often true. Planning fails because reality refuses to remain stable long enough for the original plan to survive.
This isn't limited to personal situations. It's exactly the kind of uncertainty humanitarian organizations face every day. Imagine a UN humanitarian team preparing to deliver medical supplies to a hospital in Gaza. The plan is completed today. Tomorrow morning, the security situation changes. A road is suddenly closed. A humanitarian corridor opens somewhere else. The receiving hospital changes its operating status. A local partner loses access to the area.
The objective hasn't changed. People still need medicine. But almost everything else has. Experienced humanitarian teams rarely throw away the mission. Instead, they reassess. Can we still use this road? If not, what alternatives exist? Can another partner reach the community? Should the priority shift until access improves? The destination stays the same. The route changes. Again. And again. And again.
I began noticing the same pattern in many completely different situations. Papua. Museum partnerships. Software development. Volunteer projects. Even something as ordinary as trying to meet Yuka-chi. The mistake wasn't poor planning. The mistake was assuming the environment would remain unchanged long enough for the plan to work. Sometimes it does. Often, it doesn't.
That realization changed one question I constantly ask myself. I stopped asking: "How can I create the perfect plan?" Instead, I started asking: "How can I keep moving even when the environment refuses to follow the plan?" Because eventually I realized something surprisingly simple: some problems are fixed, others keep moving — and treating both the same is where planning begins to fail.
Part 2 — Not Every Problem Wants a Perfect Plan
If I ask someone to build a house, planning is relatively straightforward. The land doesn't move. The house doesn't decide to relocate. Concrete doesn't suddenly become emotional. The blueprint remains valid because the object being planned is mostly predictable.
Most engineering projects work this way. The variables are largely fixed. Of course, delays happen — materials arrive late, weather changes, costs increase — but the objective itself rarely decides to disappear. Planning works because reality remains relatively stable.
Now compare that with trying to meet me. Immediately, everything becomes uncertain. Am I busy? Am I tired? Am I in the mood to socialize? Did I suddenly decide I'd rather spend the weekend riding my motorcycle? Did something happen yesterday that made me want to be alone? None of these variables can be predicted months in advance. Even I sometimes don't know. The organizer isn't planning around a calendar anymore. They're planning around human behavior. And humans move.
This difference seems small. It isn't. It's the difference between planning for objects and planning for living systems.
Living systems change. People change. Politics change. Conflicts change. Weather changes. Security changes. Relationships change. Every decision creates new conditions that didn't exist yesterday. The plan isn't failing because it was poorly written. The environment has already become a different environment.
This is close to what design theorists Horst Rittel and Melvin Webber called a "wicked problem" — a class of problem, common in social policy and planning, that resists a single definitive formulation because every attempt to solve it changes the understanding of the problem itself. Their argument, published in Policy Sciences in 1973, was that classical engineering-style planning (the kind that works beautifully for a bridge) breaks down the moment the "material" you're planning around is a person, an institution, or a social system rather than steel and concrete.1 Trying to schedule me is, in that narrow but very real sense, a wicked problem wearing a birthday-party costume.
Humanitarian operations experience this every day. A UN team may prepare an operation based on today's information. Tomorrow morning, that information is already outdated. A bridge becomes inaccessible. A local authority changes its decision. A partner organization loses access. A community suddenly relocates. Nothing about the original objective has changed. People still need food. People still need medicine. Children still need protection. Yet the route toward those objectives must continuously evolve. The mission remains stable. The environment does not.
This is exactly why I stopped believing that better planning always means more detailed planning. Sometimes more detail simply creates more assumptions. And assumptions are fragile, especially when the environment keeps changing. Instead, I began asking a different question: which parts of this situation are actually stable, and which parts are moving?
That single question changes everything. If the important variables are fixed, invest more time planning. If the important variables keep changing, invest more time observing. Because observation is what keeps a plan alive.
Why Yuka-chi Keeps Losing
She isn't failing because she doesn't know how to organize an event. She's failing because she's trying to schedule certainty inside an uncertain system. And unfortunately for her, I'm one of the moving variables.
Part 3 — Adaptive Planning: Changing the Route Without Changing the Mission
By this point, one question naturally appears. If detailed planning doesn't work in an environment that constantly changes, what does? The answer surprised me. The goal doesn't change. The plan does. That sounds obvious — until you realize how differently most people actually behave.
Suppose someone wants to organize a birthday party for Yuka-chi. Their objective is simple: meet Angga. So they create a plan. Reserve a café. Invite everyone. Set the date. Send reminders. Wait. The day arrives. I'm gone. Maybe I wasn't in the mood. Maybe I was exhausted. Maybe I decided to spend the weekend riding my motorcycle instead.
The organizer concludes, "The plan failed." Not quite. The meeting failed. The objective didn't. Those are two different things. Instead of asking, "How do we make this event happen?" — a better question would be, "Under what conditions is Angga most likely to say yes?" That's no longer event planning. That's adaptive planning.
A Closer Look: The Different Versions of "Ngambek"
I think this is the part most people skip past too quickly, so let me slow down. When I say I'm "the moving variable," what I actually mean is that there isn't one me to plan around — there are several, and I rotate between them without much warning.
Shows up after a heavy week of client calls, museum reports, or debugging something at 1 AM. He doesn't want conversation. He wants silence, a fan, and nobody asking him to "just show up for twenty minutes." Push an event on this version and he'll cancel same-day, guilt-free.
Something irritated him — a missed deadline, a badly worded message, traffic. This version isn't angry at Yuka-chi or the organizers specifically, but he'll interpret any invitation right now as one more demand on his attention, and he'll disappear rather than explain why.
Not sad, not tired, not annoyed — just genuinely happier riding somewhere quiet than sitting in a café making small talk. This version isn't rejecting Yuka-chi at all. He's choosing a competing good, not avoiding a bad one.
Rested, curious, not mid-deadline, replying to messages within the hour, occasionally posting something that shows he's out and about. This version says yes easily — often to something much smaller than a planned event.
Here's the problem with almost every attempt to introduce me: the organizers only ever plan for Available-Angga, because that's the version they want to meet. But they schedule the event two or three weeks in advance, with no way of knowing which version will actually show up on the day. They're not wrong about the goal. They're wrong about treating a probability as a certainty.
Part 3.5 — The Ngambek Problem: When the Moving Variable Is Also Actively Avoiding You
Now I have to be honest about something, because so far I've described myself too kindly. I've been talking as if I merely drift between states like weather — sometimes tired, sometimes riding, sometimes free. That's the polite version.
The less polite version is this: sometimes I ngambek. And ngambek is not the same thing as being busy.
Busy is passive. Ngambek is active. Busy means the road happens to be blocked. Ngambek means I saw you coming and quietly moved the road. When I'm in that state I don't just fail to show up — I manage my own unavailability. I reply later than usual, and shorter. I answer the easy question and skip the one that requires commitment. I go quiet for four days and then reappear as if nothing happened. I don't say no, because saying no would create a conversation, and a conversation is exactly what I'm avoiding.
This matters enormously for planning, because it changes the nature of the variable. A busy person is a slow-moving target. An avoiding person is a fast-moving target that reacts to being aimed at. The moment Yuka-chi increases her effort, I increase my distance. Her signal becomes my trigger. That's no longer just an uncertain environment — that's an environment with feedback.
And here's the uncomfortable part: this is the hardest version of the problem, which is exactly why solving it teaches you the most. If you can plan around someone who is actively, quietly, non-confrontationally avoiding you — without becoming pushy, without becoming resentful, and without giving up on the objective — then almost every other planning problem in your life is easier by comparison. Stakeholders who stop replying to emails. Communities that politely agree in meetings and then don't participate. Donors who say "interesting" and never follow up. Governments that neither approve nor reject. Ngambek is the training ground for all of them.
Look carefully at the left side of that diagram, because it explains two full years in five boxes. Nobody in that loop is behaving badly. The organizer is being generous. I'm not being cruel. And yet the system reliably produces failure, because effort is the input and distance is the output. Every increase in one produces an increase in the other. In systems language, that's a reinforcing loop — it doesn't self-correct, it self-amplifies.
The right side is the whole trick, and it's almost anticlimactic: make "no" free. The reason I ngambek isn't that I don't want to see anyone. It's that a big invitation makes refusal expensive — I'd have to explain, apologize, disappoint someone, possibly negotiate. Silence is cheaper than honesty, so I choose silence. But if the invitation arrives with its own exit built in — "twenty minutes, near your place, and if you're not up for it just say another time, seriously no problem" — then avoidance stops being useful. There's nothing to avoid. I can decline in four words and lose nothing, which paradoxically makes me far more likely to accept.
The Counter-Intuitive Rule
If someone is avoiding you, do not increase the pressure to say yes. Decrease the price of saying no. Avoidance is almost always a symptom of an expensive refusal, not an expensive relationship. Make refusal cheap and the avoidance disappears — along with the need for it.
There's a second thing hidden in the right-hand loop that I want to name explicitly, because it's the part most people get wrong: silence must be treated as data, not as verdict. When I go quiet, the organizer's instinct is to interpret it — "he's annoyed with me," "he doesn't like Yuka-chi," "I've been rejected." All of those are stories. The observable fact is much smaller and much more useful: this week the state is not AVAILABLE. That's it. That's the whole message. It tells you about timing, not about worth. Humanitarian teams do this instinctively — a closed corridor is a fact about today's access, not a moral statement about the mission or the people who planned it.
And if I'm honest, this is also a note to myself. Being the fast-moving variable is not something I'm proud of. It costs other people real effort — two years of it, in this case. The most I can offer in return is transparency: here is the mechanism, here is what actually works on me, and here is why your previous attempts failed even though you did nothing wrong. That's the reason this section exists. If the target can hand you its own operating manual, the least it can do is make the manual accurate.
So What Should Yuka-chi Actually Do? Seven Moves
This is the practical part. If you're planning around anything that moves — a person, a community, a market, a conflict zone — these seven moves generalize surprisingly well. I've paired each one with an analogy that I think is more accurate than the usual "be flexible" advice, because "be flexible" tells you nothing about what to actually do on Monday morning.
An airline publishes a schedule months ahead and forces reality to comply. A bush pilot flying into a remote strip does the opposite: they file an intention, then wait for a weather window, then go. Same destination, radically different commitment structure.
Do this: Don't announce "Saturday 6 PM at the café." Announce a standing intention — "whenever you're free, coffee's on me, 20 minutes, any day" — and then launch when the window opens. The window is the schedule.
Before knocking through a wall, a builder taps it and listens — is it hollow or load-bearing? The tap costs three seconds. Guessing wrong costs the ceiling. Most planners skip the tap because it feels too small to bother with.
Do this: Send one low-cost probe before committing resources. A message. A shared photo. A casual "you around this weekend?" Read the response — the speed and warmth of the reply are the data, not just the words. Then decide whether to commit anything bigger.
A ship's captain doesn't need to ask the ocean how it feels. Barometer, wind, swell, cloud colour — the signals are already there, free, continuously updating. Ignoring them and instead sending a formal request for the ocean's plans would be absurd.
Do this: Is he posting? Replying quickly? Complaining about work? Riding? Quiet for five days? These are your instruments. This is the "Observe" step — and most planners skip straight past it into "Decide," then wonder why their decision was wrong.
A chemical reaction that won't happen at room temperature doesn't need a bigger beaker — it needs a catalyst that lowers the energy barrier. The reactants were always willing. The threshold was the problem.
Do this: A 20-minute coffee has a far higher yes-rate than a twelve-guest birthday party, because it asks almost nothing of Capek-Angga or Kesel-Angga. Big formal invitations are optimized for Available-Angga only — exactly the version you can't schedule in advance. Shrink the ask until three out of four versions could say yes.
Real options thinking: instead of one large irreversible bet, pay a small premium for the right to act later when conditions are clearer. Humanitarian teams do this constantly — pre-positioned stock, multiple pre-cleared routes, standby partners. None of it is the mission. All of it preserves the ability to execute the mission.
Do this: Keep three cheap paths alive rather than one expensive one — a coffee, a group ride, a shared work session at the same café. If one closes, you haven't lost the objective. You've lost one option out of three.
Emergency response teams don't plan "we will distribute water on the 14th." They plan "if the water point drops below X, then trucking begins within 24 hours." The trigger does the scheduling, so nobody has to predict the future correctly.
Do this: Replace "next Saturday" with "the next time he posts a café photo after a ride, I invite him within two hours." Now you don't need a forecast. You need attention — and attention is something you actually control.
A radiologist reading a scan doesn't feel personally insulted by a shadow on the film. The shadow is information about the patient, not a verdict on the radiologist. Emotional entanglement destroys the ability to read data accurately.
Do this: A cancellation from Capek-Angga isn't a judgement on Yuka-chi. Treating every "not today" as rejection creates pressure — and pressure is precisely what pushes Motor-Angga toward the motorcycle instead of the café. The organizers who've kept trying for two years without adapting the method aren't failing because they're unlikeable. They're failing because they keep re-running the same fixed plan against a target that was never fixed to begin with.
None of this guarantees a yes. It can't — that's the nature of a moving target. But it shifts the odds meaningfully in Yuka-chi's favour, and it's a smaller, cheaper, faster way to find out than another elaborately planned event that has to survive three weeks of me changing my mind.
Now Replace Me With a Convoy
Instead of my mood, the variable becomes security conditions. Instead of my motorcycle, the variable becomes a damaged bridge. Instead of me disappearing, a humanitarian corridor suddenly closes.
Nothing about the mission has changed. Children still need food. Hospitals still need medicine. Families still need shelter. But every route toward those goals keeps changing. This is why humanitarian organizations rarely become emotionally attached to a single operational plan. They're attached to the mission. Not the route.
Notice how precisely the seven moves map across. The weather window becomes a security window. Tapping the wall becomes a reconnaissance run or a phone call to a local partner before committing a full convoy. Reading the instruments becomes daily access monitoring. Lowering activation energy becomes splitting one large delivery into several smaller loads that can move whenever a gap opens. Buying options becomes pre-positioned stock and multiple pre-cleared routes. Trigger conditions become contingency thresholds written into the response plan. And separating signal from self-worth becomes the professional discipline of not defending yesterday's plan just because you wrote it.
Even the ngambek problem has an operational twin. Counterparts who neither approve nor refuse; authorities who keep a request "under review" for months; partners who stop answering without ever declining. Experienced teams don't respond by sending more letters. They lower the cost of engagement — a smaller pilot, a shorter commitment, a request that's easy to grant and easy to reverse — because a decision-maker who can say no cheaply is far more likely to eventually say yes.
One lesson I learned from working in development is that experienced teams don't waste much energy defending yesterday's plan. They spend that energy understanding today's reality. If today's conditions no longer support yesterday's assumptions, they update the assumptions. Then they move again. That cycle repeats constantly — not because the original planners were incompetent, but because reality keeps producing new information.
USAID formalized a version of exactly this instinct into what it calls the Collaborating, Learning, and Adapting (CLA) framework: a structured way of embedding continuous learning and course-correction into program design, instead of treating "learning" as something that only happens at the end, in an evaluation report nobody reads until the project is already over.2 The whole premise of CLA is that in unstable or fast-changing environments, a program that only executes its original plan — however well-designed — will drift out of relevance long before it finishes.
Eventually, I realized something interesting. Adaptive planning isn't about becoming flexible because you're indecisive. It's about becoming flexible because reality is. The environment doesn't care how beautiful your PowerPoint presentation was. Reality never promised to follow it.
Looking back, I noticed this pattern everywhere. When I built software, requirements changed. When I worked with stakeholders, priorities changed. When I organized activities, people changed. When humanitarian situations evolved, access changed. When someone tried introducing me to Yuka-chi, apparently, I changed. Quite often. The destination stayed remarkably consistent. The route almost never did. And that's the mistake I see many planners make: they protect the route, when they should be protecting the objective.
The Rule I Eventually Adopted
Never fall in love with the plan. Fall in love with the mission. Plans are disposable. Objectives are not. Once I understood that difference, planning became much less frustrating. I no longer expected my first plan to survive. I expected reality to negotiate with it. And reality almost always won.
Part 4 — The OODA Loop: Why Waiting for Certainty Is Already Too Late
When I first learned about the OODA Loop, I had an odd reaction. I wasn't learning something new. I was discovering the name of something I had already been doing.
The OODA Loop was developed by U.S. Air Force Colonel John Boyd, originally to explain why some fighter pilots consistently out-decided their opponents in aerial combat.3 Its purpose wasn't to create perfect plans. Its purpose was to make better decisions faster than a changing environment. The loop is surprisingly simple: Observe — understand what is happening. Orient — interpret what those observations actually mean. Decide — choose the next action. Act — execute. Then start over. Again. And again. And again.
Notice something interesting. There is no step called "Create the perfect plan." Because the assumption behind OODA is that the environment will change before you're finished planning. Planning is useful. But observing reality is even more important. Military historian Frans Osinga, whose Science, Strategy and War remains the most thorough academic treatment of Boyd's thinking, makes the point that Boyd's real interest wasn't speed for its own sake — it was survival in an "ever changing world," where the side that can re-orient fastest wins, regardless of who had the better initial plan.3
Decision-making under uncertainty — Boyd's OODA Loop. If the player above doesn't load, browse talks on OODA here →
Running the Loop on Yuka-chi
Let's go back to poor Yuka-chi. Imagine she still wants to meet me. A traditional planner might do something like this: birthday party, Saturday, 6 PM, café reservation, everyone invited. Perfect. Except Friday night I suddenly feel exhausted. Saturday morning I'm in a bad mood. By noon I've decided I'd rather disappear for the weekend. The plan was perfect. Reality wasn't.
| OODA Step | Yuka-chi & the coffee invitation | UN team & medical supplies in Gaza |
|---|---|---|
| Observe | What has Angga been doing lately? Avoiding gatherings? Replying to messages? Socially exhausted — is this a Capek-Angga week or an Available-Angga week? | Security situation changed overnight. Road status, corridor openings, hospital operating status, partner access all re-checked this morning. |
| Orient | This probably isn't the right week. Pushing harder may actively reduce the chance of success — and may trigger ngambek. | The western route is no longer safe. The southern corridor is currently viable but may not stay that way. |
| Decide | Don't organize a major event. Wait. Keep observing. Hold the low-cost option in reserve. | Use the southern corridor. Re-sequence which facility receives supplies first based on current status. |
| Act | Weeks later Angga posts a café photo after a ride. Instead of another elaborate event: "I'm nearby. Want to grab a coffee for 20 minutes? No pressure if not." | Deploy. Six hours later, observe again — because reality has already changed again. |
Completely different strategy. Same objective. Notice what changed: not the goal — only the timing, the route, and the decision.
This is why many experienced humanitarian professionals don't become emotionally attached to yesterday's operational plan. They become attached to the humanitarian objective. Everything else is negotiable.
The mistake many planners make is treating planning as a one-time activity. Create the document. Approve it. Execute it. Reality doesn't work that way. Reality is constantly sending updates — every conversation, every weather report, every stakeholder meeting, every conflict, every unexpected phone call. All of them contain new information. The question isn't whether new information will arrive. The question is whether you're willing to let that information change your decision.
This also explains why I naturally prefer micro steps. People sometimes think micro steps exist to reduce workload. That's only part of the story. The real reason is much simpler: every completed micro step gives me new information. That information makes my next decision better than the previous one. Large plans delay learning. Small actions accelerate it. This is essentially the same logic behind the "build–measure–learn" loop that entrepreneur Eric Ries popularized for early-stage products — you ship the smallest thing that produces real feedback, then let that feedback decide what you build next, rather than trying to specify the whole product up front.4
That's why I don't try to predict the entire journey. I only need enough certainty to take the next meaningful step. Then reality teaches me what the following step should be.
Part 5 — The Biggest Planning Mistake: Treating Every Problem the Same
Looking back, I realized my biggest mistake was never poor planning. My biggest mistake was assuming every problem deserved the same planning process. They don't. Some problems reward detailed planning. Others punish it.
Imagine you're building a bridge. The laws of physics don't suddenly change tomorrow morning. Steel behaves like steel. Concrete behaves like concrete. Gravity doesn't wake up and decide to work differently. You can spend months planning because the environment itself is relatively stable. Planning creates confidence.
Now imagine trying to negotiate humanitarian access during an active conflict. Yesterday's agreement may no longer exist today. A road that was open this morning may be inaccessible this afternoon. A trusted local partner may suddenly lose access to an entire community. Nothing is physically broken. Reality simply changed. More planning doesn't remove that uncertainty. Sometimes it only creates the illusion of control.
Then I thought about Yuka-chi again. Poor Yuka-chi. She kept trying to solve a moving problem using a fixed planning process. Birthday party. Gathering. Another gathering. Another schedule. Another invitation. From her perspective, the solution was obvious: create a better event. From my perspective, I wasn't rejecting the event. I was simply becoming a different person every few weeks — sometimes wanting to be alone, sometimes wanting to work, sometimes wanting to disappear for a while. She wasn't planning around a calendar. She was planning around a human being. Those are completely different problems.
This is exactly what the Cynefin Framework, developed by David Snowden and Mary Boone and published in Harvard Business Review in 2007, tries to explain.5 Not every problem belongs in the same world.
Some problems are Simple (or Clear): the answer is already known — follow the procedure. Others are Complicated: experts can analyze them, and engineering projects often fall into this category, where planning, analysis and experience all matter. Then there are Complex problems — and this is where things become interesting. Cause and effect can only be understood after something happens. You don't discover the correct answer by thinking longer. You discover it by interacting with reality — what Snowden and Boone describe as "probe, sense, respond" rather than "sense, analyze, respond."5 Finally, there is Chaos: act first, stabilize the situation, and only then begin making sense of what happened. Organizational psychologist Karl Weick describes this same instinct in his work on sensemaking — under real uncertainty, people often have to act before they can fully understand a situation, because acting is frequently what generates the information needed to understand it in the first place.6
The Cynefin Framework — why "probe, sense, respond" beats analysis in complex domains. If the player doesn't load, browse Dave Snowden's talks here →
Suddenly, many experiences from my career started making sense. Building software? Often complex. Working with communities? Complex. Humanitarian operations? Definitely complex. Trying to predict my own mood two months from now? Apparently, also complex.
This explains why detailed planning sometimes makes me uncomfortable. Not because planning is wrong. Because sometimes it assumes certainty that simply doesn't exist. The longer the plan, the more hidden assumptions it quietly accumulates. And assumptions have an expiration date.
That doesn't mean planning is useless. It means planning should match the nature of the problem. If the environment is stable, plan deeply. If the environment keeps changing, learn quickly. Those are not contradictory ideas. They're complementary. The mistake is applying one to the other.
When I finally understood this, I stopped asking, "How detailed should my plan be?" Instead, I started asking, "What kind of problem am I actually dealing with?" That single question completely changed the way I approach uncertainty. Because once you know the type of problem, the planning method almost chooses itself.
At this point, all the pieces finally came together. Micro steps. Adaptive planning. The ngambek loop. The OODA Loop. The Cynefin Framework. They weren't competing ideas. They were describing the same pattern from different perspectives. The only question left was: how do I turn all of this into a practical operating system I can actually use every day?
Part 6 — My Operating System for Working in an Uncertain World
After years of working across government, development projects, software, education, and humanitarian environments, I eventually realized something. I wasn't collecting productivity techniques. I was building an operating system. Not for computers. For myself.
People often ask, "How do you start projects so quickly?" The answer isn't speed. The answer is that I don't try to solve tomorrow's problems today. I only solve today's problem. Tomorrow deserves tomorrow's information. Over time, my planning process became surprisingly simple — not because the work became easier, but because I stopped pretending the world was predictable. Instead, I ask myself six questions every single time.
Is it stable? Or is it constantly changing? Does it react to my effort? If it's stable, planning deserves more attention. If it keeps changing — or worse, moves away when pushed — observation becomes more valuable than prediction.
Not the activity. Not the meeting. Not the presentation. The mission. Because meetings can be cancelled, routes can change, budgets can disappear. The objective should survive all of them.
Not progress on paper. Not another discussion. Something real. Something observable. Something that teaches me what I didn't know yesterday — and cheap enough that a "no" costs nobody anything.
Probably the question I ask most often. People react. Stakeholders hesitate. Partners respond. Communities adapt. Silence itself is information. Ignoring those signals because they don't match yesterday's plan is choosing comfort over learning.
The mission rarely changes. The route often does. Changing a plan isn't admitting failure. It's admitting that reality knows something I didn't know yesterday.
Not because I'm excited. Not because someone asked. Not because funding suddenly appeared. Scale only after reality proves the previous step actually worked. Evidence first. Expansion second.
Looking back, I realized this philosophy explains almost everything I've written about. Why I work in micro steps. Why I dislike endless meetings. Why I prefer prototypes over presentations. Why I value evidence over assumptions. Why I rarely become emotionally attached to plans. They're all expressions of the same idea.
Ironically, this operating system doesn't make uncertainty disappear. Nothing can. Instead, it makes uncertainty usable. Instead of treating change as an interruption, I treat it as new information. Instead of asking reality to obey my plan, I allow my plan to learn from reality. That small shift changes everything.
And perhaps that's the biggest lesson I have learned. The world doesn't reward the person with the most detailed plan. It rewards the person who notices change first — and adapts before everyone else.
Final Thought
If there's one sentence I hope I'll remember years from now, it's this:
Protect the mission. Challenge the assumptions. Replace the plan whenever reality gives you a better one.
Because in a moving world, the goal is not to make perfect plans. The goal is to keep moving.
And somewhere out there, Yuka-chi is still waiting for a version of me that shows up on schedule. She won't get one — that version doesn't exist. What she can get is something better: a target whose mechanism is now documented. If she stops trying to schedule Available-Angga three weeks in advance and instead makes it costless for me to say no, the ngambek loop loses its fuel. Twenty minutes. Nearby. No pressure. Any day.
If she can solve that — a moving, avoiding, occasionally sulking variable who reacts to being aimed at — then honestly, every other planning problem in her life is going to feel easy by comparison. Hopefully. Semoga.
Key Sources & Further Watching
Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a General Theory of Planning. Policy Sciences, 4(2), 155–169 — the origin of the "wicked problem," and why engineering-style planning breaks down in social systems.
USAID Learning Lab. Collaborating, Learning, and Adapting (CLA) Framework. United States Agency for International Development; see also OECD (2021), Development Co-operation: Tips, Tools and Insights. Link
Osinga, F. P. B. (2007). Science, Strategy and War: The Strategic Theory of John Boyd. Routledge. (Boyd's OODA Loop developed from the 1950s–1970s, formalized in "The Essence of Winning and Losing," 1995.)
Ries, E. (2011). The Lean Startup. Crown Business — the build–measure–learn loop, and why the smallest thing that produces feedback beats the most complete plan.
Snowden, D. J., & Boone, M. E. (2007). A Leader's Framework for Decision Making. Harvard Business Review, 85(11), 68–76 — the Cynefin Framework. Link
Weick, K. E. (1995). Sensemaking in Organizations. Sage Publications — why people often must act before they can fully understand a situation.
McGrath, R. G., & MacMillan, I. C. (1995). Discovery-Driven Planning. Harvard Business Review — planning as a sequence of assumption tests and real options rather than one fixed forecast. Underpins move #5 ("buy options").
Senge, P. M. (1990). The Fifth Discipline. Doubleday — reinforcing vs. balancing feedback loops, the systems language used in Diagram 4 to explain why pushing harder on an avoiding target increases distance.
John Boyd & the OODA Loop — decision-making under uncertainty. Search on YouTube
Dave Snowden — The Cynefin Framework explained. Search on YouTube
Background soundtrack: "Magic" — HorizonScanning repository