Reference Mode: an agreed-upon Systemic Behavior

Last year, while developing a dedicated systems thinking workshop, I took the opportunity to reflect on my early experiences in teaching and applying systems thinking. In this article, I will share what may be the most important insight from that reflection: whether system modeling requires a reference and what kind of reference is required.

With reference models

In my Certified LeSS Practitioner (CLP) course, I began with a brief introduction to Causal Loop Diagram (CLD), a core systems thinking tool. Throughout the training, we applied CLD to model several key topics in large-scale product development. One such topic was the impact of “number of backlogs” on an organization: specifically, how it influenced both customer value delivery and global adaptiveness. To guide the modeling process, I used a series of questions such as “How did the number of backlogs affect global adaptiveness?”, “How could we reduce the number of backlogs?”, “What prevented us from having fewer backlogs?”, etc.

This approach proved effective for participants in several ways: 1) It allowed them to reason through the topic independently, leading to deeper understanding and stronger buy-in. 2) Their conclusions would naturally align with LeSS principles and designs. For instance, they would recognize that fewer backlogs improved adaptability; they would identify constraints such as a Product Owner’s prioritization skills or a team’s ability to learn across domains.

In this setting, I actually used reference models that reflected LeSS principles and designs as a kind of “correct answer.” I guided participants toward these models through discussion. If the group did not arrive at certain insights on their own, I would share the reasoning behind LeSS. While this served as a useful teaching aid, these reference models did not always match every participant’s real-world experience. In such cases, rather than imposing my view, I would together with them explore different mental models.

Without reference models

Beyond the CLP course, I have also taught and practiced systems thinking in the systems thinking dojo and in real work. In those settings, we did not have reference models. While I could have developed reference models for dojo sessions, I chose not to, aiming to keep the experience as close as possible to real work, where ready-made reference models are rarely available.

In the systems thinking dojos, we would select a topic or problem, such as continuous integration or how to integrate more frequently, and then I would design a set of questions to guide the modeling process. This approach worked well, particularly in strengthening participants' reasoning skills. However, compared to the CLP sessions, the outcomes were usually less conclusive. During these dojos, comments like “I’ve observed something different happen” or “My reasoning is different” were common. We often incorporated conflicting perspectives into the same model. In the end, participants tended to take away whatever insights resonated with them, which left the feeling that there was no clear way to validate the model.

In real work situations, modeling appeared more effective because teams shared context and typically had more clearly defined problems. Still, when working in groups, varying experiences and viewpoints inevitably surfaced. Multiple models explaining the problem might all seem plausible, yet there was often no structured way to validate them. Typically, we would keep all perspectives and rely on some form of voting to decide on next steps.

Although system modeling helped us articulate our reasoning and understand others’, I felt that something was missing.

Reference Mode

While preparing for the workshop, I revisited fundamental systems thinking concepts by studying classical texts and educational videos. During this review, I realized what had been missing in my own teaching and practice: systemic behavior.

a Behavior Over Time (BOT) graph

Systemic behavior refers to the overall pattern of events over time, typically represented by a Behavior Over Time (BOT) graph. Systemic structure consists of the system’s interlocking stocks, flows, and feedback loops, usually modeled with CLD or Stock-and-Flow Diagram (SFD). Then, “structure drives behavior.” Systems thinking requires continuously moving between structure and behavior. What went wrong was that we had been exploring structure without consistently checking it against behavior. Without explicitly agreeing on the specific behavior pattern we were trying to understand, any structure could be proposed; there was no grounding for our modeling. We need to agree on the systemic behavior before exploring systemic structure.

How do we do this in practice? In a private setting, you simply examine reality to sketch a BOT. In a public setting, where everyone may have different realities, you begin by agreeing on the to-be-analyzed reality through an explicit BOT. This BOT becomes your reference; a model (whether CLD or computer model) is considered plausible only if it can reproduce this reference pattern. Interestingly, Donella Meadows used the term “reference mode” in her early lectures, which is also a standard term in system dynamics referring to the behavior pattern that a model must match to be considered valid.

In fact, two kinds of differences can arise: different systemic behaviors and different systemic structures. The first should be resolved by examining reality; establishing an agreed-upon reference mode sets the stage for all further modeling. The second may remain, as multiple structures can produce the same behavior. Structures are mental interpretations after all. My approach is being pragmatic: we can experiment to see which structure leads to more effective actions.

So, we do not need a reference model (a predefined systemic structure or CLD), but we do need a reference mode (an agreed-upon systemic behavior or BOT). I have incorporated this missing piece into my systems thinking workshop and plan to apply it in future dojos and real work. The focus on establishing reference mode has already led to new insights that I may write about later.

Read more

Microservices architecture

Microservices architecture

หลายปีที่ผมต่อสู้กับปัญหายอดนิยมในวงการซอฟต์แวร์ นั่นคือป้องกันไม่ให้ซอฟต์แวร์ไปถึงจุดที่เกินเยียวยาจนไม่สามารถดูแลต่อไปได้แล้ว ต้องทุบทิ้งแล้วทำใหม่ ซึ่งจังหวะนั้นมันยากสำหรับองค์กรมาก ๆ ไม่มีใครอยากหยุดเพิ่มฟีเจอร์เป็นเวลานาน ๆ

By Chokchai
ความหมายของชีวิต

ความหมายของชีวิต

ตอนผมไปเรียน Organizational Development ที่สิงคโปร์ ผมได้เรียนรู้ว่าคนเราตามหาของหลัก ๆ 4 อย่างในชีวิต และการได้รู้ว่าผมตามหาอะไร มันทำให้ผมเห็นตัวเองชัดขึ้นมากเลย เดี๋ยวนี้ผมเลยมักจะเล่นเกมชวนเพื่อน ๆ ผมให้ลองเลือกแค่ 2 ใน 4 อย่างนี้ ผมพบว่าตัวเลือกที่เพื

By Chokchai
Keycloak

Keycloak

ช่วงที่ผ่านมา ผมลองปรับระบบหนึ่งของลูกค้าจากที่ใช้ authentication ธรรมดา ให้ไปต่อกับ ระบบ keycloak แทน keycloak มีฟีเจอร์ช่วยจัดการ authentication flow ให้กับ application เราได้ โดยที่เราไม่ต้องแก้โค้ดเราเลย แค่ให้ frontend เรา redirect ไป หน้า login ของ keycloak

By Chokchai
Vibe Coding

Vibe Coding

สร้างผลงานในจังหวะของ AI Web Summit 2025 — Lisbon | Matt Wolfe, Replit ลองจินตนาการดูว่า… การเขียนโค้ดของคุณไม่ได้เหมือนกับพิมพ์คำสั่งในเทอร์มินัล แต่เหมือนกับ เล่นดนตรีร่วมกับวง — มีจังหวะ มีความรู้สึก และมีคู่หูที่เข้

By Chokchai