diff --git a/README.md b/README.md
index 1e41e6862..3663ecee9 100644
--- a/README.md
+++ b/README.md
@@ -94,6 +94,7 @@ Our mission
 * [Internal Developer Platform](/patterns/1-initial/internal-developer-platform.md) - *As InnerSource adoption increases throughout an organisation, it is not unusual that project teams start to face inefficiencies in scaling their efforts due to fragmented tooling, environments, and workflows. An Internal Developer Platform (IDP) provides a way to tackle this type of challenges through a centralized, self-service system that standardizes development environments and integrates tools to enhance consistency, collaboration, and developer productivity.*
 * [Document Architecture Decisions](/patterns/1-initial/document-architecture-decisions.md) - *InnerSource contributors often face challenges in grasping the system's design rationale, which can result in misalignment between maintainers, contributors, and stakeholders — potentially discouraging participation. To enhance decision-making and transparency, we recommend capturing architecture decisions and their consequences in a lightweight, accessible format to streamline onboarding, clarify decisions, and support long-term project sustainability.*
 * [InnerSource Incentives and Disincentives](/patterns/1-initial/incentives-and-disincentives.md) - *Lack of awareness for incentives as well well as disincentives for InnerSource contribution decrease the chances of an InnerSource project receiving contributions; this is addressed by sharing a comprehensive list of potential incentives and disincentives.
+* [Walk the InnerSource talk](/patterns/1-initial/walk-the-innersource-talk.md) - *Teams across the organization are encouraged to adopt InnerSource principles such as working openly, sharing code, and collaborating transparently. But, if the team behind the InnerSource initiative doesn’t follow these practices themselves, it undermines credibility and adoption. Therefore, this team should lead by example: documenting their decisions as code, working in the open, and treating their work as an InnerSource project to build trust and show others how it’s done.*
 
 <!--
 NOTE: The 'Initial' Patterns below don't have a Patlet yet, which is essential for readers to quickly browse our patterns.
