Darkness has a hunger that’s insatiable and lightness has a call that’s hard to hear. […] There’s more than one answer to these questions pointing me in a crooked line. And the less I seek my source for some definitive, [the] closer I am to fine. — Indigo Girls
The hardest part of my job is figuring out what to do.
Giving advice, telling people what to do, is a trillion dollar global economy. Unfortunately, to generate knowledge flow, I can’t simply do what someone else tells me to do. I am continuously figuring it out, synthesizing, learning from the circumstances, as those circumstances continously change.
I am supported by other people’s knowing — but I still have to cultivate our own.
Nobody knows the right thing to do in every circumstance. I certainly don’t. Yet, paid to make recommendations and decisions, big ones and small ones. I don’t mind. I circle around a tricky problem like a hyena hunting prey, deciding when to act.
I make mistakes. I try to learn from them. Because the worst mistake — the one I see organizations make often — is doing the same thing but expecting different results.
The definition of insanity is doing the same thing, over and over again, but expecting different results. — Rita Mae Brown, Sudden Death
I make a lot of artifacts while discovering, describing, defining, and developing a change. Hoping to improve a system. My job is not only to find a problem and solve it. Most of the time, even when writing code, I am not fixing a problem. I am … engineering.
People usually ask for artifacts showing a straight line from requirements → launch. That’s … not how change development works. I like when something can be done that way. But usually, figuring out what to do is more like a dance.
A dance with what we know and what we don’t know, the ghosts in the machine. And that’s okay, we still get plenty done.
Perhaps you hate dancing. I don’t blame you. Unfortunately, whenever you stand still, arms folded, certain you’re “right,” you’re not only pausing the dance — you are the rock everyone else has to flow around you.
I have my Rock Days. My teammates patiently dance around me, nudging.
But dancing with the rock guy is a drag. That guy is dancing to an old song. Stepping on toes. He’s a one tune wonder. When a new song is playing, he won’t hear it.
The future value of a system reveals itself in today’s realities, not yesterday’s speculation. – Kent Beck, Tidy First
This chapter is choreography. Steps to try. Six Spiral Paths and one activity to get you started down each path.
- Navigate Temporal Currents with Feedback Dynamics
- Cultivate Coherence with Enabling Constraints
- Architect Emergent Meaning with Ontology-Centered Practice
- Steward Distributed Decisions with Fair Process
- Mastermind Cognitive Ecologies with Mental Model Callibration
- Design Learning Loops with Retrospectives
These practices are not managerial theater — doing these activities in a highly-visible but ultimately-superficial way. The goal here is not to increase the illusion of control, competence, strategic mastermindness, and efficiency.
The goal is to do genuine, substantive work.
On first read, you might shout: “Those are not substantive! They are no concrete deliverables! They don’t relate to my job!”
Bitch, please.
Concrete can’t dance. These practices let you do your job without being the rock guy.
Knowledge flow skills have benefited me more than any other skillset. Yes, my technology mojo matters. But how valuable are technology skills if I can’t be effective when applying them?
If I want to do hard things and solve difficult problems … I need to dance with knowledge systems.
Here are some grooves, my friend. Bust a move.
The Spiral Paths
The Spiral Paths are groups of practices, habits, and heuristics that lead towards the Six Inconceivable Truths. This chapter introduces them … but that is like looking at a map. You’ll have to actually walk the path if you want to get anywhere.
Each Spiral Path strengthens a different capacity in a living system. Together they create the conditions where knowledge can move, accumulate, and evolve.
Navigating Temporal Currents
People assume that time is a strict progression of cause to effect, but actually—from a non-linear, non-subjective viewpoint—it’s more like a big ball of wibbly-wobbly, timey-wimey… stuff. — Dr. Who
Knowledge is not something we own; it’s something we do. Discerning what to do and when to do it requires temporal intelligence. — the organizational capacity to operate asynchronously.
Time isn’t linear. It’s loops, delays, accelerations, and cascades. Navigating these temporal currents is learning to see how events, attention, and feedback interact over time. If you don’t design for feedback, you mistake project management for architecture, noise for progress, deadlines for learning, and urgency for importance.
A feedback loop is how systems talk back to us. An output (a project plan, a feature release) becomes a new input: deadlines, metrics, expectations.
These loops can calcify into structures … and we lose track of signal and instead, generate noise.
We already have temporal structures; meetings, a user interaction, a deadline, logs, budget estimates … we use these to navigate time together. The practices along this path restructure time-dependent experiences to make them more dynamic and less linear.
Navigating temporal currents means designing patterns that make time visible: feedback loops, rhythms, and structures that reveal what is actually happening. The practices increase our understanding of the system, and encourage the frictionless flow of knowledge.
Before designing better feedback loops, it helps to see the ones already shaping your work.
Activity: Priority Pulse Check
You are not solving a problem with this practice. You’re observing time.
Write these responses in your Knowledge Studio, or any space you’ve created for thinking and observing.
Step 1: List Current Priorities
Write down the five things currently receiving the most attention in your work.
Not the official priorities. The actual work pulling on your attention.
Examples:
- An escalation or outtage
- Preparing for a meeting in which you “manage expectations”
- A delayed task or project
- Giving feedback in a 1:1
- Fixing a bug
Step 2: Identify the Trigger
For each priority, describe:
What event triggered this work?
Examples:
- Someone posted an “emergency” Slack message
- A governing ritual is on the calendar
- Someone asked about a dependency
- Someone complained
- You discovered a problem that hasn’t been escalated yet
Notice that priorities often emerge from events. We think we are operating as planned but usually, we are reacting to events.
Step 3: Look for Feedback Loops
A feedback loop occurs when an output becomes a new input — triggering further action, reaction, or adjustment.
What signal is this priority responding to?
Is it:
- A user experience
- Operational control mechanisms
- Management-generated deadlines
- Social friction in a hierarchy
- An opportunity for improvement
Sometimes, multiple priorities share the same signal.
Step 4: Look for Missing Signals
Now ask a harder question:
What important signals are not creating priorities?
Examples:
- Long-term technical debt that interferes with reliable user experiences
- Reporting processes that reflect reality
- Team frustration increasing apathy
- Lack of shared understanding of why work matters
- No observability or testing across the system
These signals exist.
But the system doesn’t react to them.
Step 5: Pulse Check
Finally, explore this question:
If our system responds to these signals, what kind of future are we designing?
Reactive systems chase urgent signals. Intelligent systems design the signals they respond to.
Systems rarely lack information. They lack the structures that help them respond to the right signals. When these structures are designed to generate the right signals, they are called enabling constraints.
Cultivating Coherence
There’s more to being a king than getting your way all the time. — Mufasa, The Lion King
Knowledge flows through human, organizational, and technical relationships. People, tools, and practices are constantly exchanging signals, context, and perspective.
They also exchange noise: fragmented priorities, misinformation, siloed incentives, and social pressure.
Coherence doesn’t live inside a single person, team, leader, or piece of software. It lives in the relationships between them.
Every organization develops informal coherence roles: the translator, the glue person, the one who “knows how things actually work,” the person everyone calls before a cross-team meeting.
These roles provide essential systems leadership, but they are rarely recognized as leadership. As fragmentation increases, they become a janitorial response to incoherence — constantly cleaning up misunderstandings the system itself produces.
Coherence cannot be imposed — it must be cultivated.
It emerges when meaning can travel across boundaries. Teams move in relation to one another and still make sense together. The organization becomes capable of intelligent action without constant command-and-control oversight.
Teams generate more signal, action and insight. They make less mess because, as feedback loops strengthen, the consequences are visible to them.
One of the most powerful ways to cultivate coherence is through shared language.
Engineering talks about architecture. Product talks about features. Finance talks about cost centers. Operations talks about observability. Everyone is working on the same system, yet each group describes it differently.
They can’t solve challenges together because they can’t talk about those challenges, together.
When a group develops shared concepts for describing their domain they begin to see the same system together. Domain-Driven Design calls ubiquitous language.
Concepts like “product,” “platform,” “value,” “customer,” or “observability” stop shifting depending on who is speaking. They become anchors for meaning.
Shared language acts as an enabling constraint: a structure that allows collaboration to become easier and more creative.
But most organizations don’t realize how fragmented their language actually is. A quick experiment can reveal the hidden structure of meaning inside your system.
Activity: Concept Alignment
Step 1: Find Frequent Terms
Choose artifacts from three different parts of your organization.
Examples:
- an engineering design document
- a product roadmap
- a budget or resource allocation spreadsheet
- performance dashboard report
- description of work (like a JIRA ticket)
- business goals and metrics strategy
Use an AI model (or your actual intelligence) to extract the most frequently used terms.
Step 2: Define Them
Then explore:
- Do the same concepts appear across teams?
- Do the words mean the same thing?
- Where do meanings diverge?
You may discover that sometimes, the system isn’t struggling with coordination at all.
It’s struggling with language.
Shared language is only the beginning. As meaning stabilizes, patterns begin to appear: recurring concepts, relationships between ideas, and structures that help people navigate complexity.
At that point coherence stops being accidental. We can begin to intentionally design the structures that allow meaning to emerge, evolve, and travel across the system.
Expertise combines rather than colliding. The organization begins to generate meaning through a knowledge architecture.
Architecting Emergent Meaning
The mystery of life isn’t a problem to solve, but a reality to experience. — Reverend Mother Mohiam, Dune
Organizations don’t lose knowledge because people forget. They lose it because meaning has nowhere to live.
So organizations must constantly reinvent knowledge.
Teams solve the same problems again and again because the meaning behind decisions never accumulates. Artifacts live in disconnected systems. Language shifts between groups. Experience remains locked in people’s heads instead of becoming structural knowledge.
Several forces drive this pattern:
- artifacts are disconnected
- no shared ontology
- experience isn’t captured structurally
The result is constant reinvention.
The alternative is to architect emergent meaning.
Instead of treating knowledge as static documentation, or rigid blueprints, we design systems where meaning accumulates over time.
When we architect knowledge flow, execution changes. Language stabilizes. Patterns become visible. Decisions gain context.
With practices like …
- system-level knowledge repositories
- ontologies
- recognizing epistemic anti-patterns (like reductionism)
- pattern libraries
- rituals that reinforce shared vision rather than metrics
… meaning begins to travel across the organization.
This is what knowledge flow depends on.
Architecting emergent meaning is designing the connective tissue that allows insight to accumulate. Structures that allow execution to move with coherence. Not because someone enforced alignment. But because the system makes sense.
OKRs don’t magically produce clarity. But well-designed knowledge architecture reinforces itself. People see when they diverge and can shift direction — rather than being directed.
Activity: Mapping a Living Concept
Step 1: Choose a concept
One that appears frequently in your organization and is usually involved in major decisions.
For example:
- customer
- platform
- event
- product
- capability
- risk
- value
Step 2: Collect meanings
Ask five people from different parts of the organization what the concept means.
Write down their definitions.
The word is probably being used to describe different things.
Step 3: Map relationships
You aren’t looking for the “right” definition here (like in Concept Alignment). Instead, you are modeling the concepts that people describe as meaningfully connected to it.
- What other concepts does this one relate to?
- What events involve it?
- What actions affect it?
- When does the concept generate action or meaning most often?
Draw a simple map showing these relationships. (Tools like Figjam and Miro have mind map examples. But you don’t need a tool to make one.)
Context is everything: Notice how the meaning often becomes clearer through relationships viewed differently by different parts of the org? Sometimes, definitions are insufficient for understanding.
Step 4: Stabilize the concept
Share this mind map with the original participants and anyone who might benefit.
This is a first step towards an ontology: a set of concepts and categories in a domain that shows their properties and the relations between them.
Without knowledge architecture, repositories, models, and documents quickly become brittle silos.
Teams may build quickly, but if no one agrees on what “customer,” “event,” or “risk” actually means, systems fragment into duplication and contradiction.
When meaning travels across boundaries, everything else can accumulate instead of restarting from scratch.
Knowledge becomes cumulative rather than fragile.
More importantly, decision-making authority is distributed across the system, rather than bounded by limiting silos.
Stewarding Distributed Decisions
If you want a guarantee, buy a toaster. — Nick Pulovski, The Rookie
When knowledge flows, leadership shifts from making the right decision to stewarding how decisions become right together. Authority does not need to be centralized or distributed — as informed recommendations travel across context, good decisions emerge.
Stewarding distributed decisions means building the infrastructure for synthesizing divergent viewpoints. Designing processes where people can think well together without losing coherence.
This is worth repeating: distribute decision making without losing coherence.
Decisions that trickle down through hierarchy lose the connection between intent and implementation expertise. Strategy and implementation lose the ability to harmonize around shared knowledge.
When authority is distributed into siloed teams with boundaries that have no knowledge sharing architecture between them, or worse, a faulty and brittle one, conflict, unsatisfying outcomes and endless debates result.
Teams feel frustrated and increasingly apathetic. Waiting for approval to do what must be done. Taking blame for problems resulting from fragmented decisions that later collide. Without intentional design, organizations default to escalation, managerial control, the latest Business Consultant Buzzword Framework, or the goodwill of people willing to step up into problems they did not create and cannot prevent.
This is especially prevalent when:
- cross-functional complexity increases (which is true for most systems who rely on digital tools)
- incomplete information shards can’t translate context from one role to another
- success incentives conflict or compete
- promotion to leadership roles does not depend on the ability to facilitate knowledge flow
- authority structures that can’t work together effectively
- blame is placed on the wrong things
- accountability means fixing problems you can not prevent
Distributed decisions are designed processes for thinking well together. Leadership shifts from controlling outcomes to stewarding the conditions that allow insight to combine.
Leadership becomes stewardship of the knowledge infrastructure:
- Noticing what is happening or what is missing
- Making Sense of circumstances
- Relating perspectives, context, and expertise to decision making
- Generating sound recommendations
- Acting on them, in concert with cross-functional roles
- Updating processes, practices, mental models, and decisions as they learn
The goal is not simply increased efficiency, but coherent, effective, and impactful decisions that people trust and can act on.
Designing and legitimizing these processes makes the necessary skills visible — especially the ability to map the decision environment. Asking questions like:
- Why does this matter — how does it increase the value of what we do?
- What do we need to find out — what inputs are required?
- Who has the knowledge we need to integrate?
- What remains unknown and how will we take action carefully?
- What conflicts or incentives are shaping viewpoints?
- What has been blocking us and might, yet, slow us down?
Teams that can synthesize knowledge don’t need to hack authority structures to get things done. They can trust their colleagues’ input and take action even if they don’t fully understand every decision that led to this moment.
They rely on the power of organizational intelligence.
- Decisions move faster and carry more legitimacy.
- Most problems are solved by the people closest to them
- The technology systems that support work become more flexible and resilient as fragmentation decreases
- The return on investment of time, energy, and attention increases. Frustration and loss of talent decreases.
Because people who make excellent, valuable, well-reasoned decisions want to work with teams and organizations that value that skill.
Activity: Practicing Fair Process
Distributed decisions only work when people believe the process was fair.
People don’t need to win every decision. But they do need to know their perspective was heard, considered, and connected to the final reasoning.
This practice makes the decision process visible — and legitimate.
Step 1: Name the decision
Choose a decision that involves multiple roles, teams, or perspectives.
Write it down clearly:
- What decision needs to be made?
- What outcome does it influence?
Avoid vague framing like “improve the platform.” Focus on a specific decision like ‘use feature flags” or “decrease checkout time by 30%”.
Step 2: Invite perspectives
Identify 3–5 people or roles whose knowledge meaningfully affects the decision.
Ask each one:
- Why do you think this decision is valuable?
- Have you had experiences that convinced you?
- What concerns do you have about this decision?
- What opportunities do you see?
- What knowledge or experience should influence the choice?
You are not looking for agreement or alignment — you are surfacing perspectives and context.
Step 3: Make the reasoning visible
Synthesize these perspectives into an artifact that reveals the nuance of the decision and its impact.
- Why is it valuable?
- What factors matter most?
- What trade-offs exist?
- What blockers exist and what do we know about them?
- What uncertainties remain? Do they need more exploration?
Explain why a particular direction appears strongest and what convinced you.
Decisions without transparent reasoning are just opinions.
Step 4: Clarify how the decision will be made
Clarify:
- Who will make the final call on aspects where there isn’t agreement?
- What additional input is needed?
- How will learning happen to validate (or not) this decision?
- What timeline applies?
Hidden power struggles can sometimes ease when they are no longer hidden.
Step 5: Close the loop
This step is often skipped — but it builds legitimacy. Distributed decision-making also requires facing the discomfort of responsibility. Especially when people might be unhappy about it.
After the decision is made, return to the group and share:
- the final decision
- the reasoning behind it
- what input influenced the outcome
They may disagree with the decision, but they will understand how it happened.
The hardest part of stewarding distributed decisions is building trust across the knowledge infrastructure. It’s easy, and common, to shy away from transparent decision making. And stand up for well-reasoned recommendations. But it’s worthwhile.
Disagreement becomes productive. Expertise travels across roles. Decisions move faster. Organizational intelligence and individual expertise increases.
Don’t confuse this with “empowering” teams. That language suggests power is generously given by someone who owns it.
Distributed decisions work differently. Authority emerges from the sociotechnical system itself — producing better outcomes rather than simply shifting responsibilities.
Mastermind Cognitive Ecologies
We all know the truth: more connects us than separates us. But in times of crisis the wise build bridges, while the foolish build barriers. — T’Challa, Black Panther
Organizational intelligence emerges from multiple modes of cognition interacting. I experience this personally when I partner with designers and people who understand user experience.
My brain is extremely word focused. In my perfect world, we’d use words to gain insight into everything. But I’ve seen how a visual artifact communicates more effectively. And how far from understanding the audience I get when trying to articulate a new idea.
Analysis, intuition, embodied experience, storytelling, pattern recognition, and systems thinking each reveal different aspects of reality. Yet most organizations actively silo — or even discourage — collaboration across different modes of thinking.
Masterminding cognitive ecologies means breaking down those barriers and designing practices that integrate multiple ways of thinking into clearer insight and better action.
On technology teams, I also experience pressure to think in a single cognitive mode.
- purely analytical thinking (coding)
- purely operational thinking (infrastructure)
- purely managerial thinking (engineering manager)
I find this confusing because I always need all three … plus systems thinking, pattern thinking, and a bit of intuition.
This preference for singular thinking roles, ostensibly intended to improve specialization, yields partial understanding and recurring blind spots.
It’s reinforced by:
- education patterns that reinforce “hard vs soft” skills
- professional identity silos
- hierarchy of expertise
- impatience with thinking as a critical step in knowledge work
- cultural bias toward “rational” thinking
- time pressure favoring familiar solutions
These forces create competition between ways of thinking rather than collaboration.
Organizations are also influenced by the Lone Hero approach. The 10X developer, the maverick CEO, the product manager who “makes the trains run on time”, the charismatic salesperson. Even when we believe in teamwork, we forget that Frodo succeeds because he is part of a cognitive ecology.
Because Sam.
Organizational intelligence is not individual brilliance. It is the quality of thinking that emerges between people.
It is the integration of diverse cognitive perspectives.
When different ways of thinking interact well, they form a cognitive ecology — one where people with different cognitive strengths become allies rather than competitors.
Activity: Calibrating Mental Models with the Iceberg Model
Everyone relies on mental models — internal maps that explain how things work.
These models shape decisions, expectations, and interpretations of events.
Alas, they are rarely examined. Many, if not most, of our knowledge flow blockers are simply mental models colliding.
When organizations attempt change and end up repeating the same patterns, they have hit the iceberg — the deeper assumptions shaping the system. An inability to change mental models to fit the change they want to create.
Calibration is the practice of making these inner maps visible and re-shaping them — with reality and with others.
A useful tool for this work is the Iceberg Model, which reveals how deeper assumptions shape visible outcomes.
Above the waterline we see events. Below it lie patterns, structures, and mental models — the deeper forces shaping what keeps happening.
Step 1: Identify a recurring event
Choose a situation your team experiences repeatedly.
Examples might include:
- projects consistently missing deadlines
- recurring incidents
- friction between two teams or two roles
- slow decision making
- an action that fails to deliver expected value
Write down the observable event.
Step 2: Look for patterns
Explore:
- When has this happened before?
- Under what circumstances?
- Does it appear in multiple circumstances, teams, or projects?
- How often does it occur?
- How do people respond?
- What do they say?
Patterns reveal events that are systemic, though we often react as if they are isolated.
Step 3: Examine the structures
Consider the structures that might produce or reinforce the pattern.
Examples of structures include:
- incentives and metrics
- organizational boundaries
- hiring and promotion practices
- single-perspective feedback loops
- workflows and processes
- tooling and information flow
- authority structures
- rules that are reinforced
Structures are the infrastructure that keep the patterns repeating.
Step 4: Surface the mental models
Explore beliefs or assumptions that might be sustaining those structures. You’ll probably need to come up with more than one. When you discover the one that resonates, the whole Iceberg makes sense.
Examples might include:
- “Speed matters more than reflection.”
- “Growth is the goal.”
- “Engineering is responsible for delivery.”
- “Customers always want more features.”
- “Only managers are responsible for outcomes.”
- “Pleasing leadership is our job.”
- “Escalation is the safest way to resolve conflict.”
Mental models constrain decisions. You’ll notice, after you do this practice, that even when people disagree with the core mental model, they will act to reinforce it.
Step 5: Calibrate the model
Consider this: Does the mental model fit the current circumstances?
- Which assumptions are still accurate?
- Which aspects no longer match reality?
- What alternative explanations might better describe the system?
If you change the core mental model to match the change you want to see — how would that shift the Structures and Patterns?
When teams calibrate their mental models:
- problems shift from blame to curiosity
- recurring patterns become understandable
- new solutions become visible
Instead of reacting to events, people begin redesigning the system that produces them.
When we mastermind cognitive ecologies, fresh insights become possible. Teams stop cycling through the same failed solutions and begin redesigning the thinking environment itself.
Innovation emerges from interaction between ways of thinking, not from one dominant perspective.
And knowledge begins to flow.
Designing Learning Loops
No matter what anybody tells you, words and ideas can change the world. — John Keating, Dead Poets Society
It is impossible to overstate how important this path is to knowledge work. I would argue that learning is why knowledge work exists. Somehow, though, it is often the hardest path to walk in most organizations.
Resilient sociotechnical systems learn continuously. This was always true. In the age of AI, it is inescapable.
Learning cannot rely on training budgets, reading books (as valuable as that is, obviously) or occasional postmortems. It must be embedded in everyday practice.
Organizations treat learning as an event.
- training programs
- 20% time projects
- post-incident reviews
- retrospectives focused on “how to deliver faster”
- role-based constraints on learning budget allocation
- missing metrics that measure learning post-delivery
Without learning loops, activities designed to change behavior rarely change behavior.
There is one blocker to learning that prevails.
Too Busy.
- delivery pressure
- fragmented feedback (just the facts, ma’am)
- lack of reflection time
- disconnected artifacts
Teams act without knowing whether the system is actually improving. And they feel it, as the grind becomes a grindstone.
When feedback and reflection are embedded in everyday work, the system adapts continuously. Organizations evolve.
Learning is not a side project, a budget allocation, or a certification course. (Those might be involved!)
Learning is a designed loop inside the system.
This loop includes:
- Perceive signals from the environment
- Diagnose patterns and causes
- Connect insights across the system
- Create potential responses
- Launch experiments or actions
- Learn from outcomes
Among people interested in knowledge and the work that generates it, learning often happens by accident. But it can’t grow, flourish, and inform collective action.
By designing how learning will occur, teams ensure insight flows back into the system. Execution becomes adaptive rather than reactive.
Learning becomes part of engineering itself. Instead of linear delivery:
plan → build → deliver
the system evolves through:
notice → test → reframe → act
If the loop is strong, the system becomes intelligent.
Activity: Practicing Retrospective Learning
A retrospective is not a meeting. It is the habit of turning experience into evolution.
Without retrospectives, patterns slide beneath the surface and people can only respond to events. With them, insight, pattern shifts, even structural improvements becomes continuous.
Retrospectives create a simple learning loop: experience → reflection → adjustment.
Step 1: Choose a recent experience
Select a meaningful piece of work that was recently completed.
Examples:
- a product release
- a technical migration
- a cross-team decision
- a production incident
- an experiment or initiative
Choose something recent enough that people still remember the details.
Step 2: Reconstruct what happened
Before analyzing outcomes, reconstruct the sequence of events. Separates observation from interpretation.
- What were we trying to achieve?
- What actually happened?
- What surprised us?
The goal is to build a shared understanding of the experience.
Step 3: Identify signals
What did the experience reveal about the system?
Explore questions like:
- What worked better than expected?
- What created friction or confusion?
- What was given up to go faster?
- What patterns are we noticing?
- What assumptions turned out to be incorrect?
These signals often reveal insights about:
- processes
- tools
- communication
- decision-making structures
- mental models
Step 4: Choose one adjustment
Resist the urge to generate a long list of improvements. (Please.)
Instead ask:
• What small change would make the biggest difference next time?
Examples might include:
- clarifying a shared definition
- adjusting a workflow
- adding a feedback signal
- reshaping an artifact
- changing a decision pattern
- testing a new practice
Remember: learning becomes meaningful when it changes behavior.
Step 5: Close the learning loop
Document the insight and the adjustment somewhere visible.
The goal is not simply reflection, but making learning cumulative. Over time, small adjustments compound into significant improvement.
When learning become habitual, teams stop repeating the same mistakes. Learning travels and experimentation becomes the norm. When we make an improvement, it sticks.
Instead of relying on heroic effort, learning improves the entire system through collective processes and practices.
Learning is the bridge between “We tried.”
and
“Now, we are better.”
The opening of the TV Show The Six Million Dollar Man* said “We can rebuild him. We have the technology.”
You have what you need to take this journey. You can re-architect the systems you inhabit.
Not all at once. And not easily. But you have begun.
In fact, you are already well on your way. You now have practices, patterns, and ways of seeing that can help knowledge flow where it once stalled.
From we’ll go deeper. You’ll generate lived experience. Learn more complex dance moves. Practice the kind of discernment that helps you recognize delusion and move towards change.
This journey is next-level work. Take your time. That’s the beauty of practice — it waits for you to be ready. You don’t need to hurry.
You took the red pill, remember? You are not going back.
Knowledge is seeking you.
^ the billion dollar man in today’s dollars