Management foundations case study: findings and lessons

No organization is described on this page, and no manager, project or result. That is deliberate. A management case study is a story about a person who made choices under conditions you cannot see, and the useful skill is reading one, not collecting more of them.

The general craft of reading operations write-ups is covered in operations case studies. What follows is the narrower problem: why stories about managing are harder to learn from than stories about processes, and what you can do instead.

What to take away

• Every management case is written backwards from the ending. Decisions that were close calls at the time appear in the text as obvious, because the author already knows how they turned out.
• The practice and the person cannot be separated in the telling. What transferred may have been authority, tenure or slack rather than the method being described.
• You will never get the counterfactual for someone else's decision. You can get a rough one for your own, by writing down what you expected before you find out.

The story is built from the ending

A case study is assembled after the outcome is known, and the outcome determines which details are included. This is not deception. It is what narrative does, helped along by the way knowing an ending makes the route to it look inevitable, an effect known as hindsight bias.

Watch for the effects. Decisions that were genuinely uncertain arrive with a stated rationale, because the rationale that turned out to be right is the one that gets remembered. Steps taken in the wrong order become a sequence. Months of confusion compress into a paragraph. The people who disagreed either vanish or become the obstacle the manager overcame, and their argument, which was often reasonable at the time, is not reproduced.

The practical consequence is that you are shown a decision rule that nobody actually had. What existed at the time was a judgment made on partial information, with a fair chance of going another way.

A test you can apply while reading: cover the second half. From the situation as described, would you have predicted the choice they made? If not, and the text presents it as evident, the account has been tidied.

The person is doing work the method is credited with

An operations case can sometimes isolate a mechanism: this step moved, that handoff went away. A management case rarely can, because the intervention was delivered by a specific individual in a specific position.

Four things typically travel with the manager and not with the practice.

Authority. Some approaches only work if the person can actually decide. The same conversation held by someone who cannot commit resources produces politeness rather than agreement.

Tenure and credit. A manager who has been right before can spend the belief they accumulated. A new one asking for the same latitude is asking for a loan.

Slack. Being able to take a team off delivery for a fortnight is a resource. Where it is absent, the same plan becomes a series of squeezed evenings and quietly fails.

Permission to fail once. Many recommended approaches require an attempt that does not work. Whether that ends the initiative or is treated as information is a fact about the organization, not about the method.

When you read a management case, ask which of the four was present and whether it is present for you. Most failed imitations trace to one of them, and the failure gets attributed to the technique or to the imitator's competence.

The sample you cannot see

The managers who tried the same thing and were quietly moved sideways do not get interviewed. Neither do the ones for whom it worked and who never wrote anything down, which is most of them.

So the collection of management stories you have access to is not a sample of what works. It is a sample of what is publishable, and publishability correlates with a clean ending, a nameable method, and an author with a reason to be visible. Reading an archive assembled that way and concluding something about the odds is the error called survivorship bias.

This does not make the stories worthless. It means the honest conclusion from any of them is "this can work, and here is a mechanism worth considering," never "this works." The difference matters when you are about to spend a team's tolerance for change on it.

Reading for the question, not the answer

The transferable part of a management case is almost never the decision. It is the distinction the manager drew before deciding.

Someone who separated the deviations that harmed other people's work from the ones that were merely different has given you a distinction you can apply anywhere. Their conclusion about one person is worth nothing to you. Someone who noticed that the disagreement between two teams was about an undefined word rather than about attitude has given you a question. Which word is undefined in your case is yours to find.

A habit worth having: after reading, write one sentence stating the question the manager asked themselves, with no names, no numbers, and no outcome. If you cannot write that sentence, the case was a story rather than a lesson, and there is nothing to carry away. The constructed situations in management foundations examples are written this way on purpose, with the reasoning exposed and the result left out.

The only base rate you can actually build

You cannot run the counterfactual on someone else's organization. You can run a weak one on yourself, and it costs about five minutes a week.

Keep a decision record. One line per decision that is not trivial, written at the time:

• What you decided, in a sentence.
• What you expected to happen, specifically enough to be wrong.
• How confident you were, in ordinary words: fairly sure, could go either way, a long shot.
• What would tell you it was going badly, and roughly when you would know.

Then read them in a batch every few months, not one at a time. Read individually, each entry gets explained. Read together, patterns appear that no single case shows: the kind of decision you consistently make too late, the kind of estimate you always halve, the situations where "could go either way" turns out to mean nine times out of ten.

That is the closest thing to evidence about your own management you will ever have, and it is better than any external case study, because the context is held constant. It also settles arguments with yourself that memory would otherwise settle in your favor.

Two cautions. Record confidence before the outcome, not after; reconstructed confidence is always higher. And keep it private and about decisions, not about people. A file of observations about individuals is a different artifact with different obligations attached, and anything heading toward formal consequences belongs with your HR function rather than in a personal notebook.

When someone brings you a case study

You will regularly be handed an example as an argument. A short set of responses that keep the conversation useful:

• "What was the situation before?" If the answer is a mood rather than specifics, comparison with your own situation is impossible.
• "What else was happening at the same time?" Rarely nothing, and rarely mentioned.
• "What is different about them that would break this here?" The person offering the case has usually thought about this and decided it was not important. Their reasoning is the interesting part.
• "What did they stop doing to make room for it?" If the answer is nothing, you are being shown an addition, and additions come out of the same capacity your existing work uses. The strategic planning pillar treats that arithmetic in more detail.

None of these are objections. They are the questions that turn an anecdote into something you can act on, and asking them in front of the person who brought it is better than deciding privately that they are naive.

For the standing obligations that no case study will change, see management foundations, and for the week-to-week decisions no story can make for you, team management.

Common questions

Why avoid naming organizations here at all?

Because a named example does two things at once: it makes the point vivid, and it imports a set of claims about a real company that this page has no way to verify. The second cost is larger. A constructed situation with the reasoning exposed teaches the same thing and asserts nothing about anyone.

Is a case from someone I know better than a published one?

Usually yes, because you can ask follow-up questions and they have less reason to tidy. Ask what nearly went wrong and what they would not do again. Both answers are absent from published versions and are where the value sits.

How do I stop myself pattern matching?

Force the difference to the surface before the similarity. Write down three ways their situation is unlike yours before you write down what you are going to copy. The similarities will occur to you anyway; the differences will not.