You Don't Need a Better Map. You Need a Compass.

You've run this play before. It worked, too. It's the framework you couldn't escape if you tried. The smartest person you know swears by it. It was in the article you read last week, and the book before that. Fast Company ran its own version. It got a keynote at the last two conferences you sat through. And the founder you grabbed coffee with wouldn't stop telling you what it had done for her team. So you brought it in, and it worked. It turned a quarter around, and you watched it land. Then things got hard again. You reached for it the way you'd reach for a familiar tool, and this time it did almost nothing.

Or maybe that was never your story to begin with. Maybe it never really worked for you at all. Everyone around you swore by it, and you could never get it to do for your team what it seemed to do for everyone else's, and you wondered what they had figured out that you hadn't.

Either way, it's a strange, lonely feeling. Not because the framework was wrong, but because it used to fit, and now it doesn't, and nobody can quite tell you why. You start to wonder if the problem is you, or your team, or whether you just ran it wrong. You tighten the screws. You add a step. You find a newer framework with a better acronym and roll that one out instead. For a quarter, maybe two, it helps. Then the same stiffness creeps back in.

Here's the thing almost nobody says out loud: the framework was never the asset. It was a souvenir of one. And the day the world it was built for changed, you were left holding the shape of a solution with the reason for it quietly missing.

Why the best practice becomes a cage

Every framework you've ever used started its life as a living insight. Someone, somewhere, was staring at a real problem and saw the pattern underneath it. That seeing is the valuable part. The framework is just what they wrote down afterward so they wouldn't have to see it from scratch every time.

That write-down is generally useful. It's fast, it's repeatable, it can scale. You can hand it to a new hire, and they can run it on Monday. But something gets left behind in the writing. The why gets compressed out. What you're handed is the steps, not the seeing.

And while you can still feel the why behind the steps, you're fine. You can bend the framework when your situation is a little different. You can break it when it needs breaking, repair it when it cracks, stretch it to cover a case its author never imagined. But the moment the why is gone, all of that goes with it. You can't bend a rule you don't understand. So you reach for the only moves left: run it faster, push it harder, or throw it out and go find a newer framework to replace it. They feel like different responses, but they're the same reflex, reaching for a better set of instructions instead of recovering the understanding the instructions were standing in for.

That's the trap, and it's worth naming plainly: a best practice becomes a cage not when it's wrong, but when everyone who could explain it has moved on. It's the difference between following a recipe and knowing how to cook. A recipe will get dinner on the table. But the cook who understands why it works can rescue it when the sauce breaks, swap what's missing, scale it for a crowd, save it when the oven runs hot. The person with only the recipe is fine right up until something on the night doesn't match the card. Then they're stuck, holding the steps without the reason. A framework is a recipe. Most of the time we're handed the card and never taught to cook.

You've felt the other side of this. Think of the last time you called a big company's support line and hit a wall. Most enterprise support is built as a decision tree: a branching map of scripts and knowledge-base articles where the agent's whole job is to navigate to the right card and read it back to you. It works beautifully when your problem is one the tree saw coming. The moment it isn't, you watch a well-meaning person get stuck, because they have the cards and not the understanding underneath them. They can't bend the answer to your situation, so you get put on hold, or escalated, or asked five questions that have nothing to do with what's actually wrong. The companies famous for service do the opposite. Zappos trains every new hire for weeks and runs its call center with no scripts and no stopwatch on the calls. Ritz-Carlton lets any employee spend up to two thousand dollars to fix a guest's problem on the spot, no manager required. They hired cooks, not recipe-followers.

Putting every new hire through weeks of training runs against every instinct a spreadsheet has. It looks like pure cost, and it's the cheapest thing they do, because the person who understands can handle the call no script saw coming, and those are the calls that decide whether a customer stays. The heavy investment is really an investment in understanding, paid up front and on purpose. I'll admit I have a framework for exactly that. Total Onboarding™, a way to bring people into the why of the work and not just the what. Yes, I see the irony of selling you a framework in an essay about frameworks becoming cages, but that's the point of it: a framework earns its keep when its whole job is to teach the why and get the understanding into the system before anyone can lose it. That kind of investment is rarer than it should be. Most of the time we do the exact opposite without noticing.

