No. 52 · Manuscript complete · Founder psychology · MEMEX
The Knowledge Scale
Engineer Organizational Memory So Your Company Stops Forgetting What It Already Learned
The Knowledge Scale: Engineer Organizational Memory So Your Company Stops Forgetting What It Already Learned.
MEMEX turns organizational learning into memory infrastructure: capture, structure, retrieval, review, and reuse at company scale. Engineer Organizational Memory So Your Company Stops Forgetting What It Already Learned. The framework: MEMEX.
- pages
- 124
- chapters
- 14
- hours of reading
- ± 3
- editions
- EN · NL
- Design
- Drafting
- Manuscript
- Production
- Launched
The book
Engineer Organizational Memory So Your Company Stops Forgetting What It Already Learned
A junior engineer asks a question in Monday standup that a thread already answered last quarter. The thread is gone. The one person with the context is on a customer trip. Three people spend forty minutes reconstructing what one could have surfaced in sixty seconds. Not a crisis. Just a Tuesday, and the operating cost of a company running on memory instead of design.
That cost hides in the work week, not the P&L: reconstruction hours, the call that starts late, the new hire reverse-engineering what the team already decided. The reflex is a bigger wiki, more docs, another tool. That scales the swamp, not the memory. Forgetting is not a people problem. It is an architecture problem with a price.
The Knowledge Scale treats organizational memory as something you engineer. Its MEMEX framework (Map, Encode, Maintain, Extract, eXchange) is five moves that turn tribal knowledge locked in heads and Slack threads into explicit, retrievable structure that scales without you.
What you learn
What this book puts in your hands
- Run a 7-day friction log that surfaces the three costliest places your team re-pays for knowledge it already had.
- Map the five to ten things your team cannot afford to lose onto one page, and let the rest evaporate on purpose.
- Encode a decision for the next operator, then test retrieval with someone who was never in the room.
- Give your agents a memory layer so a 90-day-old decision stays traceable to the context that produced it.
- Put a number on forgetting with the cost calculator, and read your calendar for knowledge signal.
The contents
Chapter by chapter
Every chapter of The Knowledge Scale with its printed epigraph, what you can do afterwards, and the moment it is built for.
Introduction
The Knowledge That Disappears Every Monday
Tribal knowledge is the default at 5–200 people; the daily cost is invisible until you log it. The first move is to make the evaporation visible in the work week. The team that runs MEMEX as a daily practice does not need to remember. It needs the practice.
What you can do afterwards
You will run a 7-day knowledge friction log with five categories and a scoring rule, and name the three highest-cost evaporation points in your team's work week.
Use this chapter when
New hires or new contexts keep rediscovering what the team already knew, and nobody can say what that costs.
Chapter 1
Map What Drives Decisions
Not everything is worth encoding; the decisions that move revenue, risk, or capability are. Documenting everything creates a swamp. Mapping what drives decisions is the only mapping that earns its keep.
What you can do afterwards
You will run a 90-minute mapping session with a minute-by-minute agenda, apply the named/owned/used test with its edge cases, and produce a one-page knowledge map of the five items your team cannot afford to lose, each with its decision, owner, retrieval design, and single-head exposure.
Use this chapter when
The team has a wiki full of outdated process docs and the new head of operations cannot find the one decision that explains why the marketplace has three different fee structures in different countries.
Chapter 2
Encode for the Next Person
Encoding is making the next operator faster, not making a document. Writing things down is not encoding; turning tacit knowledge into queryable, versioned, context-rich artifacts that the next operator (human or agent) can use is the only encoding that survives contact with the work week.
What you can do afterwards
You will take the highest-friction item from your team's map, pull the rationale and exceptions out of its holder's head with a 30-minute interview script, encode it in the six-section template, and prove it works with a scripted 60-second test on someone who was not in the original decision.
Use this chapter when
"Just ask Sarah" is the most expensive sentence in your team's daily work.
Chapter 3
Maintain the Living Knowledge
Knowledge decays; ownership and cadence keep it true. Static wikis and "we'll update it later" are how knowledge becomes shelfware. Maintenance cadence, ownership, and pruning are the immune system of the team's memory.
What you can do afterwards
You will learn the five ways encoded knowledge decays, install the three-layer cadence that catches each one, run the weekly signal check as a two-question script, and prune one artifact using the retire/update/merge rules with a proper retired-list entry.
Use this chapter when
The exception logic from two years ago is still the first result for "pricing exception" and the team is following the old rule.
Chapter 4
Extract at the Moment of Choice
A memory that cannot be queried at decision time is decoration. Retrieval design that surfaces the right context in the right moment is the only extraction that earns its place. The team that compounds what it learns wins the moments that matter.
What you can do afterwards
You will inventory your team's ten highest-stakes recurring moments of choice, match each to one of four retrieval patterns, and build one end-to-end trigger that surfaces the right artifact, with its last-verified date, in the tool where the decision happens.
Use this chapter when
"I know it's in the wiki somewhere" is the sound of lost velocity during a live decision.
Chapter 5
eXchange Across the Team
Knowledge does not flow by goodwill. It flows by design. Silos are the default state of any team that has not made exchange a discipline. The team that compounds what it learns names the boundary, names the trigger, and moves the artifact.
What you can do afterwards
You will find your three most painful knowledge seams by walking the last three escalations backwards, understand the four mechanical reasons goodwill fails to move knowledge, and design one boundary-trigger-artifact exchange mechanism, then run it for a full cycle this week.
Use this chapter when
The customer success team solved a problem the product team is still building features for.
Chapter 6
The Agent-Augmented Team Memory
Agents change what the team must remember and how. "The agent knows" is the new version of "Sarah knows." The team that runs agents well supplies them with versioned, retrievable, human-verified memory, and treats the agent memory as a first-class artifact of the practice.
What you can do afterwards
You will write a complete five-part agent memory spec for your highest-stakes agent use case, choose the right verification tier for each output category using stakes and reversibility, and make a 90-day-old agent decision traceable to the human-verified context that produced it.
Use this chapter when
The team's agents are producing output that no one can explain to a customer, a regulator, or the next engineer who has to debug it.
Chapter 7
Versioning in the Daily Workflow
Every artifact will be revised, so every artifact gets a version. Not at a quarterly review: at the moment of the change, inside the artifact itself, as part of the daily workflow. The team that versions its decisions can defend any of them in five minutes. The team that does not will re-argue them from scratch, quarter after quarter, and call each re-argument "alignment."
What you can do afterwards
You will add the six-field version block to the three most important decisions still in force, learn which events force a version bump and which do not, and run the five-minute test with your newest team member as the judge.
Use this chapter when
A new hire is spending week three reconstructing why the team made a decision the team still believes in, or the same call has been re-debated twice this year under a different name.
Chapter 8
The Cost of Lost Knowledge in the Work Week
The cost of repeated mistakes, slow onboarding, and lost context is visible in the work week long before it is visible in the P&L. Quantifying the calendar hours turns "we should probably document that" into a business case with a number attached. The team that does not measure the cost pays it anyway, in arrears, under other names.
What you can do afterwards
You will cost the three most expensive forgetting events from the last 24 months with the five-field work-week cost calculator, compress the result into one slide, and defend the number against the three standard objections in your next strategy meeting.
Use this chapter when
"We should probably document that" keeps losing to "we need to ship this quarter," and nobody can say what losing costs.
Chapter 9
Knowledge as Daily Competitive Moat
The team that compounds what it learns wins by the work, not the slide. "Knowledge is not a moat" is true only for teams that treat knowledge as a byproduct. Run MEMEX as a daily practice and the recall compounds faster than a competitor can hire or copy. The moat is not the code. The moat is the recall.
What you can do afterwards
You will run the three-dimension moat audit on your team's knowledge domains, score each for compounding, leaking, and copy resistance, and leave with one domain to protect and one leak to fix this quarter.
Use this chapter when
A well-funded competitor has copied the team's feature set but is still making the pricing and exception mistakes your team solved two years ago.
Chapter 10
Onboarding and Offboarding the Knowledge
Knowledge that walks out with departing teammates, or that new teammates must rediscover from zero, is not living knowledge; it is knowledge on loan from whoever happens to be employed this quarter. Every arrival and every departure is a lifecycle event, and the team that designs for both turns transitions from silent losses into net gains.
What you can do afterwards
You will run the lifecycle checklist on the next person or agent entering or leaving your team: extract the three pieces of knowledge a departure would erase, build the day-one inheritance packet an arrival should receive, and verify both with the 60-second test.
Use this chapter when
Someone just gave notice and you are mentally listing everything only they can explain, or a new hire is in week six and still asking who to ask.
Chapter 11
Your Calendar as Knowledge Practice
The leader who says "we need to remember what we learn" while spending 2% of their calendar on knowledge work is not sending a mixed message; they are sending a clear one. The team does not believe what you say about memory. It believes what you protect time for.
What you can do afterwards
You will audit your last 90 days of calendar against explicit signal rules, categorize the ambiguous hours honestly, and redesign the next 30 days so the knowledge blocks exist, survive a tight quarter, and are visible to the team.
Use this chapter when
You keep saying the team's knowledge is the edge while your calendar shows almost no time in encoding, maintenance, or retrieval design, and the practice keeps stalling one level below you.
Chapter 12
The MEMEX Protocol for a Living Team
Every project feels new and every mistake feels original until the practice becomes a protocol: one runnable page per piece, owners named, rituals on the calendar, tests that prove it still works. The protocol is not a document about knowledge. It is the operating system that makes the next cycle of work cheaper than the last one, whoever happens to be in the room.
What you can do afterwards
You will write version 1 of your MEMEX protocol, one page per piece with an owner, cadence, and test on each, put the ritual calendar in place, and run the first week of it, scoped to one domain.
Use this chapter when
The practice works wherever you personally push it and stalls wherever you do not, or every new launch keeps feeling like the team's first.
Conclusion
The Team That Thinks Together
The protocol, run daily, stops being a set of instructions and becomes the way the team thinks: decisions land on encoded context, exceptions get captured at the moment they are granted, and the recall is in the room even when the people who built it are not. The team that compounds what it learns wins by the work.
What you can do afterwards
You will write your one-sentence commitment, book the 90-day review with its three tests, and know exactly what a pass looks like for each.
Use this chapter when
You have run the pieces long enough that the question is no longer how to start but whether it has become the default, even when the pressure says move fast now.
Who it is for
Who this book was written for
The result is a team that remembers by design: each decision you encode becomes context the next person inherits, and no single head stays the company's recall system. If you have become that head, start this week: run the friction log and encode the worst evaporation point.
The reader it was written for
Founders, engineering leads, ops directors, and team leads at 5–200 person companies where "ask Sarah" is the default way of finding out why a decision was made. They have agents producing output but no one can explain the history or rationale at the moment the next decision is being made. They are tired of tribal knowledge and tired of wikis nobody opens. Concrete archetypes (used in vignettes): Psychographics:
Probably not for you if
- Pure documentation or wiki admins (this book is a daily practice, not a documentation project).
- Companies with perfect memory (none).
- Readers seeking only personal note-taking (*Building a Second Brain* territory).
- Readers seeking institutional, audit-grade, legal-record memory (this is *The Org Memory* territory).
Editions
Editions and specifications
| Edition | Formats | Chapters | Pages | Reading time | ISBN (paperback) |
|---|---|---|---|---|---|
| English The Knowledge Scale | In production | 14 | 124 | ± 3 hours | — |
| Dutch De Kennisschaal | In production | 14 | — | ± 1 hours | — |
Both editions are written natively. The Dutch text is not a machine translation of the English.
Frequently asked
What readers usually want to know
What is The Knowledge Scale about?
MEMEX turns organizational learning into memory infrastructure: capture, structure, retrieval, review, and reuse at company scale. The subtitle is: Engineer Organizational Memory So Your Company Stops Forgetting What It Already Learned.
Is there a Dutch edition?
Yes. The Dutch edition is De Kennisschaal, written as a native edition rather than a machine translation. It moves through the same production line.
How long is The Knowledge Scale?
This edition runs 14 chapters, 124 pages in print and roughly 3 hours of reading.
Who is The Knowledge Scale for?
The result is a team that remembers by design: each decision you encode becomes context the next person inherits, and no single head stays the company's recall system. If you have become that head, start this week: run the friction log and encode the worst evaporation point.
The production system
How this book was made
Every title moves through the same gated production line: sourced research, a claim-level evidence ledger, structural review, fact-checking, red-team critique, and a bilingual final edit. AI agents do specialist work inside those gates; judgment, voice, and accountability stay human.
- Claims enter an evidence ledger with a source and a confidence grade before they reach the page
- English and Dutch are two native editions, not a translation of one another
- Every chapter clears readability, rhythm, and style gates before it is typeset
The series
More in this theme
