Business Dynamics by John D. Sterman

I finished this book in December 2025. I recommend this book 8/10.

Why you should read this book:

This is the bible on system thinking. The author is a professor at MIT, and this is the book that is used there. The book explains the basics to a new student, all the way to how to use calculus to math out results and outcomes that only a professional would need.

Get your copy here.

🚀 The book in three sentences

1. The System Thinking Bible

2. How to go from basic causal diagrams to calculus

3. Systems thinking is a skill you need to practice

📝 My notes and thoughts

• P14. "Feedback" has come to serve as a euphemism for criticizing others, as in "the boss gave me feedback on my presentation." This use of feedback is not what we mean in system dynamics. Further, "positive feedback" does not mean "praise," and "negative feedback" does not mean "criticism." Positive feedback denotes as self-reinforcing process, and negative feedback denotes a self-correcting one. Either type of loop can be good or bad, depending on which way it is operating and, of course, on your values. Reserve the terms positive and negative feedback for self-reinforcing and self-correcting processes, and avoid describing the criticism you give or receive as feedback. Telling someone your opinion does not constitute feedback unless they act on your suggestions and thus lead you to revise your view. Though there are only two types of feedback loops, models may easily contain thousands of loops, of both types, coupled to one another with multiple time delays, nonlinearities, and accumulations. The dynamics of all systems arise from the interactions of these networks of feedback.

• P61. The modeling team assembled the full model by replicating the generic project phase module to represent each phase of each ship in each program. The major activities (system design, detailed design, procurement, construction, etc.) were disaggregated further where necessary; for example, construction was divided into several major activities (e.g., hull, piping, electrical, etc.), and the construction workforce was disaggregated by major crafts (e.g., steelworkers, electricians, etc.). Construction progress for each ship was represented separately. Each instance of the generic phase module was calibrated to the particular activity it represented. The individual activities, phases, and programs were linked by additional structure representing overall program management, progress monitoring, scheduling, hiring, resource allocation, and so on. A model of this scope could never be built, calibrated, maintained, or understood if such a modular architecture were not used. Meaning, you need to break down your model into smaller chunks.

• P79. Principles for successful use of system dynamics:

  • Develop a model to solve a particular problem, not to model the system. A model must have a clear purpose and that purpose must be solved the problem of concern to the client. Modelers must exclude all factors not relevant to the problem to ensure the project scope is feasible and the results are timely. The goal is to improve the performance of the system as defined by the client. Focus on results.

  • Modeling should be integrated into a project from the beginning. The value of the modeling process begins early on, in the problem definition phase. The modeling process helps focus diagnosis on the structure of the system rather than blaming problems on the people making decisions in that structure.

  • Be skeptical about the value of modeling and force the "why do we need it" discussion at the start of the project. There are many problems for which system dynamics is not useful. Carefully consider whether system dynamics is the right technique for the problem. Modelers should welcome difficult questions from the clients about how the process works and how it might help them with their problem. The earlier these issues are discussed, the better.

  • System dynamics does not stand alone. Use other tools and methods as appropriate. Most modeling projects are part of a larger effort involving traditional strategic and operational analysis, including benchmarking, statistical work, market research, etc. Effective modeling rests on a strong base of data and understanding of the issues. Modeling works best as a complement to other tools, not as a substitute.

  • Focus on implementation from the start of the project. Implementation must start on the first day of the project. Constantly ask, how will the model help the client make decisions? Use the model to set priorities and determine the sequence of policy implementation. Use the model to answer questions: How do we get there from here? Carefully consider the real-world issues involved in pulling various policy levers. Quantify the full range of costs and benefits of policies, not only those already reported by existing accounting systems.

  • Modeling works best as an iterative process of joint inquiry between client and consultant. Modeling is a process of discovery. The goal is to reach a new understanding of how the problem arises and then use that understanding to design high-leverage policies for improvement. Modeling should not be used as a tool for advocacy. Don't build a client's prior opinion about what should be done into a model. Use workshops where the clients can test the model themselves, in real time.

  • Avoid black box modeling. Models built out of sight of the client will never lead to change in deeply held mental models and therefore will not change client behavior. Involve the clients as early and as deeply as possible. Show them the model. Encourage them to suggest and run their own tests and to criticize the model. Work with them to resolve their criticisms to their satisfaction.

  • Validation is a continuous process of testing and building confidence in the model. Models are not validated after they are completed, nor by any one test, such as their ability to fit historical data. Clients (and modelers) build confidence in the utility of a model gradually, by constantly confronting the model with data and expert opinion—their own and others'. Through this process, both model and expert opinions will change and deepen. Seek out opportunities to challenge the model's ability to replicate a diverse range of historical experiences.

  • Get a preliminary model working as soon as possible. Add detail only as necessary. Develop a working simulation model as soon as possible. Don't try to develop a comprehensive conceptual model prior to the development of a simulation model. Conceptual models are only hypotheses and must be tested. Formalization and simulation often uncover flaws in conceptual maps and lead to improved understanding. The results of simulation experiments inform conceptual understanding and help build confidence in the results. Early results provide immediate value to clients and justify continued investment of their time.

  • A broad model boundary is more important than a great deal of detail. Models must strike a balance between a useful, operational representation of the structures and policy levers available to the clients while capturing the feedback generally unaccounted for in their mental models. In general, the dynamics of a system emerge from the interactions of the components in the system—capturing those feedbacks is more important than a lot of detail in representing the components themselves.

  • Use expert modelers, not novices. While the software available for modeling is easily mastered by a high school student or CEO, modeling is not computer programming. You cannot develop a qualitative diagram and then hand it off to a programmer for coding into a simulation model. Modeling requires a disciplined approach and understanding of business, skills developed through study and experience. Get the expert assistance you need. Use the project as an opportunity to develop the skills of others on the team and in the client organization.

  • Implementation does not end with a single project. In all three cases, the modeling work continued to have an impact long after the initial project was over. Models and management flight simulators were applied to similar issues in other settings. The modelers developed expertise they applied to related problems, and clients moved into new positions and new organizations, taking the insights they gained and, sometimes, a new way of thinking, with them. Implementation is a long-term process of personal, organizational, and social change.