You can watch it play out with almost any method everyone adopts. Take OKRs. Ask a roomful of people who run them every single quarter what actually separates an Objective from a Key Result, and watch how long the pause gets. They'll have the spreadsheet, the cadence, the color-coded scoring. What they often won't have is the one distinction the whole thing is built on. The form travels effortlessly. The understanding that makes it worth anything gets left at the door.

I've written before about how the institutional memory of why something is done decays one promotion cycle at a time. Every handoff, every reorg, every "this is just how we do it here" spends a little of the original understanding. Eventually you're left with a company full of procedures nobody can justify, faithfully executed by people who would change them in a heartbeat if they only knew what they were for.

Why we don't go back for the why

There's a reason the understanding gets abandoned, and it isn't laziness. It's economics. Two very different kinds of work go into any framework. One is the discovery, the innovation itself: the slow, uncertain, unglamorous work of staring at a hard problem until the pattern underneath it gives way. The other is everything that comes after: adopting it, teaching it, scaling it across the company, publishing it, writing the book about it, giving the conference talk.

Almost all of the return lives in that second part. But all of the value was created in the first. That is the quiet irony of it: the half that holds the value gets logged as a cost, paid once, often invisibly, by someone who may be long gone, while the half that holds none of it is where the payoff shows up, quarter after quarter. So every incentive points the same way, toward running the framework and away from re-earning the understanding beneath it. Nobody wants to pay the discovery cost twice.

And that "cost" framing actually undersells it. You already know this balance from running a business. The framework is the product, the thing you can package and hand over. The understanding is the sale, and the sale is what keeps the whole thing alive: the best product in the world is just inventory gathering dust until someone sells it. Understanding isn't a bill you paid once at the start. It's the sale you have to keep making, the thing that keeps the framework earning its place. Let it lapse and you're left holding a product you can't move, a polished procedure that has stopped working. You already give your fiercest attention to the thing that keeps the business alive. Your thinking deserves no less.

And the instinct isn't wrong, which is exactly what makes it a trap. The whole point of a framework is that you can put it to work without re-doing the hard thinking. That is the return on the investment, and it's a real one. The catch is only this: the world eventually moves, the use stops paying, and the only way forward is to go back and pay the discovery cost again, on purpose, before the thing fails you. None of this is a new worry. The organizational theorist James March gave the two halves their names decades ago, exploration and exploitation, and found that organizations leaning too hard into exploiting what they already know tend to win in the short term and lose in the long one. The teams that stay adaptable are the ones who keep a little of that expensive, generative work alive even while they're busy cashing in on what it already built.

What running it harder actually costs

When the why is gone and the framework starts to slip, almost nobody's first move is to stop and rethink it. The first move is to run it harder. More hours, more hustle, more check-ins, more of exactly the same thing with the volume turned up. If the playbook isn't working, the instinct says, you must not be running it hard enough.

In a stable world that instinct is often right, and effort closes the gap. But when the environment has actually changed, harder is a bet that the shape was right and only the energy was missing. And there's a difference between doing the same thing harder and doing the right thing. It's the whole game. The first is efficiency, the relentless optimization of a fixed approach. The second is effectiveness, doing the thing that actually moves you now. A framework you can't bend can only make you more efficient at what it was built for, which is wonderful right up until that thing stops being what matters. Then all the extra effort just gets you to the wall sooner, and more tired.

I learned this running a team, and I've written the long version of it here: a two-year turnaround at a studio that had hit a lean stretch and came back to a strong, durable margin. It didn't come from working harder, or faster. Same people, same hours, same tools. We changed what we were paying attention to. We didn't get faster. We didn't push harder. We got more effective. The frameworks we'd inherited, the ones every shop our size was running, were optimized brilliantly for a question that had stopped being the right one.

That's what a framework with no why does to a smart, hardworking team. It doesn't make them fail. It makes them succeed, efficiently and exhaustingly, at slightly the wrong thing.

The thing about Cinderella

So you might reasonably conclude that the answer is to distrust frameworks, throw out the playbooks, treat every situation as brand new. That's the wrong lesson, and there's a beautiful demonstration of why.

