The encyclopedia of cognitive moves

When your problem feels stuck, change the size of the thing you're looking at by running six zoom lenses (Structure, Cycle, Actor, Link, Ensemble, Service) until a unit appears that you can actually control.

Break the thing into its component parts and ask which single part you could study on its own. You are looking for pieces and materials, not timing, people, or purpose. Each part becomes a candidate unit to analyze instead of the whole.

Re-cut the thing as something that repeats on a clock instead of a fixed object. Ask what its period is, which phase of the loop you are in, and whether the pattern is daily, weekly, monthly, or seasonal.

Re-cut the problem around a person or agent instead of a thing or process. Ask who actually performs the behavior, and which specific role or version of that person, since different actors do different things at different moments.

Study a relationship instead of the things it joins. Ask what passes between two parts, how one feeds the other, and where the handoff breaks. The pair becomes what you measure and change, not either part alone.

Step up from the single instance to the whole set it belongs to. Instead of studying one case, study the population or system of like cases and ask what the distribution shows: how often, how much spread, which outliers, what the group does that no single case reveals.

Ask what job the thing is supposed to do, and make that job the unit instead of the object. Where the other lenses cut by parts, timing, people, or connections, this one cuts by function, so anything delivering the same result counts as the same unit.

Regroup your cases into new categories until membership in a group actually changes what you predict or do.

Take one crowded bucket and cut it along the different processes that actually produce its cases. You ask what causes each case, not what it looks like on the surface, then give each distinct cause its own group.

Collapse two or more of your existing categories into one when they do the same job for you. Different labels, identical behavior, identical decision. Where splitting divides a crowded bucket, this asks which separate buckets you never actually treat differently.

Sort cases by how they react when you push on them, not by what they are. Run the same intervention across everything, then put whatever reacts alike into one pile, even if the items look unrelated on the surface.

Pull the few odd cases out of a group and give them their own bucket, so what stays behind behaves the same way. Unlike a full reslice, you move only the misfits, then write a separate rule for them.

Instead of one flat cut, stack two or three levels of grouping, and let each branch be split by its own rule. You then act at whichever level the decision lives on: broad strokes up top, fine distinctions only where they change something.

Redraw what counts as inside versus outside the problem so that hidden dependencies and costs come into the frame.

Step one link backward from whatever you're blaming and ask what feeds it: who supplies its inputs, sets its deadlines, hands off work to it. Bad or late inputs cause failures the actor itself could never have prevented.

Ask who receives the output and what it costs them. Follow the work forward past your current stopping line to the people who wait on it, rework it, or absorb the damage, and let their pain count as part of the problem.

Look sideways instead of up or down the chain. Who sits beside the blamed party, sharing its people, budget, tools, or calendar, and constrains what it can do without ever appearing in the workflow diagram?

Ask what ambient conditions the whole system sits in: rules, incentives, tooling, budgets, physical setting, market pressure. These aren't people or handoffs, they're the background that shapes every actor's behavior at once and usually goes unnamed because it never changes during the analysis.

Ask what inputs your frame treats as free, unlimited, or somebody else's problem. Budget, tooling, shared systems, senior attention, headcount. These never appear in the explanation because nobody counted them, yet the work cannot happen without them.

Ask who absorbs the costs your current frame does not bill anyone for. Not who feeds or consumes the work, but who quietly pays for it in overtime, rework, or damaged trust while sitting outside the box you drew.

Stretch the clock rather than the org chart. Ask what happened before your data starts and what happens after it ends. Causes that predate your window, and costs that land after it, are invisible to every actor-level or upstream check.

Swap the variables you describe things with, turning labels into continua, averages into distributions, and traits into states, so hidden differences become visible.

Swap the either/or category name for a graded scale, so the question changes from which box someone or something belongs in to how much of the quality is present, measured in degrees you can actually rate.

Measure how fast something is changing and in which direction, not where it currently stands. A low score climbing steadily is a different problem than a high one sliding, though a single snapshot scores them the same.

Stop summarizing with one middle number. Ask instead how the cases spread out: how often the high end shows up, how often the low end, and how wide the gap is. Two situations with identical averages can need opposite fixes.

Stop describing something as a permanent property of a person or thing, and describe it instead as a condition that switches on and off. The question becomes what turns it on, how long it lasts, and what turns it off.

Stop scoring one factor at a time and ask which factors only matter in combination. Some causes do nothing alone and everything together, so a description that tracks each separately will keep missing the pattern that actually predicts the outcome.

Titles and role names carry assumptions about what someone does. Drop the title and list the actual jobs being performed, each one measurable on its own, so you can see which functions are covered, missing, or handled by someone else entirely.

Make the order of events explicit, because the same ingredients in a different sequence produce a different outcome.

Write down the timeline you already have, in three slots: what happens ahead of the key event, what happens inside it, and what follows. This is the baseline picture, taken as-is, before you change anything about the order.

