I think that pattern languages might be a useful tool for organizations - like rich meme libraries - able to convey a bunch of knowledge in a few words. I think they can improve communication, collaboration, learning, and problem solving.
This is my attempt to understand them better through the Feynman technique.
What’s a Pattern Language?
I came across pattern languages after reading Christopher Alexander’s Notes on the Synthesis of Form and A Pattern Language. Maggie Appleton provides a good definition here:
Patterns are problem-solution pairs that are relevant in a specific context, like the Personal Touch pattern below (from Manns & Rising, Fearless Change), designed to help a person introduce a new idea to colleagues. A pattern is a general case, meant to be widely applicable across diverse experiences. I’ve included the general structure of a pattern in an appendix to this post.
Patterns are given conversational names and linked together in a language, so that users can efficiently communicate deep knowledge of a subject area. Like memes and clichés, patterns are cultural artefacts that have secret meaning to those in the know. Well-named patterns are community builders.
I was talking with Jim Johnson a while back about mapping the org, making visualizations to describe how the org works. These become shared representations that provoke org changes and speed team decision making. Patterns, as an example of this kind of representation, need just a couple of high quality words and a good pic to be quick-referenced by people within their work and broadly understood throughout the org.
A pattern language is expert knowledge made explicit. It’s cracking open the heads of your most experienced workers to make an omelet. I followed Cedric Chin’s lead and started reading Accelerated Expertise, which suggests that sets of interlinked expert case studies can accelerate learning. Patterns are like condensed case studies that can be spoken and that carry analysis along with experiential summaries of the pattern in use.
Beyond just a set of patterns, the language can include established pathways and clusters of related patterns that combine to solve more complex problems. Patterns can be solutions to other patterns, as in the reference to [Use Just Enough] in the [Personal Touch] example above.

When would I use a Pattern Language?
Like any language, pattern languages support communication and learning among a group of people. They’re most useful when:
trying to understand a domain, as in a worker onboarding to a new organization,
communicating complex ideas, as in a manager referencing a pattern by name in a project retrospective,
approaching a recurring problem, as in [Personal Touch] above - used to introduce new ideas in an organization, and
approaching a new problem, as in the emergence of something that extends across and beyond existing patterns.
How do I use a pattern language?
A pattern language can be built and surfed like a wiki, where documented patterns link to other patterns. Pattern navigation is guided by the user (often via intuition) and their specific context - you learn what you need in the moment.
Patterns can be combined to form novel solutions to complex problems. While surfing, you might assemble a set of patterns that offer a unique solution.
Imagine you’re considering a 4-day work week for your org. You might find and combine the following patterns to inform the design and communication of the new idea to workers:
Why Pattern Languages?
Pattern languages emerged as an answer to communicating deep senses/perspectives of the org, following a conversation with Jason Shim about how to break the guiding strategy of the org into pieces that could be used in the flow of work. We talked through values, principles, mantras - objects of essential knowledge made explicit - that the worker could grab hold of, learn from, apply the learning to the work, then feed new learning about that object.
It’s this connection to strategy and alignment that most interests me.
Every interaction is an event, and it is these light and ephemeral events that weave reality, not the heavy objects charged with absolute properties that our philosophy posited in support of these events.
Carlo Rovelli, Helgoland
If a heavy object like an organization exists only through its events - its actions - then it’s within those actions that the critical moments of org realization and adaptation occur. In this way, an individual worker making a single decision is more representative of the current state of the org than a board-approved strategic plan from last year.
If the worker has access to reliable and evolving patterns in the course of their work, will they make better decisions? Will the values that the org….values… be transmitted and reflected in the worker’s decisions and actions?
As I was walking and talking around over a few days, thinking about pattern languages, I found a useful connection to conversations with Seth Earley about AI and RAG (retrieval augmented generation).
My current impression of AI is as a data ingester, creating patterns and spitting out pattern fragments to match a user query. With no org schema, AI will eat your data and make its own patterns. But some organization (maybe most?) will want the AI to use the organization’s pre-built patterns, not generic or context-unspecific patterns.
These org patterns - be they values, mantras, principles, cultural representations - are the org’s core operating principles - their soul - the subsconscious instructions that give them their unique drives. With these in hand, an AI could answer worker queries that are framed and phrased according to the org’s perspective.
What are the Next Steps for Exploring Pattern Languages?
So is a set of patterns - interlinked - a decent way of representing the org? Can pattern languages help workers align, communicate, work together with greater efficiency, faster, warmer, healthier?
I’m exploring this question through an experiment in Coda I’m calling Lines. In subsequent posts, I’ll document some of my findings and see if pattern languages can be helpful in the context of my work design agency, Morning Strategy.
Appendix: the Structure of a Pattern
From Fearless Change, fed into ChatGPT, and edited a bit:
Sections of a Pattern
Name:
Purpose: a clearly stated name to capture the essence of the pattern
Example: "Work Should Feel Natural"
Context:
Purpose: the situations or environments where this pattern applies.
Example: "Workplaces with low engagement and productivity."
Problem:
Purpose: Define the issue the pattern aims to address.
Example: "Employees feel disconnected from their tasks."
Forces:
Purpose: List the factors that impact the problem and the solution.
Example: "Employee well-being, productivity, alignment with skills, work environment."
Solution:
Purpose: Provide the actionable steps to resolve the problem.
Example: "Design tasks that align with motivations, encourage autonomy, foster a supportive environment."
Implementation:
Purpose: Offer specific methods or actions to apply the solution.
Example: "Conduct surveys, provide job crafting opportunities, create a culture of trust."
Consequences:
Purpose: Outline the potential outcomes of applying the pattern.
Example: "Increased satisfaction and productivity, potential resistance to change."
Examples:
Purpose: Provide real-world instances where the pattern has been successfully applied.
Example: "Tech company project selection, marketing agency flexible workflows."
Related Patterns:
Purpose: List other patterns that are connected or complementary to this one.
Example: "Autonomy in Work, Aligning Roles with Strengths, Supportive Work Environment."