Knowledge Sharing & Team Memory

A backend engineer spends a day and a half chasing an intermittent failure in a payments vendor’s sandbox — a token that validates on issue and is rejected on the very next request, roughly one call in twenty, no obvious pattern in the logs. She eventually traces it to a clock drift between the vendor’s sandbox and its production environment: a short-lived token occasionally expires before her service gets to use it, because the two clocks disagree by a few seconds. She writes a comment above the fix, opens a pull request, and moves on to the next ticket.

Eleven weeks later, a different engineer on a different team — same company, same vendor, a separate product line integrating the identical API — opens a ticket for an intermittent token failure, roughly one call in twenty, no obvious pattern in the logs. He spends a day and a half on it. The first engineer’s fix is sitting in the company’s version control, findable by anyone who searches the vendor’s name, but searching never occurs to him, because nothing about how he works prompts the question before he has already spent most of a day rediscovering the answer himself. This is not a story about missing documentation. The documentation exists. What is missing is the habit of checking for it before doing the work again.

What the data already shows

The gap between a knowledge system existing and a knowledge system being used is old enough to have its own academic literature, predating AI-assisted engineering by two decades. Cabrera and Cabrera’s widely cited 2002 analysis frames knowledge sharing as a social dilemma structurally similar to a public-good problem: contributing carries a real cost to the person doing the sharing — time spent writing it up, the small risk of looking less indispensable — while the benefit is diffuse, delayed, and captured mostly by people who are not in the room. Their paper opens with an observation that reads as though it were written about 2026 rather than 2002: organizations that invest in the technology to support knowledge exchange routinely struggle to get employees to actually use it. Provisioning access and producing a habit of checking are two different projects, and only one of them is solved by buying the tool.

The AI era has not closed that gap on its own, and the industry’s own measurement bodies say so directly. DORA’s 2026 commentary on AI adoption describes AI as an amplifier of whatever organizational condition already exists — a team with fragmented tooling and siloed knowledge, the guidance states plainly, will simply use AI to generate technical debt faster, not slower. A coding agent that can read a repository does not, by itself, know that a different repository three teams over already solved the exact problem it is being asked to solve. It amplifies the habit that was already there, for better or worse, which means the habit is still the thing that has to change.

The habit gap

Why checking first is not the reflex, even for careful engineers at well-resourced companies, has a more specific answer than “people are busy.” A widely cited 2005 study of knowledge-sharing behavior found that anticipated extrinsic rewards — the kind of recognition an organization hands out for being the one who solved the hard problem — can actually depress an employee’s attitude toward sharing what they know, because being visibly the person who cracked it is a different, more individually valuable outcome than quietly pointing a colleague to someone else’s fix. Nobody has to be cynical or hoard knowledge on purpose for this to matter. The ordinary incentive structure of most engineering organizations rewards solving problems, not looking things up, and the two behaviors compete for the same afternoon.

Even when the incentive problem is fully absent — a generous engineer who would happily point a colleague to a known fix — Szulanski’s research on internal knowledge “stickiness,” already load-bearing in this Library’s discussion of ramp-up curves, supplies the second half of the answer: transfer fails inside a single firm even when nothing on paper prevents it, because causal ambiguity about why a fix worked and the recipient’s own capacity to recognize it as relevant matter as much as whether the write-up exists. A search result about vendor clock drift does not announce its relevance to an engineer who has framed his own bug as an authentication problem rather than a timing problem. This volume’s own chapter on Learning Organizations named the general shape of this failure elsewhere — a finding that only changes practice when someone remembers to change it was never really learned — and cross-pollination between teams is the identical mechanism, one layer earlier: a fix that only helps the next engineer if she remembers to go looking for it, and looks with the right words, was never really shared.

Nobody has to hoard knowledge on purpose. Rewarding the person who solves the problem, and never rewarding the person who avoided solving it again, does the hoarding for you.

A mechanism that did not exist before

Every pre-AI answer to this problem shares one structural weakness: it requires the person who stands to benefit to take the first step. A wiki helps only the engineer who thinks to search it. A tech talk helps only the engineer who attended and, months later, remembers the talk existed. A buddy system or a designated subject-matter expert helps only the engineer who knows whom to ask, which itself presumes she already suspects the problem is not new. Every one of these channels puts the entire burden of initiation on exactly the person least equipped to know, in the moment, that a shortcut exists — because if she already knew that, she would not be stuck.