Run the same steps backward and ask what breaks or improves. It is a stress test on order dependence: if flipping the sequence changes nothing, order was never the issue, and you should look elsewhere for the real constraint.

Break a long run of steps by adding a stopping point partway through where you test what you have or decide whether to keep going. You add steps rather than reorder them, so errors surface while they are still cheap to fix.

Cut a stretch you have been treating as one continuous activity into segments that run by different rules. Each segment gets its own goal, its own success test, and its own definition of what confusion or slowness means.

Walk the order you mapped and mark every step you cannot take back once it happens. Those one-way doors constrain the rest: cheap reversible moves can go early and be tested freely, while a step that spends something permanently should wait until it has the information it needs.

Change the baseline or comparison class behind a judgment, because every evaluation secretly depends on what it is being compared to.

Measure the thing against its own earlier state instead of against anyone else. Ask what changed between then and now for this same person, team, or project. It reveals rate and direction of movement, which cross-sectional comparisons to other people cannot show.

Ask who is genuinely comparable: people matched on the conditions that drive the result, like starting point, time invested, resources, and constraints. Whoever is loudest or most visible is a sampling artifact, not a peer group.

Judge the result against the realistic option you could actually have taken, given your money, time, and skill at the time. Not the ideal outcome, not zero effort, but the best real substitute that was on the table.

Ask what would have happened if you had never started. That isolates what the effort itself added. Unlike the next-best-option contrast, this one holds effort at zero, including whatever slow drift or decline doing nothing would have brought.

Measure the result against the ceiling: the strongest outcome physically possible given your constraints, talent, and time. This contrast ignores what is typical or what you did before, and reports only the size of the remaining gap.

Ask where you sit in the whole spread, not against one summary number. Look at the range, the subgroups inside it, the tails, and how it shifts over time. A single average hides how much variation is normal.

Map which tasks must come before which, so the real bottleneck and critical path stand out from the pile of visible work.

Marks a hard ordering link: item B literally cannot start or finish until item A is done. You are testing necessity, not habit. Ask what physically or logically breaks if you flip the order. If nothing breaks, it is not this kind of link.

Some pairs cannot be staggered. Flag the two items that have to be true at the same moment, not merely both done eventually, because finishing one early and letting it lapse leaves you no further ahead.

Flags a link you could cut and still ship. The later item works without the earlier one; skipping it costs polish, not function. Marking these tells you where the slack lives, which items to defer first when the date gets tight.

Some prerequisites can be met more than one way. Tag those, because a second supplier, tool, or person makes the requirement look like a hard blocker when it is really a choice. Substitutable items rarely deserve emergency attention.

Flag the items that stop other work cold until they clear. A must-precede link only sets order; this one freezes everything behind it. For each candidate, count how many downstream tasks sit idle and how long they wait.

Once you have marked the links, trace the longest unbroken chain of must-precede tasks. That chain sets your earliest possible finish date. Every task off it has slack, so a day lost there costs nothing, while a day lost on the chain slips the whole launch.

Sort your ideas into their proper levels (goals above functions above mechanisms) so you stop comparing things that were never peers.

The top tier: the end states you actually want, valuable in themselves rather than because they get you something else. Test each item by asking "why do I want this?" If a further answer exists, the item belongs on a lower tier.

Ask what jobs have to get done for a goal to be reached, stated without naming any method. This tier sits between the outcome you want and the specific tactics, so each entry answers "what must happen," never "how."

The concrete how of a function: the specific method, routine, or machinery you would actually run. Swappable by design, since several different mechanisms can serve the same function equally well. If you can't picture doing it Tuesday morning, it isn't here.

One level below mechanisms: the physical or procedural parts a mechanism is assembled from. Ask what pieces have to exist for the mechanism to run at all. Pieces are things you buy, install, or schedule, not outcomes you want.

Pull out the individual, actual cases and set them apart from the general category they belong to. A single case carries details that don't hold for the whole class, so treating one as the category itself quietly turns a one-off into a rule.

Pull out the items that are only measurements standing in for something else. They are readings on a dial, not the goal, function, or mechanism itself. Once labeled this way, they stop competing with the things they were meant to track.

Replace 'these things go together' or 'this person is to blame' with a testable mechanism of what would change what.

Write out two or more competing causal stories that would each explain the same pattern you observed. Spell out the actual chain in each one, and keep only the ones that would predict different results, since identical predictions give you nothing to test.

For each rival mechanism you listed, name the specific spot you could actually reach in and change something, and say what would shift downstream if that mechanism is the real one. Handles you can grab, not structure you can only describe.

Name the in-between step the cause has to run through to reach the outcome. Not what else could explain the link, and not what changes its strength, but the actual chain: cause acts on this, and this acts on the result.

Ask what hidden third thing could be driving both sides at once, faking a link between them. Unlike a mediator, which sits on the causal path, this factor sits off to the side and manufactures the correlation you noticed.