Management foundations examples: lessons and useful context

Management advice tends to be stated at a level where it is impossible to disagree with and impossible to use. This page works the other way: a set of ordinary situations, each with the reasoning laid out, including where the obvious response is the wrong one.

These are illustrations, not reports. No real organization, person, or outcome is being described. They are constructed to show how a decision is reasoned about, and you should adapt them rather than match them.

What to take away

• Someone reliable for two years has been missing things for about a month.
• A step is removed from a process to speed it up.
• A recurring meeting, twelve attendees, an hour, weekly.
• A manager hands a piece of work to a capable person.

The person who is always the exception

A team of eight. One of them is unmistakably the strongest, and also the one who misses agreed dates, skips the process everyone else follows, and does the work their own way. The output is good. Everyone has noticed that the rules do not apply to them.

The instinct is to weigh their output against the disruption and, because the output is high, to let it continue. That underprices the second effect: every other person has now learned that the standards are negotiable if you are valuable enough. That belief is expensive and hard to reverse.

The more useful move is to separate the two things. Which of the deviations actually harm anything, and which are just different? Someone who works odd hours and produces excellent results is not a problem. Someone who skips a check that exists to protect other people's work is, regardless of their output.

Then be specific about the ones that matter and say why in terms of the effect on others, not in terms of compliance. "When you go straight to the client, the delivery team finds out about the commitment afterward" is arguable on the merits. "You need to follow the process" is a status contest you may lose.

And consider whether some of the deviations are correct. A strong person routing around a process is data about the process. If they are right, change it, publicly, and you have gained both an improvement and their engagement.

The handover that keeps not happening

One person holds a system nobody else understands. Everyone agrees knowledge should be shared. Six months of agreeing has produced nothing.

The standard diagnosis is that the person is protecting their position. Occasionally true; usually not. The ordinary explanation is that they are at capacity, documentation has no deadline, and every week something urgent outranks it.

Things that tend to work: pick one specific request type, not the whole system. Route the next three of those to someone else, with the expert available to help rather than to do it. The learning happens on real work with a real deadline, which is the only setting where it reliably happens at all.

Also, take something away. Adding a knowledge transfer to a full queue means it will not happen, and it will look like reluctance.

If it genuinely is protective, that is a conversation about what they are worried about: usually being seen as replaceable. It does not get resolved by process.

Two teams that each think the other is the problem

One team says the other sends incomplete work. The other says they are being blocked by pedantry. Both are frustrated, and each has escalated.

Almost always, "incomplete" is undefined. The sending team believes they have finished; the receiving team believes they have not; there is no written statement of what complete means, so both are sincere.

The productive meeting is not about the relationship. It is: what specific items must be present before this moves, agreed by both sides, written down. Ten minutes of that resolves more than an hour of discussing collaboration.

Two details worth adding. Decide what happens when something arrives incomplete (accepted with a flag, or returned), because silent acceptance means it will continue. And check whether the sending team is even able to supply the missing information; sometimes they are being asked for something they do not have, and the fix is upstream of both of them.

The person whose work has quietly declined

Someone reliable for two years has been missing things for about a month. Not dramatically. Enough to notice.

The wrong first move is to treat it as a performance issue, because the most likely explanations are not performance. Something has changed (at home, in their health, in their role, in their relationship with someone at work), and the drop is a symptom.

Ask, in private, without a diagnosis attached. "I've noticed a few things slipping recently, which isn't like you. Is everything all right?" leaves room for an answer you have not anticipated. "Your performance has declined" forecloses it and puts them in a defensive position from which the real cause will not emerge.

Be prepared for the answer to involve health, caring responsibilities, or something else where obligations may apply. Rules on adjustments, leave, confidentiality, and what an employer must do differ by jurisdiction and by employer, so involve HR early rather than agreeing arrangements yourself. Your job in the conversation is to find out and to make it safe to say, not to resolve it on the spot.

The improvement that got worse

A step is removed from a process to speed it up. Cycle time improves immediately. Two months later, rework has risen enough to cancel the gain, and nobody connects the two.

This is the ordinary result of measuring one thing. The removed step was catching something; its absence shows up somewhere else and on a delay.

Two habits prevent it. Watch a pair of measures rather than one (speed alongside rework, volume alongside quality), because most single measures can be improved by degrading their counterpart, which is the ordinary result of a measure becoming a target and is known as Goodhart's law. What a check is for and where defects are cheapest to catch is treated in quality management. And write down, before making the change, what would make you reverse it, with a threshold and a date. After the fact, reversing feels like failure, and the bar rises until the change becomes permanent by default.

Also worth asking before removing any check: what was this for? A control with no remembered purpose is not necessarily pointless; it may be old enough that everyone who understood it has left. Dropping a safeguard because it has not fired recently, and then dropping the next one, is the slow drift described as normalization of deviance.

The meeting nobody can cancel

A recurring meeting, twelve attendees, an hour, weekly. Most participants say privately that it is not useful. It has run for two years.

It persists because canceling requires someone to decide, and nobody owns it. Everyone assumes it matters to someone else.

The intervention is not a discussion about whether it is valuable, that produces a defense of it in the room and complaints outside it. Suspend it for a month and see what actually breaks. Some things will, and those are the meeting's real purpose, usually narrower than the agenda and achievable in fifteen minutes with four people.

The general lesson: give recurring meetings an expiry date so continuing them is a choice rather than an omission. Treating meeting time as a budget that has to be defended, rather than as a default, is part of productivity systems.

The delegation that came back wrong

A manager hands a piece of work to a capable person. It comes back structured differently from how the manager would have done it. The manager reworks it, and concludes that delegation does not work here.

The question to answer honestly is whether the result was wrong or merely different. If different, the rework taught the person that their judgment will be overridden, and next time they will ask before deciding, which returns the decision to the manager and doubles the cost.

Where it genuinely was wrong, the failure was usually at the start: the constraints that mattered were never stated, because they were obvious to the person who has been doing this for years. Say what the boundaries are before the work, and say which kind of delegation it is, decide it yourself, or bring me a recommendation. Ambiguity there is the single most common cause of this situation.

How to use these

Do not pattern-match. Take the reasoning (what question was asked, what was distinguished from what), and apply it to a situation of yours. The shape recurs; the details never do.

For the underlying practices, see the management foundations overview and the day-to-day mechanics in team management.

Common questions

Are worked examples better than principles?

They are easier to remember and easier to over-apply. The value of an example is that it shows the reasoning; the risk is that you match on surface features and import a response that does not fit. Always ask what is different about your case.

What if I have tried these and they did not work?

Then something in your situation differs in a way worth identifying, and that difference is more informative than any further advice. The most common ones are that the person has no real authority to make the change, or that an unaddressed conflict is sitting underneath the stated problem.

Why are there no numbers or named companies here?

Because inventing them would make the examples feel authoritative without making them true. A constructed illustration with the reasoning visible is more useful than an unverifiable anecdote with a logo on it.