A worked example of [[Shared Second Brain|building a shared second brain]] at cross-team scale, traced through pain → cluster → quality bar → method → tool. Extends the [[Shared second brain example - ADR log|ADR log example]] - same organisation, six months later, having outgrown a decision-only log. ## In one line ADR log answers *what did we decide* but not *who knows about X* or *what tools have we tried* → cross-team expertise cluster, non-negotiables *multi-entry queryability* + *connectivity across dimensions* → linked databases following the [[Expertise Radar]] pattern → [[Notion]] with linked databases. ^one-line ## Starting point ![[Shared second brain example - ADR log#^one-line]] That works for *what did we decide?*. It fails when the question shifts. ## The acts in one line each ADR log captures decisions but cannot answer *who is the expert here*, *what tools have we tried*, or *what problems does this technology actually solve*. The trail still goes cold at the edges of the decision record. ^trail-line Cross-team expertise as a graph - decisions yes, but also experts, tools, problems, and projects, all interrelated. Non-negotiables: *multi-entry queryability* and *connectivity across dimensions*. ^profile-line Linked databases following the [[Expertise Radar]] pattern - each entity (problem, tool, expert, project, decision) is its own database, cross-referenced. Entries traversable from any direction. ^method-line ## Full walkthrough ### Knowledge trail mapping Same organisation as the ADR log example, six months later. The ADR log works for the question it was designed for - *what did we decide on this project, and why?* The pattern breaks when the question shifts: - *Who in the org has experience with event-driven architectures?* - ADRs name decisions but not experts; finding the right person requires asking around - *What tools have we tried for caching across projects?* - the tool is buried inside decision rationale paragraphs; no way to query across - *This new project has a notification problem - has anyone solved this before?* - the underlying problem is not a first-class entity; only decisions are Decisions are documented. Everything else - the *who*, the *what tool*, the *what problem class* - lives in people's heads. ### Knowledge domain profiling The cluster: cross-team expertise as a graph. Same data as the ADR log but with additional first-class entities - experts (the people), tools (the technologies), problems (the underlying business challenges), projects (the contexts), and the decisions that connect them. Volatility: low at the entity level (the same Postgres expert remains a Postgres expert; the same tool remains the same tool). High at the connection level (which projects used which tools, who solved what problem when). Connectivity: explicitly high - the whole point is being able to traverse from any node to any other. The quality bar: - **Multi-entry queryability** - the same data must be reachable by problem, tool, expert, project, or decision - **Cross-dimension connectivity** - every entity is a first-class node, not buried inside another entity's prose - **Maintainability** - adding a new decision must not require re-tagging across the entire graph - **Agent-readiness** - structured enough that an agent can pull adjacent context Non-negotiables: *multi-entry queryability* and *cross-dimension connectivity*. Without those, this is just an ADR log with extra fields. Steward candidates: the senior engineers who already track tool usage and expertise informally - the same brokers who emerged in the ADR log act. ### Knowledge methodology matching A linked-database pattern following the [[Expertise Radar]] convention - one database per entity (problems, tools, experts, projects, decisions), cross-referenced. The discipline: - Every decision tagged with its problem (one-to-one or one-to-many) - Every decision tagged with the tools considered (the *with* axis - many-to-many) - Every expert tagged with the projects they led and the tools they have hands-on experience with - Every problem tagged with the projects where it appeared - Querying by traversal - pick any starting node, walk the graph The method exists independently of any specific tool. Linked databases in Notion, page properties in Confluence, the graph plugin in Obsidian - the pattern is the contract. ### Tool (illustrative, after the workshop) [[Notion]] with linked databases - relations between Problems, Tools, Experts, Projects, and Decisions; queryable from any entry; comfortable for non-engineers to read; in the same workspace as task management. The same workshop would land on a different tool if the room's non-negotiables included offline-first ([[Obsidian]] with graph plugins) or compliance-grade audit trail (a more rigid DMS).