Credit: Tim Brumley
Jorge Luis Borges once penned a short story (and I mean short - the English translation runs around 170 words) about an empire whose cartographers became obsessed with making their maps ever more vast and comprehensive.
In this kingdom, more and more maps were produced, until the map-makers reached an inevitable outcome: a perfect 1:1 map of the empire, laid over the landscape, each point modelled to painstaking perfection. Finally, the punchline hits: due to its sheer exactitude, the map was deemed useless. As the years passed, the citizens discarded it in the desert, where it crumbled to dust.
As Borges was writing in the 1940s, he probably didn't have large-scale Agile transformations in mind. Yet his model-versus-reality parable may feel pretty on the nose for anyone who’s spent time in one of today’s big Agile adoptions.
Let’s rewind and remind ourselves: Agile was originally attractive partly because it reduced complexity. It offers a small set of principles, some lightweight practices, a focus on feedback, working software, and responding to change. The map was always deliberately incomplete. That was sort of the point.
Somewhere along the way, we started drawing bigger maps.
The irony is that many of these 'maps' we now create are intended to make organisations simpler to navigate. Yet every additional layer of representation introduces another thing people have to understand, remember, and comply with.
(A personal aside: at one company I worked at, User Stories came with a checklist of 23 different fields that needed to be completed, before the work was deemed 'ready to start'. We also had more than 20 different meeting types. Looking back now, I could barely name half of them.)
Why does this happen?
It seems odd to make this mistake more than once. Why do we continually fall into this trap?
Part of the challenge is scale. After all, it’s far easier to design systems for five people and their specific contexts than 5,000. And, inevitably, some of it is the fear of losing control. More people, we fret, means more room for rogue behaviour. Let's add to the map.
Our ape brains also play their part.
We can be surprisingly susceptible to detail, mistakenly believing that adding more and more information can make something more likely to happen. Daniel Kahneman’s Linda problem isn't a perfect analogy, but it illustrates a related tendency: detail can make something feel more convincing, even when the additional detail doesn't make the underlying proposition more probable.
Agile models and excessive organisational maps can do something similar. But detail isn't the same as understanding.
When people are asked to navigate these exhausting maps, the cognitive burden is real.
We need maps - but not maps of everything
None of which is to suggest we simply have no map. Large organisations are complex. They need maps and models that can provide shared language, coordination, constraints, and useful patterns.
The question is whether the map is helping people navigate the territory, or whether people have become servants of the map. Once the model of an organisation becomes so detailed that we try to capture everything, the model can become the thing we're managing, rather than the organisation and the work itself.
The challenge is to be selective when designing, adding to, or subtracting from our map. Which leads us on to:
How do we avoid over-indexing on detail?
Whether you're creating a brand new map for your organisation, or even adding to or (!) subtracting from an existing map, I find the following five principles useful.
🤔 Start with the decision. Before adding yet another ceremony, role, metric, or governance mechanism, always start by asking what decision or behaviour it is we intend to improve. Is it really worth that extra layer?
🤏 Prefer the minimum viable model. Begin with the simplest version that might work, and add complexity only when experience tells you it is necessary.
➖ Subtract before you add. When something isn't working, resist the instinct to introduce another process to compensate. Ask what you could remove instead.
⚖️ Trust people to satisfice. Rather than designing processes around the assumption everyone will make the theoretically ‘ideal’ decision, give people room to choose an option that is good enough to meet the need. Satisficing isn’t lazy. It's how humans manage complexity. And no, trusting people won’t always magically align 5,000 souls in perfect harmony - but nor will wrapping everything in endless processes.
❓ Finally, periodically question the map itself. What are people actually using? What are they working around or gaming? What has become ritual? What information is being collected but never acted upon? What could we stop doing?
The answer isn't to pretend large organisations are simple. It's to be ruthless about which complexity actually helps people navigate that reality, and which complexity we've simply accumulated.
The moment our map requires so much effort to maintain and follow that it starts consuming the capacity of the people it’s supposed to help, we may have built Borges' map.
Perhaps the most Agile thing we can do is throw some of it away. Leave it in the desert.