In a now-famous lecture, Kurt Vonnegut gave a short, funny account of the shapes of stories. He walks up to a chalkboard and draws a simple graph. Up the side runs fortune, from worst at the bottom to best at the top. Across the bottom runs time, from the start of the story to the end. Then he draws Cinderella. He draws "Man in a Hole." He draws "Boy Meets Girl." And he shows you, in about five minutes, that essentially every story humans tell runs on one of a small handful of simple shapes. It's worth watching. And it isn't only a charming theory. Decades later, a team at the University of Vermont ran more than 1,700 stories through a computer and found he was essentially right: the emotional arc of almost everything we read collapses into one of about six basic shapes.

There's a quieter lesson in that gap. Vonnegut first offered this idea as his master's thesis, and the university rejected it. Half a century later, the data caught up and agreed. The data almost always does that. It is not the enemy, and it is not the discovery. It confirms, after the fact, what someone working at the edges already saw and chose to bring into the world. The insight comes first. The proof comes later, and takes its time.

Now, the part that matters for you and your team. Those shapes are abstractions. They are, in a sense, the most reusable "frameworks" in human history, a few lines on a graph that have governed storytelling for thousands of years. And yet we have never gotten tired of them. We retell Cinderella in a hundred new costumes and feel something every single time. The shape is fixed. What makes each telling alive is the fresh context poured into it.

That's the resolution to the whole problem. The abstraction was never the cage. An abstraction is endlessly generative, as long as you keep wrapping new, living context around it. The cage appears only when you stop doing that, when you take the shape and run it mechanically, expecting the old result in a world that has moved on. Hold the shape and keep authoring real context for your actual situation, and the same pattern renews itself forever. That's effectiveness.

Real patterns get simpler

How do you tell the difference, in practice, between a framework that will cage you and a pattern that will travel?

When you find a genuine underlying pattern, it gets simpler, not more complicated. Vonnegut reduced all of literature to a shape on two axes. That's the tell. Real abstractions have the elegance of a geometric proof: spare, almost obvious in hindsight, and absurdly useful across situations that look nothing alike. They bend without breaking, because there's so little to break.

A framework heading toward cage-hood does the opposite. It accretes. More boxes, more steps, more sub-frameworks bolted on to patch the last place it failed. It gets heavier and more brittle at the same time, until it's a jerry-rigged contraption that gives you exactly one output and shatters the moment your situation doesn't match the diagram.

So when the work in front of you keeps demanding more boxes, that's not a sign you need a better framework. It's a sign you haven't found the pattern yet. The pattern, when you find it, will feel almost too simple to be worth that much.

Why I see frameworks this way

I didn't arrive at this from a book. I arrived at it from spending twenty-five years solving problems in too many different rooms.

For eight years I led design at a studio called gskinner, building edge-of-release technology for Google, Microsoft, Disney, and the NFL. We built the tool that gave the winningest team in NASCAR a data edge on race day. We built the official NFL fantasy app, and Microsoft liked it enough to hold it up as an example for their other partners. Before that, and after, I ran my own studios. Later I managed UX on the team behind Shopify Capital. I've sat with founders, scientists, broadcasters, engineers, and designers, on problems that ranged from "ship this in twelve weeks" to "this team can't stand to be in the same meeting."

When you work across that many disciplines, with that many genuine experts, on that many unrelated problems, something strange happens. You start to notice that the frameworks rhyme. The thing the agile coach swears by and the thing the org-design consultant swears by and the thing the lean manufacturing guy swears by turn out, underneath the vocabulary, to be the same handful of ideas wearing different uniforms. Most frameworks aren't unique discoveries. They're the same small set of underlying abstractions, arrived at independently by different people in different fields, dressed in the language of each. Genres wrapped around Vonnegut's shapes.

Here's one you can run yourself. Take the Business Model Canvas, the nine-box diagram nearly every founder has filled in at least once. Strip off the boxes and the labels, and what's left is almost embarrassingly simple: the activities that create the value on one side, the activities that deliver it on the other, and the thing in the middle that translates between them, which is the part people actually buy. Everyone in the company is heads-down on the two sides, creating, selling, building, maintaining, growing, while the thing they are all serving sits quietly in the middle. That residue isn't really about business models. It works just as well on a team, a project, a career, even a single conversation, because it's the pattern and not the template. I took that one all the way down to its bones once, and it turned into something of its own. A story for another day.

