Fog of War as a mental model

I like using “fog of war” as a mental model. You might have seen it in strategy games when a part of the territory is hidden until you actually visit it. The map exists, the terrain is already there but you can’t see it until you send a unit in. The original term comes from military strategy where it describes the uncertainty commanders experience on the battlefield. About enemy position, their own capabilities, the full picture of what is actually happening and etc.

What I find useful about this model is that it applies equally well to a lot of things that aren’t war.

When you join a new codebase, you’re dropped onto a map with most of it fogged out. You can see the file you’re editing. Maybe the ones right next to it. But the full shape of the system, the assumptions, historical decisions, the parts that are truly fragile, those only reveal themselves as you move through. The same thing happens when you start a new job, learn a new domain or try to solve a problem you’ve never touched before. You don’t get the full picture upfront. You get it incrementally by going step by step.

And there’s something important there. The fog doesn’t mean the territory is missing. It just means you haven’t been there yet. It’s already shaped. It’s already real. Your movement is what reveals it.

In strategy games good players don’t wait for the fog to lift on its own. They send units out specifically to gather information, not to win territory yet, just to see. The decision to scout is itself a strategic move because information costs something (time, resources, attention). This maps cleanly to technical work. Writing a small proof of concept is scouting. Reading through an unfamiliar module without trying to change it is scouting. Asking a dumb question in a meeting is scouting. You’re not trying to ship yet. You’re trying to reduce uncertainty before you commit.

Here’s also the part I find most interesting. In some games there’s a subtle difference between territory you’ve never seen and territory you’ve seen but are no longer watching. In Age of Empires, if I remember correctly, if you scout a building and then leave that area, you still see the building but frozen at the last moment you were there. You might come back and find it’s been destroyed. The map held a version of reality that was already outdated.

We do this with knowledge all the time. We form a mental model of a system, a team, a codebase, a person and then we stop actively looking. The fog re-closes but we don’t notice because our old picture is still rendered. We’re navigating with a map that describes how things were. The territory changes; the map does not update itself (there’s also a psychological phenomenon for this process but I won’t pretend I knew it without searching on the Web).

I think this is one of the quieter sources of mistakes in engineering. Stale certainty.

The frustrating and kind of beautiful thing about fog of war is that you can’t fully resolve it before you act. At some point you have to move. You commit to a direction based on what you can see, knowing that the act of moving will reveal more and that some of what it reveals will require you to adjust.

That’s just the shape of navigating incomplete information, which is most of the time, in most work that matters. What the model gives me isn’t a way to remove the fog but a way to think clearly in spite of it, to know what I’ve scouted and what haven’t, be honest about which parts of the map are stale and make deliberate decisions about where to send the attention next.

And, hopefully, don’t mistake the edge of my visibility for the edge of what actually exists.