# Malik Management Decisions > Work through a management decision as Fredmund Malik's "Führen Leisten Leben" (Managing Performing Living) prescribes — define the real problem, fix boundary conditions, force out alternatives incl. "do nothing", weigh risks, decide, build implementation and follow-up into the decision — check it against Malik's six principles, five tasks and seven tools of effective management, and counter-check where the model misleads. Use whenever a user must make, prepare, defend or review a management or leadership decision: hiring, restructuring, budget and priorities, make-or-buy, vendor choices, stopping a project, delegating, organising a team, conflicts, objectives, or any "should we do X?" from a leadership position. Trigger without the word "Malik" — "I need to decide", "help me think this through", "I'm torn between", "Entscheidungsvorlage", "Führungsentscheidung", "prepare a decision for the board/GF", "we keep going back and forth", or a request for a decision memo. Also for why decisions keep not sticking. - Skill: `liuiu030/malik-management-decisions` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add liuiu030/malik-management-decisions` - Raw SKILL.md: https://api.skillmd.com/api/skills/liuiu030/malik-management-decisions/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: liuiu030 (https://skillmd.com/u/liuiu030) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/liuiu030/malik-management-decisions --- # Management decisions after Fredmund Malik Fredmund Malik's central claim in *Führen Leisten Leben* is that management is a profession, and like every profession it can be learned and practised with craftsmanship. It rests on a small number of principles, a defined set of tasks, and a handful of tools. Effectiveness — getting the right things done — is not a personality trait; it is the result of applying these consistently. Deciding is one of the five tasks of that profession, and it is the one most people do badly, because they treat the moment of choice as the decision. Malik's view: the choice is one step in a process, and the quality of the decision is made before and after that step — in defining the problem, in fixing what a solution must satisfy, and in building implementation and follow-up into the decision itself. A decision that has not been implemented is not a decision; it is a good intention. This skill walks a user through that process and checks the outcome against the rest of Malik's model. It is deliberately demanding: the point is to produce a decision the user can defend and execute, not to validate what they already wanted to do. ## When someone brings a decision Start by establishing what kind of decision this is and where the user stands. Read `references/decision-process.md` before doing the work — it carries the detail for each step, the risk typology and the typical traps. Then: 1. **Restate the decision as you understand it** and ask the one or two questions whose answers would change the outcome (who owns the decision, what deadline is real, what has already been tried). Do not run a questionnaire; a manager wants progress, not an intake form. If the user is clearly pressed for time, state your assumptions and go. 2. **Work through the seven steps** below. The value is in the written discipline — a step skipped is a hole the user will fall into later. 3. **Run the effectiveness check** (principles, tasks, tools) against the resulting decision. 4. **Deliver one document, not two.** Write the analysis *as* the decision memo (format in `references/decision-memo-template.md`), in the user's language, in plain text so it can be pasted or sent as-is. Do not narrate the seven steps in prose and then repeat them in the memo — the memo is the answer. Add a short commentary before it only for things the memo cannot carry: where you pushed back on the framing, and what would change the recommendation. Match the depth to the decision. A consequential, hard-to-reverse decision (a hire, a contract, a reorganisation) gets the full memo. A small or urgent one gets the quick variant. A question like "why do our decisions keep not sticking?" gets the *review* format and a single thing to fix first — not a fresh seven-step analysis wrapped around it. Facts you do not have (fees, notice periods, salaries, dates) stay out of the memo as numbers. State them as assumptions in the open-questions section, or write the condition in words ("if the notice period makes the real deadline earlier than November …"). Invented figures look like analysis and get quoted. ## The seven steps ### 1. Define the problem precisely Most bad decisions are good answers to the wrong question. Before anything else: what is this actually about? Malik, following Drucker, insists on classifying the problem first, because the classification determines the kind of decision: - **Generic** — a recurring situation that wants a rule or a policy, not a one-off decision. Most "urgent individual cases" are really generic. Deciding them case by case is a symptom of a missing rule. - **A generic problem that appears new here** — new to this organisation, but well known elsewhere. Look for the existing principle before inventing one. - **Truly unique** — rare. Treat as such only after the first two have been ruled out. - **The first appearance of a new generic problem** — the most dangerous type, because it looks unique and gets an ad-hoc answer when it needs a new rule. Write the problem in one sentence, name its type, and state what would happen if nothing were decided. If the user's framing is already an alternative in disguise ("should we hire a second designer?"), pull it back to the problem ("we cannot deliver the campaign volume the plan requires"). ### 2. Fix the boundary conditions What must the decision achieve, at minimum, to count as right? These are the specifications: the goals it must reach, the constraints it must respect, the things it must not damage. Malik calls this the most important and most neglected step. A decision that does not satisfy its own boundary conditions is wrong even if it feels clever, and boundary conditions are what let you recognise later that a decision has become obsolete because the conditions changed. State them as a short, testable list. Separate "must" from "nice to have". Ask the user which of these they would drop if forced — that reveals the real ones. ### 3. Search for alternatives — always, and include "do nothing" There is no decision with only one option. If the user arrives with a single option, the job is to generate at least two more that also satisfy the boundary conditions, and to add explicitly: *what happens if we do nothing?* "Do nothing" is a real alternative with real consequences; naming it prevents activism and sometimes turns out to be the right answer. Do not pad the list with straw men; every alternative should be one a serious colleague might defend. ### 4. Analyse risks and consequences of each alternative For every alternative, think through what follows — for the organisation, the people, the customers, the finances, the user's own credibility — and classify the risks: - risks we can afford to take; - risks we cannot afford to take, whatever the upside; - risks we cannot afford *not* to take. Then ask Malik's blunt question for each alternative: *if this turns out to be wrong, what do we lose, and can we reverse it?* Reversibility is often more decisive than expected value. Also ask what the decision costs in attention and organisational capacity, not just money. This is also where the six principles earn their keep as a comparison tool, not just as a final check: for each serious alternative, ask which result it produces, whether it serves the whole or a unit, whether it adds or removes a priority, whether it builds on existing strengths, and whether it keeps commitments. Alternatives that survive on upside but fail two or three principles usually fail in execution. ### 5. Decide The moment of choice. Malik's guidance here is about courage and honesty rather than technique: prefer the alternative that satisfies the boundary conditions and whose downside you can live with, over the one that looks best on the upside. Consensus is not required and is often a warning sign — a decision nobody disagrees with has usually not been examined. If no one has argued against the preferred option, provoke the disagreement before deciding (the Sloan practice: "then let's postpone until we have found something to disagree about"). And do not confuse deciding with deciding quickly; speed at this step is rarely the constraint. State the decision in one sentence, with the reason it beat the runner-up. ### 6. Build implementation into the decision Not a separate phase — part of the decision. Specify: who must know about this decision; who has to do what, by when; what resources move; what stops. Then assign each action to a named person and check whether the people concerned are actually able and willing to carry it out — a decision that ignores the capabilities of the people who must execute it will not be executed. If the answers are vague, the decision is not finished. ### 7. Build follow-up into the decision Decide now how and when you will find out whether the decision is working: the milestone, the indicator, the date, the person. Malik's advice is to *go and see for oneself* rather than rely on reports, and to fix in advance what result would trigger a revision. A decision is not final; it is the current best answer under known conditions, and the follow-up is what tells you when the conditions have changed. ## The effectiveness check Once the decision stands, hold it against Malik's model of effective management. The full detail is in `references/principles.md`, `references/tasks.md` and `references/tools.md`; the questions below are the short form. **Principles** — does the decision: - serve **results**, not activity or good intentions? - make a **contribution to the whole**, not just to the user's own unit? - **concentrate on few things** — or does it add another priority without removing one? - **build on strengths** (of the people, the organisation, the user) rather than trying to fix weaknesses? - rely on and reinforce **trust** — robust, predictable, honest? - come from **constructive, positive thinking** (what can we do with what we have?) rather than from grievance or fear? **Tasks** — which of the five management tasks does this decision touch, and are they handled? Setting objectives, organising, deciding, controlling (monitoring), developing people. A decision that changes objectives without changing the organisation, or reorganises without saying how it will be monitored, is incomplete. **Tools** — which tool carries the decision into practice? Meetings, written reports, job design and assignment control, personal working method, budget, performance appraisal, systematic waste disposal (what do we stop doing?). Name the tool and the concrete next use of it. ## The counter-check: where the model can mislead Malik's own foundation is cybernetic: organisations are complex systems that can be steered but not controlled in detail, and he is scathing about management that mistakes rituals for interventions. A skill that applies his process mechanically would violate his premise. So before the memo is final, run these questions against the decision and record at least one objection and how it was handled: - **Steerability**: does the decision assume the organisation will behave like a machine — that a rule, a structure or an announcement will produce the intended behaviour? In a complex system the honest answer is often "we will find out at the first checkpoint", which is why follow-up is part of the decision and not an afterthought. - **Intervention or ritual**: would anything observable be different in four weeks if this decision were taken versus not? If not, it is a symbolic act — Malik's "wirkungsloses Ritual" — and should either be dropped or turned into something that changes who does what. - **Complexity of the problem**: for a simple, well-understood problem, a rule and control are right. For a problem that is still being understood, a reversible pilot and short feedback loops beat a definitive decision, however well-structured. - **Governance reality**: Malik's model is normative — it favours the long-term viability of the organisation over short-term financial signals. Where owners or boards measure differently, name the tension rather than pretending the decision will be judged by Malik's standard. - **The model is not the manager**: the process produces a defensible decision, not a right one. Courage, judgement and the willingness to carry consequences are the user's, and the memo should leave room for them. Full notes on the model's limits and the main critiques are in `references/limits.md`. ## How to behave as a sparring partner Malik's book is a manual for practitioners, not a theory, and the skill should feel the same way: concrete, plain, unimpressed by fashion. Push back when the user - presents an alternative as the problem; - has only one option; - has no boundary conditions or ones so vague nothing could fail them; - wants consensus before deciding; - has no named owner or date for implementation; - wants to decide a generic problem case by case; - is about to add a priority without dropping one. Do it plainly and kindly, in the user's language. If the user writes in German, keep Malik's terms as he uses them (Wirksamkeit, Grundsätze, Aufgaben, Werkzeuge, Randbedingungen, systematische Müllabfuhr). Do not moralise, do not pad, and never invent facts about the user's organisation — mark what you do not know as an assumption or an open question in the memo. ## References - `references/decision-process.md` — the seven steps in detail, Drucker's problem typology, risk classes, participation and dissent, common traps. Read first. - `references/principles.md` — the six principles of effective management with test questions. - `references/tasks.md` — the five tasks of effective management and what "done well" looks like for each. - `references/tools.md` — the seven tools, with what each is for and how it typically goes wrong. - `references/decision-memo-template.md` — output format for the final decision memo and a shorter "quick decision" variant. - `references/limits.md` — where the model stops, the main critiques, and how the counter-check is used.