This volume’s companion volume on engineering knowledge described a mechanism that inverts that requirement entirely: Decision Memory, and the decision graph built on top of it. Decisions captured from a session — what was decided, why, what it superseded — are not just archived; Operon’s MemoryInjector scores every relevant decision by goal-keyword match and recency and appends the strongest matches to a new session’s starting context automatically, before the engineer working that session has typed a single prompt. The Decision Archives chapter called this out as the property that makes a decision graph survive contact with a real deadline: the query happens whether or not a person thought to run it. Applied to cross-pollination specifically, the same property is what no wiki, tech talk, or buddy system has ever offered — a team member’s AI session surfacing “here is what a similar past session decided” requires zero deliberate effort from the person benefiting from it, which is a genuinely different property than any of knowledge management’s pre-AI practices ever had.

What auto-injection cannot reach

The honest limit sits exactly where the Decision Archives chapter already drew it, and it is worth restating plainly rather than implying the problem is solved. Today, Operon’s auto-injection reaches across a project’s own sessions, branches, and even machines — the single-session boundary Decision Memory originally solved, already crossed — but not yet across the boundary into a genuinely separate project, which the same chapter named as the open frontier. The vendor clock-drift fix from this chapter’s opening scene, discovered on one product line, would today auto-surface for a later session on that same product line. It would not yet auto-surface for the second engineer’s entirely separate product line, even though both live inside the same company, because the two projects’ decision graphs do not currently talk to each other.

Extending the graph across projects closes that particular gap, and is a reasonable near-term engineering target. It would not close the deeper one. Even a fully organization-wide decision graph can only surface what was captured as a decision somewhere — a session that ran, a fix that got written up, a trace that got persisted. It has no way to surface a solution that lives only in a different team’s undocumented practice: the workaround a senior engineer keeps in her head, the convention a team follows without ever having declared it, the vendor quirk everyone on one team simply knows. Volume X’s chapter on Team & Organizational Intelligence named the diagnostic that matters here — a difficulty map distinguishing work that is hard everywhere from work that is hard only on one team — and that distinction is exactly the signal auto-injection cannot act on by itself. A category flagged “hard here, routine three teams over” is not evidence of a missing decision record. It is evidence of a conversation an org has not had yet, and no amount of graph traversal substitutes for having it.

Two channels, different reach

The bottom three rows are not a consolation prize for the boundary auto-injection has not yet crossed. Wenger and Snyder’s foundational account of communities of practice — informal groups bound by shared expertise rather than by reporting line — describes guilds solving precisely the “hard here, routine there” case: a member who has quietly solved a problem three other teams are still paying for surfaces it not because a system scored her relevant, but because the group’s whole reason to exist is bringing exactly that kind of thing into the room. Tushman and Scanlan’s older research on boundary-spanning individuals found something narrower and just as durable: information crosses a real organizational boundary reliably only through specific people who are well connected on both sides of it, and that role is rarely a formal job title — usually it is recognized informally, and just as often left unfunded.

Field data

What to build

1. Treat auto-injection coverage as a floor, not a finished job — audit which categories of decisions never get surfaced because they live in a project the injector does not yet reach, or were never captured as a decision at all.
2. Run a difficulty map on a real cadence, per Volume X, and route every “hard here, routine there” finding to an actual scheduled conversation between the two teams — not a wiki page nobody will open.
3. Fund a guild or community of practice around the specific categories the difficulty map keeps flagging, rather than a generic standing meeting nobody quite knows the purpose of.
4. Give boundary-spanning explicit time on someone’s calendar, not just informal credit — Tushman and Scanlan’s finding was that these people are recognized, not resourced, and recognition alone does not survive a reorg.
5. Measure the gap between “solved somewhere” and “solved again elsewhere,” the same structural-loop logic this Library has already applied to postmortems — a shrinking gap is the actual sign the practice is working.

None of this replaces the other. An organization that builds only the automatic channel gets free cross-pollination exactly as far as its own captured history reaches, and nothing at all past that boundary. An organization that relies only on guilds and rotations gets breadth without the zero-effort property — real cross-team knowledge, available only to whoever happened to be in the room, on whichever week the topic came up. The two are not competing investments. One removes the need for anyone to remember to look, inside the boundary it can see. The other is the only thing that has ever worked for everything past it.