Two Libraries for Wicked Problems

You’re stuck on a problem. The natural assumption is that you’re stuck because the problem is hard — it’s complex, interconnected, maybe even wicked.

I don’t think that’s why you’re stuck. I think you’re stuck because you keep looking at it from the same altitude — and I notice this pattern a lot in conversations with museum leaders.

The metaphor I lean on is altitudinal messiness. If we imagine a problem existing at 20,000 feet, then going granular brings us down to ground level, and going lateral¹ elevates us above the problem to see the surrounding landscape.

The trap is staying at the same altitude — circling the same problem from the same vantage point, following all the interconnected threads, never going below or above. Stress makes it worse (cortisol narrows our range of responses), but the underlying issue is directional rather than cognitive. The fix isn’t to think harder. It’s to change altitude.

Going granular means breaking a challenge into smaller, testable claims. You identify specific assertions, isolate variables, and run experiments. You’re generating your own evidence through direct observation.

A caveat: Decomposition works best when you can estimate the parts more confidently than the whole — for example, if “declining program attendance” feels overwhelming as a whole, but you could reasonably gauge whether people know about your programs, whether the content matches what they want, and whether the timing works. Research by MacGregor and Armstrong found that when this condition is met, breaking problems into components can significantly reduce estimation error. But when you can already size up the whole problem reasonably well, decomposition can actually add noise — in some cases, increasing error by over 400%. The rule to remember is to go granular when the pieces are clearer than the puzzle.

Going lateral means analogical thinking — finding challenges others have solved that rhyme with yours, and importing their patterns. You ask: What other domains have faced something like this? What insights transfer? You’re leveraging evidence others have already generated.

Both approaches are grounded in evidence. The difference is the source: your own data versus others’ insights.

There are two structural practices that support these approaches. Both require tending — you build them over time, and their value compounds with maintenance.

Two libraries

An evidence library accumulates data around your challenges. Every observation, survey result, or documented outcome contributes to going granular when you need to. You might be sitting on a nascent evidence library that you call a CRM² or a folder full of spreadsheets from past visitor studies. These all qualify — think of them as books littered around your house that you never organized in a bookshelf.

A pattern library or source library holds the lessons and metaphors others have found in their explorations of challenges that might rhyme with yours. Whether those patterns are available when you need them depends on how much attention you’ve paid to organizing what you encounter. You’ve read something that would solve your current problem. You just can’t remember where. Researchers call this “inert knowledge” — relevant insights sitting in your head that don’t surface when you need them. In laboratory studies, only about 10% of people solved problems when they had to retrieve analogies on their own. When prompted to use a specific analogy, success jumped to 75-92%. A pattern library is a retrieval mechanism — it makes what you’ve encountered findable when a challenge arrives that could benefit from it.

A place to start

Pick one challenge you’ve been circling. Not your biggest institutional problem — something mid-sized, where you have some control and can actually see results.

First, try the granular direction. Write down 3-5 assumptions embedded in the challenge (here’s a way to surface assumptions). For each one, ask, “Can I test this?” If you’re wrestling with declining program attendance, your assumptions might include “our audience doesn’t know about these programs," “the programs don’t match what people want,” or “the timing doesn’t work for our visitors.” Each of these is testable. Pick one. Design a small observation or conversation that would tell you whether it’s true.

Then try the lateral direction. Ask: What other field has faced something like this? Libraries dealt with relevance questions when digital alternatives emerged. Theaters navigate the tension between artistic vision and audience preferences. Restaurants figure out how to serve regulars while attracting new customers. Find a case study, article, or conversation from an adjacent domain. Look for the structural similarity, not the surface features.

You don’t need both libraries built to start. You just need one challenge, one testable assumption, and one borrowed pattern. The libraries can accumulate from there.

Kyle