As scientific software ecosystems grow in complexity, storytelling becomes a critical tool for alignment, adoption, and long-term impact. This article highlights how intentional narrative practices can help communicate purpose, guide collaboration, and drive systems-level change. While intended for a broad audience, the key points of the article are directly applicable to scientific software.
| Resource information | Details |
|---|---|
| Article title | Narrative as Infrastructure: How Storytelling Shapes Systems Change |
| Authors | Joseph Wernau |
| Focus | Narrative strategy, systems thinking, scientific communication |
In the article Storytelling for Systems Change, the authors argue that storytelling is not simply a communication technique. It is a core mechanism for shaping complex systems. In environments where multiple stakeholders, technologies, and goals intersect, narrative provides coherence, direction, and shared understanding.
For scientists developing software as part of discovery workflows, this insight is particularly relevant. Scientific software is rarely just code. It is embedded in research programs, collaborations, funding structures, and evolving user communities. Without effective storytelling, even technically excellent software can struggle to gain adoption or sustain impact.
A central premise of the article is that systems change requires shifting mental models, not just building new tools. Stories are the primary way humans, and increasingly organizations, make sense of complexity. They define what matters, who is involved, and what success looks like. In scientific-software contexts, this translates into framing not just what the software does, but why it exists and how it fits into a broader ecosystem.
The author emphasizes that effective storytelling operates across multiple layers:
-
Individual narratives: Why a researcher or developer cares about a problem
-
Project narratives: What a software effort aims to achieve and how it evolves
-
Ecosystem narratives: How multiple tools, teams, and institutions interact to produce impact
For scientific software developers, this suggests a shift from isolated technical descriptions toward multi-level narratives that connect code to scientific and societal outcomes.
Another key concept is that stories should be intentional and structured, not accidental byproducts of documentation. The article highlights several principles that translate well into scientific software practice:
-
Clarity of purpose: Clearly articulate the problem being addressed and why it matters
-
Defined actors: Identify the users, developers, stakeholders, and beneficiaries
-
Causal pathways: Explain how actions (software, workflows, data) lead to outcomes
-
Adaptability: Allow the story to evolve as the system and understanding change
In practice, this means that README files, tutorials, and project descriptions should not merely list features, but should tell a coherent story about usage, value, and evolution.
For teams working in HPC, AI, and scientific computing ecosystems, storytelling plays an additional role: it helps coordinate across distributed, interdisciplinary efforts. For projects that I am involved in, like E4S and CASS, initiatives depend on shared understanding across institutions and domains. Narrative becomes a lightweight but powerful form of infrastructure—aligning expectations without requiring rigid control mechanisms.
The article also warns against overly simplistic or static narratives. Systems change requires acknowledging uncertainty, competing perspectives, and evolving conditions. For scientific software teams, this translates into:
- Avoiding overly rigid “one-size-fits-all” usage narratives
- Supporting multiple valid workflows and entry points
- Continuously updating documentation and messaging as capabilities evolve
Importantly, storytelling is not just outward-facing. Internal narratives shape how teams prioritize work, evaluate success, and make design decisions. A well-articulated story can serve as a decision framework, guiding trade-offs in architecture, usability, and performance.
For scientists who may not see themselves as storytellers, the key takeaway is pragmatic: if you do not define the story of your software, others will, and often define it incorrectly. Investing in narrative clarity reduces onboarding friction, improves collaboration, and increases the likelihood of sustained impact.
In summary, storytelling should be viewed as a first-class practice in scientific software development. It enables:
- Clear communication of purpose and value
- Alignment across distributed teams and stakeholders
- Improved onboarding and user experience
- More effective use of AI-driven tools and workflows
- Greater long-term sustainability and impact
For scientific software practitioners aiming to influence complex systems, storytelling is not optional. It is foundational.
This curated contribution should be useful for scientists, research software engineers, and technical leaders seeking to improve the impact and sustainability of their software through better communication and systems-level thinking.
