Introduction
Frameworks are like IKEA manuals: prescriptive, rigid, and guaranteed to leave you with three leftover screws. Patterns are LEGO bricks: reusable, adaptable, and fun to combine into something uniquely yours.
With Harmony, we’re building something unprecedented: a community-driven pattern language for organizational design, digital transformation, and the future of work in the age of AI. Unlike rigid frameworks that force-fit solutions, the Harmony Pattern Language will provide modular building blocks that practitioners can mix and match to address their real challenges.
To keep our language consistent and usable, all pattern submissions must follow the format below in the exact order listed. This structure ensures each pattern is complete, actionable, and connected—so we’re building not just a catalog, but a living language.
Are you ready to submit a pattern for community review? Upgrade your membership and then post your proposal to the Specs Lab. Questions? Contact the admin.
For a more elaborate description of pattern languages, check out this Substack post: “From Dollhouse to LEGO Bricks: Why Patterns Beat Frameworks”
Need help with your first pattern submission? There’s a Harmony Pattern Creator GPT and a Harmony Pattern Validator GPT waiting for you.
Harmony Pattern Language Elements
Author (Required)
The pattern contributor who remains responsible for maintaining and updating their submission during community review and after acceptance. (Basically, it’s the author of the topic posted to the Specs Lab.)
Number (Assigned after community acceptance)
A unique identifier for organizational purposes and easy referencing. The moderator assigns it when moving the pattern from The Conclave folder (where voting takes place) to the Pattern Language folder.
Name (Required)
A memorable, descriptive title that creates a shared vocabulary. For example, when teams say, “we need a Daily Standup” or “this calls for a Platform Crew,” they’re using the language efficiently.
Purpose (Required - 10 to 50 words)
A concise statement capturing what the pattern accomplishes. More specific than the title (but shorter than the problem/solution) this helps readers quickly grasp the essence before diving into details.
Also Known As (Optional)
Alternative names or synonyms. Valuable when patterns have different names or titles in different communities or when merging pattern languages.
Introduction (Required - 10 to 50 words)
A brief narrative or context-setting opener, sometimes an anecdote illustrating the situation. Helps readers connect emotionally with the pattern before technical details.
Context (Required - 10 to 100 words)
Situations where the pattern applies—the preconditions that make it relevant. Prevents misapplication and helps practitioners recognize familiar problems.
Forces (Required - 10 to 100 words)
Underlying tensions, constraints, or conflicting requirements shaping the problem. Essential for complex problems where multiple factors must be balanced simultaneously.
Problem (Required - 100 to 500 words)
The recurring challenge or design dilemma the pattern addresses. Often includes empirical evidence and real-world observations about why the problem matters.
Solution (Required - 100 to 500 words)
The recommended approach, strategy, or design addressing the problem. This is the actionable core—what you can actually do when encountering this situation.
Rationale (Required - 10 to 50 words)
A brief explanation of why the solution works and how it resolves competing forces. Deepens understanding beyond “what” to “why.”
Visuals (Strongly Encouraged)
Graphic representations clarifying structure or relationships. Particularly valuable for spatial, structural, or process-oriented patterns. Even a napkin sketch is better than nothing.
Participants (Optional - 10 to 50 words)
Roles, objects, elements, or parties participating in the pattern and how they cooperate. Useful for organizational patterns involving multiple stakeholders.
Implementation (Required - 100 to 500 words)
Practical guidance for enacting the solution, including tips, common pitfalls, and adaptation strategies. Bridges the gap between understanding and doing.
Variants (Optional - 100 to 500 words)
Alternative forms and common variations, with adaptation guidance for different contexts. Provides specific alternative implementations rather than general tensions.
Consequences (Required - 100 to 500 words)
What happens after applying the pattern—benefits, trade-offs, and new challenges that may emerge. Understanding consequences helps practitioners prepare for second-order effects and identify next steps.
Related Patterns (Required)
Connections to at least one other pattern. In early submissions, when few patterns exist, contributors must still describe anticipated connections. This ensures forward links that turn our collection into a true language.
Classification (Required)
One of five categories (please use the tagging feature on the topic). In case of ambiguity, make an educated guess on the best fit.
-
Behavioral: Actions and behaviors to imitate (e.g., standups, rituals)
-
Structural: Shapes and forms of work systems (e.g., platform teams, circles)
-
Dynamic: How systems evolve over time (e.g., scaling, pivoting)
-
Relational: Human connections and interactions (e.g., trust-building, feedback loops)
-
Technical: Human-technology collaboration (e.g., automation agents, dashboards)
Scope (Required)
Organizational level where the pattern primarily applies: Individual, Team, Organizational, or Ecosystem (please use the tagging feature on the topic). Helps practitioners understand implementation scale and potential ripple effects.
References (Required)
External sources with more information on this pattern.
Review Process
The review process is described in the Proposal & Voting Process.
TLDR:
-
Community members submit patterns using this exact format and element order.
-
Open community review period, usually up to one month. (If a proposal is posted in the 2nd half of a month, it carries over to the next month to allow everyone sufficient time for voting.)
-
Community voting on each submission (accept/reject). All members have equal rights, including the moderator.
-
To prevent abuse (brigading, trolling), moderators can temporarily suspend questionable submissions or voting behaviors pending community discussion of appropriate governance processes.
-
Accepted patterns receive official numbers and integration into the official pattern language.
-
All patterns receive a Creative Commons license and can be copied and applied by anyone, with proper attribution.
-
Pattern authors maintain responsibility for ongoing refinement based on real-world usage.
Conclusion
This format ensures the Harmony Pattern Language remains both comprehensive and practical. By standardizing submission requirements, we create consistency while preserving the flexibility that makes pattern languages powerful.
But remember: this isn’t an IEEE standard. It’s a LEGO set. Start with a problem you’ve solved in real life, write it up in this format, and submit it. That’s your first brick in the language.
The future of work isn’t written in frameworks. It’s built in patterns. Let’s start building together.