"If what you are mapping is incoherent, don’t fall in love with the map"
John, this feels like a very important reminder for those who pride themselves in playing leadership roles when it comes to mapping and building coherence. It connects well to your point later in this essay around not seeking perfect coherence, at the risk of reinforcing a map that can not change.
I have been thinking a lot about AI context management these days, and came to a similar conclusion recently. More coherent organizations tend to have less explicit, legible context - because they don't need it. This can be in stark contrast to less coherent orgs that may be swimming in strategy, decision, alignment, operational, etc. artifacts that are borne out of necessity. In some sense, both types of orgs have "blind spots" when it comes to how they might equip their AI systems with context.
Good distinction. I'd push it further . . less-coherent orgs aren't just artifact-heavy, they're artifact-heavy in ways that don't cross team lines either. E.g., everyone's documenting their own neighborhood, not the seams between them. That's where the real friction/cost shows up.
In "Domain Driven Design - tackling complexity at the heart of software" - my personal bible of software development - a very similar relationship is highlighted: If the underlying model really matches the problem-domain and the software is built around this model, things suddenly start feeling simple. If this is not so many people don't directly notice this mismatch but start fighting all this complexity. Same with organisations. If the maps align and the organisational design is good, focussing on missions, objectives and features feels natural, occasional dependencies play a secondary role and can be handled by the teams directly. In this sense complexity is tackled at the heart of the organisation. If not: The org needs to deal with dependencies, cross unit alignment calls, bridging roles, theme/topic owners, expeditors etc. Complexity is here to stay.
Yes, managers should grow simplicity. Yes, the maps need to evolve rather than extra navigators assigned.
Thank you John Cutler for one more beautiful metaphor!
Thanks for this. Your "appearance of alignment" point has a concrete mechanism showing up in process documentation right now: a paper SOP staled visibly, so people learned when to stop trusting it and go find whoever actually knew the current state, but a continuously-regenerated AI SOP never looks old enough to doubt. HBR ran an editorial on exactly this in June — polished AI-generated SOPs can mask accuracy degradation and organizational knowledge decay. The artifact meant to manage the incoherence ends up hiding it instead, because the cue that used to send people to the fixer has disappeared.
"If what you are mapping is incoherent, don’t fall in love with the map"
John, this feels like a very important reminder for those who pride themselves in playing leadership roles when it comes to mapping and building coherence. It connects well to your point later in this essay around not seeking perfect coherence, at the risk of reinforcing a map that can not change.
I have been thinking a lot about AI context management these days, and came to a similar conclusion recently. More coherent organizations tend to have less explicit, legible context - because they don't need it. This can be in stark contrast to less coherent orgs that may be swimming in strategy, decision, alignment, operational, etc. artifacts that are borne out of necessity. In some sense, both types of orgs have "blind spots" when it comes to how they might equip their AI systems with context.
Good distinction. I'd push it further . . less-coherent orgs aren't just artifact-heavy, they're artifact-heavy in ways that don't cross team lines either. E.g., everyone's documenting their own neighborhood, not the seams between them. That's where the real friction/cost shows up.
Very true, they’re inundated with competing worldviews and the need for continuous reconciliation.
I love the mapping metaphor!
In "Domain Driven Design - tackling complexity at the heart of software" - my personal bible of software development - a very similar relationship is highlighted: If the underlying model really matches the problem-domain and the software is built around this model, things suddenly start feeling simple. If this is not so many people don't directly notice this mismatch but start fighting all this complexity. Same with organisations. If the maps align and the organisational design is good, focussing on missions, objectives and features feels natural, occasional dependencies play a secondary role and can be handled by the teams directly. In this sense complexity is tackled at the heart of the organisation. If not: The org needs to deal with dependencies, cross unit alignment calls, bridging roles, theme/topic owners, expeditors etc. Complexity is here to stay.
Yes, managers should grow simplicity. Yes, the maps need to evolve rather than extra navigators assigned.
Thank you John Cutler for one more beautiful metaphor!
Thanks for this. Your "appearance of alignment" point has a concrete mechanism showing up in process documentation right now: a paper SOP staled visibly, so people learned when to stop trusting it and go find whoever actually knew the current state, but a continuously-regenerated AI SOP never looks old enough to doubt. HBR ran an editorial on exactly this in June — polished AI-generated SOPs can mask accuracy degradation and organizational knowledge decay. The artifact meant to manage the incoherence ends up hiding it instead, because the cue that used to send people to the fixer has disappeared.