How Do You Describe Systems? Lessons on Making Systems Practice Coherent
The process of documenting how organisations actually use systems thinking is worth paying attention to: take a messy, years-long process of organisational transformation and turn it into a story with a shape.
A recent expert review from systems practitioner, Hansika Singh, encouraged us to be more honest about this process and about what we owe the organisations in question and the practitioners who will eventually read the result. While her feedback was brief, it gave us lessons to carry forward.
How do you employ tools well?
Systems tools are ways of thinking that should shape the writing itself. That’s simple in principle, easy to forget in practice.
What we mean by “systems”
When we say “systems,” we don’t mean one single thing. Different practitioners work with different lenses, and the lens you choose changes what you notice, what you ignore, and what counts as evidence:
System dynamics: feedback loops, stocks and flows, how structure creates behaviour over time, often traced through causal loop diagrams.
Socio-technical systems: how technology and social practices shape each other, as in energy, transport, or digital platforms.
Social-ecological systems: people and nature as one coupled system, as in fisheries, forests, or watersheds.
Political-economy systems: who decides, who benefits, and how rules, money, and authority shape outcomes.
Transitions and transformation: how whole regimes shift over long periods, through niches, tipping points, and path dependence.
Many real cases exist at the overlap of these. A system is a purposeful way of drawing a boundary so we can ask better questions. That is the ontology and epistemology underneath the tools: what we treat as real, and how we claim to know it.
Take a regional rice economy as an example. A system-dynamics lens treats stocks, prices, and consumption as real, and claims to know the system through models that trace how a bad monsoon moves through prices months later. A political-economy lens treats trader cartels, subsidy rules, and land ownership as real, and claims to know the system through policy analysis and the lived experience of smallholders. Same food system, but different lenses and evidence. Naming the lens up front tells a reader what they are likely to see, and what they might miss.
A callout box that names a concept after the fact serves a purpose that’s quite different from a narrative that was actually built around tracing loops, levels, and transitions as they happened. For example, labelling a finished story as “reinforcing loop” is different from writing a story whose plot depends on tracing that loop as it unfolds.
Take causal loop diagrams. Treat them not as pictures but as sets of questions. If you bring them in early, they force you to ask: What was actually driving what here? Did a solution in one part of the system create a problem somewhere else? These questions frame the narrative. They decide what you pay attention to in the source material and what connections you trace.
How do you check whether you really used the tool? Imagine removing the framework from the finished piece. If the narrative still stands on its own, you probably used the tool as decoration. If the narrative collapses without it - if the structure, questions, and insights depend on it - then you actually used it.
Let those tools guide your questions from start to finish: What reinforced what? Where did momentum stall? Where did the transition curve instead of running straight? And, when relevant: Who gained or lost influence as the system shifted? The point is to let the tool do the work.
How do you avoid getting trapped?
Hindsight makes everything look connected. Once you know how a story ended, every early decision starts to look like it was aimed there. An abandoned idea seems like a crucial detour. An internal conflict reads like a point that forged the right culture. Nothing feels messy because we crave coherence and a good story gives that to us.
But case studies can end up feeling true without being faithful: a version of events where every thread leads neatly to the ending, and all the loose ends have been snipped off. But, the people living through the real situation were guessing, debating, hedging. They made decisions with incomplete information, and some of those decisions were wrong, or lucky, or both. That uncertainty is the actual story.
This is where systems archetypes become double-edged. They’re useful because they help you spot recurring patterns: reinforcing loops, balancing feedback, delays, tipping points. But they can also make a muddled reality feel orderly. A story that fits an archetype too neatly should raise suspicion, not satisfaction. Ask yourself: did I find this pattern, or did I arrange the evidence to fit it? That is a worthy epistemological line: a pattern you found in the evidence is not the same as a pattern you fitted the evidence to.
To avoid this, go back to the source material and look for friction. Notice what’s missing: whose voices aren’t in the records? Which conflicts were never written down? Where did people disagree? What decisions were genuinely debated? What outcomes surprised the people closest to the action? Those moments make the story honest.
Be suspicious of your own sentences. For instance, you can use quick checks like:
If you write “naturally, this led to…,” pause. Was it natural at the time, or does it only look that way now?
When you write “the team realised they needed to…,” ask: did they realise it, or are you attributing clarity they didn’t yet have?
A good case study will resist the pull of a clean narrative and stay with the genuine uncertainty practitioners felt at the time.
Who is this for and what do they leave with?
A piece of writing without a clear audience is like a speech delivered to an empty room - it might be well-crafted, but it lands nowhere. Who you are writing for determines not just how you say something, but what you say, and why you’re saying it at all.
Fellows on a systems practice program are there to learn the craft. They need to see the flaws, highs, lows, and everything in between, and need reflective questions along with answers. The value for them is in the process: how did you navigate ambiguity? What would you do differently? A fellow’s question might sound like: “What would you do differently if you had to start this again tomorrow?”
Funders assessing impact operate differently. They need evidence of change, clarity on what worked (and what didn’t), and a credible link between intervention and outcome. They’re looking for scalability, return on investment, and risk assessment. For them, the case study is a validation tool that demonstrates effectiveness with metrics and a clear narrative of cause and effect. A funder’s question might sound like: “What specific change can you point to that wouldn’t have happened without this intervention?”
Practitioners in an unrelated field are hunting for transferable principles. They don’t need the full context. Distilled insights are just fine. What’s the core mechanism that could work in their world? What’s the adaptable framework, the portable lesson? A practitioner’s question might sound like: “What’s the smallest version of this you could try in your context next month?”
A case study that tries to serve all audiences equally risks serving none of them well. It’s fine to write more than one version for different audiences. The “who” and “why” should be revisited at every major draft. Writing without continuously asking “who is this for?” might still take you forward, but you’ll rarely arrive where you intended.
How do you talk about power?
Decentralising power is one of the most difficult organisational shifts there is. If you can
show it convincingly, you’ve written something worth reading.
The gap between naming and showing is where the real work lives.
Power didn’t just float from one place to another. For example, a country director no longer approves grants under $10k; that authority moved to regional leads, along with the budget line and sign-off rights. What happened there? Was it a new governance structure? A shift in budget authority? A change in who gets to speak in which meetings? A redesign of decision-making protocols? Who held it before and who holds it now? The mechanism is the vehicle that must be named.
Power shifts are contested, negotiated, sometimes fought over. Where did people push back? Where did the old power holders try to retain control indirectly? Where did the new power holders struggle to exercise authority they had been given on paper but not in practice? These moments of friction are evidence that something real was happening. A smooth transition is often a sign that nothing actually changed.
It is easy to write a sentence claiming decentralised power. It is much harder, and much more valuable, to show the moment a decision that used to sit with one actor came to sit with another, and what that cost the people who let it go.
So, how does one begin?
For a case study on systems practice, start with more discipline right at the start, and before you draft, decide:
Which system lens are you using (system dynamics, socio-technical, social-ecological, political-economy, transitions)?
Who is your primary audience (fellows, funders, practitioners)?
What would count as evidence that power actually moved?
Writing already has some rigour built in. We just need a bit more nuance and conscious effort woven into every step: tools used as instruments of inquiry rather than illustration, a working suspicion of our own neat narratives, a clear-eyed answer to who we are actually writing for, and evidence rather than assertion when we claim that power has moved.
Make it an iterative process and engage with practitioners and their thinking as much as possible. How you write about systems practice itself should undergo a systems process: iterative, tested against more than one perspective, and open to revision.
Try making a Causal Loop yourself
Take a case study or write-up you are working on now. Before you draft another line, map the loop it describes. What was actually driving what? Where did a fix in one part of the system create a problem somewhere else?
The worksheet below is a Current and Possible System Change Map. One half asks you to trace the loop as it already runs, and where your intervention enters it. The other asks what the loop might look like afterwards, and which link you expect to break.
If something in the worksheet raises a question, or if you want to think through your own case study with us, write to us at info@centreforsystemspractice.org. We would love to hear what you are working on.
The Centre for Systems Practice is a SELCO Foundation initiative. If this piece was useful, our newsletter goes out every month with one piece of practical thinking from the field.
Comments