• P86. Steps of the modeling process:

  • Problem articulation (boundary selection)

    • Theme selection: What is the problem? Why is it a problem?

    • Key variables: What are the key variables and concepts we must consider?

    • Time horizon: How far in the future should we consider? How far back in the past lie the roots of the problem?

    • Dynamic problem definition (reference modes): What is the historical behavior of the key concepts and variables? What might their behavior be in the future?

  • Formation of a dynamic hypothesis

    • Initial hypothesis generation: What are current theories of the problematic behavior?

    • Endogenous focus: Formulate a dynamic hypothesis that explains the dynamics as endogenous consequences of the feedback structure.

    • Mapping: Develop maps of causal structure based on initial hypothesis, key variables, reference modes, and other available data, using tools such as:

      • Model boundary diagrams

      • Subsystem diagrams

      • Casual loop diagrams

      • Stock and flow maps

      • Policy structure diagrams

      • Other facilitation tools

    • Formulation of the simulation model

      • Specification of structure, decision rules

      • Estimation of parameters, behavioral relationships, and initial conditions

      • Test of consistency with the purpose and boundary

    • Testing

      • Comparison to reference modes: Does the model reproduce the problem behavior adequately for your purpose?

      • Robustness under extreme conditions: Does the model behave realistically when stressed by extreme conditions?

      • Sensitivity: How does the model behave given uncertainty in parameters, initial conditions, model boundary, and aggregation?

    • Policy design and evaluation

      • Scenario specification: "What environmental conditions might arise?

      • Policy design: What new decision rules, strategies, and structures might be tried in the real world? How can they be represented in the model?

      • "What if ..." analysis: What are the effects of the policies?

      • Sensitivity analysis: How robust are the policy recommendations under different scenarios and given uncertainties?

      • Interactions of policies: Do the policies interact? Are there synergies or compensatory responses?

  • P153. Tips for casual loop diagram layout. To maximize the clarity and impact of your causal diagram, you should follow some basic principles of graphic design:

    • Use curved lines for information feedback. Curved lines help the reader visualize the feedback loops.

    • Make important loops follow circular or oval paths.

    • Organize your diagrams to minimize crossed lines.

    • Don't put circles, hexagons, or other symbols around the variables in casual diagrams. Symbols without meaning are "chart junk" and serve only to clutter and distract. An exception: You will often need to make the stock and flow structure of a system explicit in your diagrams. In these cases, the rectangles and valves around the variables tell the reader which are stocks and which are flows—they convey important information.

    • Iterate. Since you often won't know what all the variables and loops will be when you start, you will have to redraw your diagrams, often many times, to find the best layout.

  • P159. Great example of a causal diagram for student workload.

  • P180. When developing a causal map, it is helpful to consider the units, which can often be a great aid in clarifying the constructs in your diagram. Having consistent units is often a great aid to clear thinking about the definitions of and relationships among the variables. Specifying units and checking for dimensional consistency is useful even when your model is purely conceptual, and you do not intend to develop a formal simulation. Travel time would be measured in minutes per trip (for the average trip in the region). Highway Capacity and Traffic Volume are measured in vehicle-miles per day (a vehicle mile is one mile traveled by one vehicle).

  • P190. Casual diagrams are a powerful tool to map the feedback structure of complex systems. Casual diagrams can be helpful to you in the early phases of a project, when you need to work with the client team to elicit and capture their mental models. They are helpful in presenting the results of your modeling work in a nontechnical fashion. To be effective, you should follow the rules for causal diagrams, including the selection of variable names, layout, and assignment of link and loop polarities. It is best to build up diagrams in steps: resist the urge to create a single, comprehensive diagram. As in learning to read music, practice is everything. Develop your skills in mapping the feedback structure of systems by sketching causal diagrams to capture the feedback you recognize as you read the newspaper or the great work of literature.

  • P191. Casual loop diagrams are wonderfully useful in many situations. They are well-suited to represent interdependencies and feedback processes. They are used effectively at the start of the modeling project to capture mental models—both those of a client group and your own. They are also used to communicate the results of a completed modeling effort. However, causal loop diagrams suffer from a number of limitations and can easily be abused. Some of these are discussed in Chapter 5. One of the most important limitations of causal diagrams is their inability to capture the stock and flow structure of systems. Stock and flows, along with feedback, are the two central concepts of dynamic system theory. Stocks are accumulations. They characterize the state of the system and generate the information upon which decisions and actions are based. Stocks give systems inertia and provide them with memory. Stocks create delays by accumulating the difference between the inflow to a process and its outflow. By decoupling rates of flow, stocks are the source of disequilibrium dynamics in systems. Stocks and flows are familiar to all of us. The inventory of a manufacturing firm is the stock of products in its warehouses. The number of people employed by a business is a stock. The balance in your checking account is a stock. Stocks are altered by inflows and outflows. A firm's inventory is increased by the flow of production and decreased by the flow of shipments (and possibly other outflows due to spoilage or shrinkage). The workforce increases via the hiring rate and decreases via the rate of quits, layoffs, and retirements. Your bank balance increases with deposits and decreases as you spend. Yet despite everyday experience of stock and flows, all too often people fail to distinguish clearly between them.

  • P198. How can you tell which concepts are stocks and which are flows? Stocks are quantities of material or other accumulations. They are the states of the system. The flows are the rates at which these system states change. Imagine a river flowing into a reservoir. The quantity of water in the reservoir is a stock (measured in, say, cubic meters). If you drew an imaginary line across the point where the river enters the reservoir, the flow is the rate at which water passes the line—the rate of flow in cubic meters per second.

  • P199. Stocks characterize the state of the system. To identify key stocks in a system, imagine freezing the scene with a snapshot. Stocks would be the things you could count or measure in the picture, including psychological states and other intangible variables. You can estimate the stock of water in a reservoir from a set of satellite images and topographic data, but you cannot determine whether the water level is rising or falling. Your bank statement tells you how much money is in your account, but not the rate at which you are spending it now. If time stopped, it would be possible to determine how much inventory a company has or the price of material, but not the net rate of change in inventory or the rate of inflation in materials prices. The snapshot test also applies to less tangible stocks. The plant manager's expectation of the customer order rate at any instant or perception of the size of inventory are stocks, even though they are mental and not physical stocks. A snapshot of people's mental states, however, does not indicate how fast they are revising their beliefs.

  • P206. Stock only changes from the flow rate; therefore, auxiliary variables don't point back to the stock but to the flow rate.