You can only see that from across the disciplines, not from inside one. And it changes what you reach for. Once you've watched the same pattern surface in a microbiology lab and a creative agency and a venture pitch, you stop collecting frameworks and start collecting the patterns underneath them, the ones that keep showing up because they're real. There's a name for what happens at the overlap of two different ways of seeing, the place where a genuinely new pattern shows up. I call it the Core Unit of Creativity™, and it's essential to innovation, problem-solving, and finding solutions.

A map, or a compass

I have been hard on frameworks for this whole essay, so let me be fair to them. They are sturdier than I have made them sound. A good one is genuinely resilient. You can pour wildly different situations into it and it will hold its shape and give you something useful, as long as two things stay true. The work has to be specialized enough that the framework was built for roughly your kind of problem, and the world around it has to stay roughly stable. Inside those two conditions a framework is a gift. It takes hard-won understanding and makes it fast, repeatable, and easy to hand to someone else. Most weeks, that is exactly what you want.

The catch is that both conditions are on loan. They hold right up until they don't. When something genuinely big moves, a technology that rewrites your industry's rules in a year, a competitor who opens up next door or appears out of nowhere on the other side of the world, a social upheaval, a disruption nobody saw in the model, a pandemic that rearranges how everyone works, the frameworks and the playbooks and the processes stop bending. They break, all of them, at roughly the same time. Because underneath the diagrams, every one of them is a map. And a map is only ever as good as the day the territory was surveyed.

And the shift that breaks a framework isn't always out in the world. Sometimes it's in you. You grow, you live through something, you come out the other side seeing more than you did, and a playbook built for the person you used to be quietly stops fitting. This is the one I see most in the people I work with: leaders twenty-some years in who have started to see something they can't unsee, whose sense of what the work is really for has shifted underneath them, for whom the same old play, the one that always felt right, just doesn't anymore. Nothing out there changed. The terrain moved because they did. That isn't a problem to fix. It's usually growth, the kind that retires the map you were using.

That is why buying a better map is the wrong instinct, even though it is the one almost everyone reaches for. You can buy a hundred of them and still be holding a picture of the ground on the day it was drawn. What you need is the other instrument. A pattern is a compass. It does not tell you the turns. It tells you which way is north, anywhere, in terrain that is changing under your feet. It is less comforting than a map, because it asks you to do the navigating. But it is the only thing that works when the ground will not hold still, which, right now, is most ground. In a 2026 survey, more than eight in ten executives said their boards and owners now expect them to adapt to constant disruption, and many of the same leaders admit they have no clear playbook for actually doing it. Of course they don't. There isn't one to have. The playbook that got you here is, almost by definition, not the one that gets you through what comes next.

This is the actual work I do with leaders and their teams: not handing them a better framework, but helping them find, hold, and apply the patterns underneath, so they stop needing a new playbook for every situation and start being able to read the terrain themselves. It's slower to teach than a framework and worth infinitely more, because it's the one capability that doesn't expire. Give a capable team a compass and the judgment to use it, and you stop being the only person who can navigate. I've watched that shift land in a month, and I've written about why "just delegate more" can't get you there on its own.

It rests on an old idea about what learning is actually for. Training hands you the steps for a job that already exists. Education builds the capacity to see the one that doesn't yet. It was never really about the job. It was about seeing a little further than you could before. A framework trains you. Holding the pattern underneath it is closer to an education. The leaders I do my best work with want that, for themselves and for the people around them, and they would rather get better at seeing than be handed another answer.

Where to start

If you recognized your own company in the first few paragraphs — the framework that stopped fitting, the boxes piling up, the quiet suspicion that you're running something harder instead of better — the move is not to go find a sharper framework. That's buying a better map.

The first move is to pick the place where your team is most obviously running a play nobody can explain anymore, and ask the question out loud: what was this actually for? Not "how do we do it." Why it exists. Half the time the why is still good and everyone relaxes. The other half, you've just found a cage, and you can start building the thing that replaces it: a team that holds the pattern, not the procedure, and can adapt it without you in the room.

That's the work. The frameworks will keep going out of date. The ability to see the pattern underneath them is the one thing that doesn't.

‍