A worked example of [[Build a Shared Brain|building a shared second brain]] at organisational scale, traced through [[Knowledge mapping|the three steps]]: decompose what a question depends on, place each piece in its container and judge its state, then match a method. The case is [[Experts Hub]] at [[Brainhub]] - what it took to answer, from one shared graph, *how do we solve our clients' typical problems, with which tools, and who did it* - across every project. ![[Shared second brain example - Experts Hub.canvas]] ## Summary 1. Prompt *"Marketing is building a new website and asks: point out how we solve clients' typical business problems, with which tools, and who the experts are."* - a question that needs four things, each kept somewhere else 2. Four entities, four owners, no join: business **problems** (Sales, 🟠 stale), **tools** and domains (Engineering, 🟡 ambiguous), **projects** (Delivery, 🟡 scattered docs + 🟣 tacit), **experts** - the actual people - with 🔴 no register; and nothing links problem↔tool↔project↔person (🔴), so the answer lives only in heads 3. Promote the four to first-class, cross-referenced entities in one linked graph ([[Expertise Radar]]), single-sourced and **stewarded** - productised as [[Experts Hub]] under a named [[Tech Evangelist]] 4. [implementation] [[Notion]] linked databases, or [[Obsidian]] with [[AI agent|agents]] ^summary ## The steps in one line each Prompt *"how do we solve clients' typical problems, with which tools, by whom?"* decomposes into, per project, a **problem we solved** - which is itself a join of a **business problem**, the **tool(s)** used, the **project** it ran on, and the **expert** who did it. The thing the question wants - the link across all four - is written nowhere; each entity sits in a different silo. ^trail-line Where each piece lives - four entities, four owners, no join: **problems** held by Sales, 🟠 stale; **tools** (and domains) by Engineering, 🟡 ambiguous; **projects** by Delivery, 🟡 across scattered docs and 🟣 tacit; **experts** - the actual people - have 🔴 no register at all. Worse, nothing links problem↔tool↔project↔person: that relation is 🔴 absent, alive only in heads. A sales-support [[AI agent|agent]] asked the prompt cannot assemble a single answer. ^profile-line Promote problems, tools, projects, and experts to first-class, cross-referenced entities in one linked graph ([[Expertise Radar]]) - **refresh** the stale problems, **single-source** the ambiguous tools, **consolidate** the scattered projects, **author** the missing expert register, and **link** every solved-problem to its problem, tool, project, and person. Single-sourced and stewarded; productised as [[Experts Hub]] under a named [[Tech Evangelist]], the domains the website needs first. ^method-line ## Full walkthrough ### Knowledge dependency mapping Start from the real request. Marketing is building a new website and comes to engineering: *"Point out how we solve our clients' typical business problems - with which tools - and who the experts are, so we can show it."* The ask is literally [[Ostension|ostensive]] - *point at it* - and that is the tell: nothing is written to hand over. Decompose what answering it depends on: - per project, a **problem we solved** - the unit the website wants to showcase; - which is itself a **join** of four things: - the **business problem** - the client need, in business terms; - the **tool(s)** used to solve it - and the **domain** it sat in; - the **project** it ran on; - the **expert** - the actual person who did the work. Traced down, the cone does not bottom out in one place. The centre is a *relationship* - "this problem, solved with this tool, on this project, by this person" - and each of its four ends is a separate entity. Where each lives, and whether anything ties them together, is the next step. ### Knowledge container mapping Place each entity in the container that actually holds it - and the owners turn out to be different departments: - **Business problems** - held by **Sales**, in old pitch material: written, but 🟠 stale (the list lags what delivery actually does now). - **Tools** (and the **domains** they apply to) - held by **Engineering**: present, but 🟡 ambiguous - no single source, spread across repos, threads, and memory. - **Projects** - held by **Delivery**: 🟡 scattered across different per-project docs, and 🟣 tacit where the docs stop. - **Experts** - the actual people who did the work: 🔴 there is no register at all; you find them by asking around. And the centre - the **join** that says *which* problem was solved with *which* tool on *which* project by *whom* - lives in no container: 🔴 absent, reconstructed from memory each time. Four entities, four owners, many layers of separation, and the one thing the question needs - the link across them - written nowhere. Re-walk the cone as a sales-support [[AI agent|agent]]: it cannot point or ask, and with the join absent and the leaves stale, ambiguous, or unregistered, it cannot assemble a single honest answer. That gap is the headline finding. ### Knowledge method matching The colours name the moves; they converge on one structure - a single linked graph with an owner: - 🟠 stale problems → **refresh** them with Delivery's current reality; - 🟡 ambiguous tools (and domains) → **single-source** into one queryable list; - 🟡 scattered + 🟣 tacit projects → **consolidate** into project entities; - 🔴 absent experts → **author** an expert register; - 🔴 absent join → **link** every solved-problem to its problem, tool, project, and person, so the relationship is first-class and traversable from any node. The moves converge on the [[Expertise Radar]] pattern - one database per entity (problems, tools, domains, projects, experts), cross-referenced, with the *solved-problem* as the relation joining them. Productised, this is [[Experts Hub]]: the linked graph as structural core, single-sourced, under a named [[Tech Evangelist]] accountable for keeping it current - serving the website now, and Sales and candidates next. Scope it to the domains the website needs first; decouple the long tail. ### Tool (illustrative, after the workshop) [[Notion]] linked databases - relations between Problems, Tools, Domains, Projects, and Experts, queryable from any entry and comfortable for non-engineers to read; living in the same workspace as delivery and sales material so the graph feeds the website and proposals directly. Where the room wanted richer natural-language querying, the same method would land on [[Obsidian]] with [[AI agent|agents]] over a plain-text, linked graph instead - same discipline, different surface.