diff --git a/patterns/1-initial/walk-the-innersource-talk.md b/patterns/1-initial/walk-the-innersource-talk.md
new file mode 100644
index 000000000..f4aff198f
--- /dev/null
+++ b/patterns/1-initial/walk-the-innersource-talk.md
@@ -0,0 +1,164 @@
+## Title
+
+Walk the InnerSource talk
+
+## Patlet
+
+Teams across the organization are encouraged to adopt InnerSource principles such as working openly, sharing code, and
+collaborating transparently. But, if the team behind the InnerSource initiative doesn’t follow these practices
+themselves, it undermines credibility and adoption. Therefore, this team should lead by example: documenting their
+decisions as code, working in the open, and treating their work as an InnerSource project to build trust and show others
+how it’s done.
+
+## Problem
+
+The team behind the InnerSource initiative promotes transparency, collaboration, and best practices across the
+organization. However, if the team itself does not adhere to these principles, others may perceive InnerSource as mere
+rhetoric rather than a transformative practice. Without leading by example, adoption and trust in InnerSource
+initiatives may suffer.
+
+## Story
+
+At Siemens, when the InnerSource journey began, many of the early contributors were deeply inspired by the Open Source
+culture, several were also active participants in community projects. For them, setting up an InnerSource platform
+wasn’t a stretch; it was a natural continuation of how they already worked: asynchronously across locations, sharing
+ideas through issues, and documenting decisions transparently.
+
+This Open Source-inspired mindset gave the InnerSource platform a distinctly different character - transparent,
+collaborative, and developer-friendly - compared to the closed, proprietary environments many developers were used to.
+Unsurprisingly, it quickly attracted experts and engineers seeking more open, cross-team collaboration and meaningful
+technical exchange.
+
+## Context
+
+In many large organizations, IT services rely on what we might call a “TicketOps” model: users submit requests into a
+system, but the people and decisions behind the process remain invisible. This lack of transparency often breeds
+frustration and mistrust, making true collaboration across departments difficult.
+
+In contrast, developer-centric initiatives like InnerSource thrive on openness and shared ownership. Instead of hiding
+behind tickets, teams work in open repositories, discuss decisions transparently, and empower others to contribute. This
+shift fosters trust, reduces the frustration of not knowing what happens behind the scenes, accelerates problem-solving,
+and turns support into collaboration.
+
+## Forces
+
+### What makes the problem difficult?
+
+- In large, traditionally structured organizations, teams - especially platform, architecture, or governance groups -
+are often used to working behind closed doors. Decision-making happens in meetings, documentation is internal or
+scattered, and ownership is unclear. Shifting to transparent, open collaboration requires both cultural change and a
+reevaluation of existing workflows.
+- Working in the open can feel scary - when everything is public, people might hold back from contributing because they worry their work isn't perfect enough. This fear of not being "good enough" can stop many valuable ideas from being shared.
+- People in central roles may fear scrutiny, overload from unsolicited input, or loss of control.
+- Moving towards open collaboration demands more discipline in documentation, async communication, and community management -
+skills not always prioritized in internal tooling teams.
+
+### What are the trade-offs?
+
+- **Transparency vs. Control**: Sharing decisions and code openly fosters trust, invites valuable feedback, and
+  increases acceptance, especially when people feel included in the process. However, it also requires a mindset shift:
+  embracing open discussion, being comfortable with disagreement, and being willing to justify decisions in public and
+  potentially critical forums.
+- **Speed vs. Quality**: working transparently can slow things down in the short term compared to quick, closed
+  decision-making. However, this slower pace often leads to higher-quality outcomes: better-informed decisions, fewer
+  misunderstandings, and solutions that are easier to maintain.
+- **Effort vs. Reuse**: documenting decisions, maintaining contribution guidelines, and curating issues takes time. But
+this investment leads to higher reusability, easier onboarding, and better scaling of knowledge.
+- **Risk vs. Trust**: opening up work may expose mistakes or half-finished ideas. But by showing authentic work in
+progress, teams build credibility and foster trust across organizational boundaries.
+
+The solution - working in the open, documenting decisions transparently, and following InnerSource best practices
+internally - addresses these forces by modeling the desired behavior. It increases alignment with developer
+expectations, improves trust in the initiative, and helps shift the broader organizational culture over time.
+
+## Solutions
+
+Rather than **telling** the teams in your organization how to practice InnerSource, find ways to **show** them how to do it.
+
+This role-modelling of the desired behaviors can be done by any team. However the more central that team is, i.e. the more touch points it has with other teams,
+the more effective this role-modelling will be as it disseminates the InnerSource behaviors into many different teams and parts of the organization.
+
+Therefore, we recommend to identify some central teams (e.g. platform teams, DevEx teams, enablement teams, or maybe even the team behind the InnerSource initiative to do this role-modelling.
+
+✅ Verified Resolutions
+
+These have been successfully applied in real-world InnerSource initiatives (including at Siemens) and are known to help
+solve the problem:
+
+1. Use version-controlled repositories for all InnerSource-related assets (policies, guidelines, tooling code,
+documentation), accessible to all relevant developers.
+1. Make decisions in the open by using issue trackers and discussions rather than closed-door meetings or emails.
+1. Apply contribution workflows to internal platforms and tools exactly as recommended for InnerSource projects: open
+pull requests, reviews, contribution guidelines, etc.
+1. Document frequently asked questions (FAQs), design rationales, and change histories transparently, as part of the
+repositories.
+1. Encourage asynchronous collaboration, especially across locations and time zones, to foster inclusiveness and reduce
+dependency on synchronous coordination.
+1. Guide new contributors with patience and understanding, creating a welcoming environment where mistakes are seen as learning opportunities. Provide constructive feedback in a respectful and supportive manner, remembering that everyone was once a beginner.
+
+💡 Possible Resolutions
+
+These could be explored to address the problem further, depending on organizational context and maturity:
+
+1. Create InnerSource “meta-projects” that transparently host governance decisions, tooling roadmaps, and shared
+architecture discussions - open to comment and contribution from the developer community.
+1. Embed technical community leads or advocates into platform/tooling teams to help translate feedback and improve
+transparency across organizational layers.
+1. Use lightweight tooling (e.g. chat bots, dashboards) to surface changes, decisions, and contributions happening
+within InnerSource-supporting teams, making their work more visible and discoverable.
+1. Promote a “working out loud” culture through internal blogs, changelogs, or recorded demos where teams share updates
+and learnings openly - even outside of the InnerSource platform.
+1. Set up health checks or self-assessments for InnerSource-supporting teams to reflect on how well they themselves are
+practicing the principles they advocate.
+
+## Resulting Context
+
+When the team behind the InnerSource initiative consistently applies the same principles they promote - working
+transparently, documenting decisions, and enabling contributions - credibility increases across the organization.
+Developers begin to see the InnerSource approach as authentic and achievable, not just aspirational.
+
+This fosters greater trust, encourages broader adoption, and creates a feedback loop where teams start to mirror these
+practices in their own projects. The organization gradually shifts toward a more open, collaborative engineering
+culture.
+
+However, this transparency can also surface new challenges, such as increased demand for contributions, the need for
+community moderation, or pressure on core maintainers. These may lead to follow-up patterns like "Growing a Trusted
+Committer Base" or "InnerSource Project Lifecycle Management" to ensure sustainability.
+
+## Known Instances
+
+- **Siemens** - The experts behind the InnerSource initiative applied the same principles they advocated, developing key
+assets such as documentation portals and contribution tooling transparently in shared repositories. Discussions about
+governance, onboarding, and platform features were handled openly using issue trackers and pull requests. This visible
+commitment to openness not only boosted trust among developers but also encouraged other teams to adopt similar
+practices, accelerating InnerSource adoption organically across departments.
+
+- **Eurospace** - This pattern was also successfully applied at Eurospace, details about this case study can be found in
+the book [Adopting InnerSource](https://innersourcecommons.org/documents/books/AdoptingInnerSource.pdf) by Danese Cooper
+and Klaas-Jan Stol (O'REILLY), see in particular the chapter _Leading by Example_.
+
+## Status
+
+- Initial
+
+## Author(s)
+
+- Florian Greinacher (Siemens AG)
+- Marion Deveaud (Siemens AG)
+- Nejc Habjan (Siemens AG)
+- Roger Meier (Siemens AG)
+
+## Acknowledgments
+
+- Antoine Auger (Siemens AG)
+- Diego Louzan
+- Ercan Uçan (Siemens AG)
+- Fabio Huser (Siemens AG)
+- Max Wittig (Siemens AG)
+
+## Alias
+
+- Show, don't tell
+- Lead by example
+- Dogfooding the InnerSource behaviors
+- Role-modelling the InnerSource behaviors