Virksomhedens anden hjerne: fra wiki til færdigheder, det handler om kontekst8 min read

Jeg har tænkt meget over al hypen omkring “second brain”. Jeg diskuterede dette med andre i feltet og mine kolleger, som enten er ved at bygge en anden hjerne eller har en version af den.

For dem, der ikke kender, startede den anden hjernebevægelse med “Wiki”-ideen af ​​Andrej Karpathy: organisering af agentens personlige viden i en slags sammenkædet Wiki-struktur af lokale MD-filer. Dette udvidede senere til at organisere personlige data i et meget bredere format, hvor brugere ofte brugte Obsidian til at organisere og visualisere noter og tilføje data fra møder (Granola/Whisperflow/Zoom-transskriptioner) til Wiki.

rocket-karpathy-viden-baser: start

raket-karpathy-viden-baser: ende

Efterhånden som “Wiki” blev udvidet, blev det tydeligt, at der er en vis værdi i at dele informationen i den. Således begyndte “virksomhedens anden hjerne”-projekter at blomstre. Den utopiske version af en anden hjerne får alt muligt transskriberet: zoom-opkald, F2F-møder, endda tilfældige interaktioner, e-mails, slappe beskeder, dokumenter – alt sammen til en enorm datadatabase som Snowflake. Forestil dig, at enhver i virksomheden kan spørge denne Snowflake-instans om hvad som helst, de vil, og med det samme få svar på alle spørgsmål.

Hov, ikke en god idé. For det første er dette super dyrt. Mængden af ​​data, der går ind i sådan noget, er bare vanvittig, og det bliver ekstremt vanskeligt, langsomt og dyrt at hente data fra det. Sikkerhed og dataadskillelse bliver et problem. Hvordan forhindrer du, at 1:1 personlige data, økonomiske data, ledelsesbeslutninger, HR-data eller endda beslutninger om at stoppe nogen glider ind i udskrifterne og er tilgængelige. Ikke alle burde ved alt…

Og hvem har brug for dette, hvad redder det os, og er det overhovedet en god idé?

Generelt vil jeg sige, at en indeholdt version af dette er en god idé. Meget af grunden til, at mellemledelsen eksisterer, er at flyde spørgsmål opstrøms og afklare beslutninger nedstrøms. Meget af dette kan nu gøres med en anden hjerne.

Anden hjerne for tekniske teams

En teknisk anden hjerne kan være meget nemmere at vedligeholde. Mange virksomheder bruger bare en Dropbox/Google-drev/OneDrive-mappe, der rummer delt viden, som Claude/Codex kan dele. Automatisering til at skubbe dette til en Git-repo er ret simpel, eller du kan virkelig også bruge Github til at administrere dette (jeg gætter på, at det er en meget lille indsats for OpenAI/Anthropic at understøtte dette scenarie uden at skulle installere brugerdefinerede færdigheder for at administrere denne type ting). Sandhedens kilde bliver nu Github-reposen, og de lokale kopier er lokale git-reposer.

Dette kan tilføje viden og kapaciteter som delte færdigheder, fælles beslutninger, arkitektoniske designs, visuelle designs (designsystembeslutninger, for eksempel) og forskellige andre virksomhedsproduktbeslutninger.

Små teams har egentlig ikke brug for meget ud over blot en simpel synkronisering omkring repoen, men større virksomheder med adskillige større teams vil meget hurtigt løbe ind i alvorlige begrænsninger. De mest alvorlige problemer involverer kontekstforgiftning, hvor en bestemt bruger kan træffe lokale beslutninger, der er i konflikt med den anden hjernedata, enten ved at introducere modstridende data eller tilsidesætte virksomhedens beslutninger utilsigtet (i nogle tilfælde måske med vilje?).

At holde det i git og flette kan gøres ved hjælp af en dedikeret agent, der leder efter konflikter og kan advare en bruger, hvis deres ændringer er modstridende, løse konflikter og flette resultaterne.

Bemærk, at dette ikke er en god metode til at vedligeholde projektdokumentation. Til det er den bedre måde at inkludere wikien som en integreret del af selve projektet. Det er ret nemt at skabe. Du sætter bare en kodningsagent til side og beder den om at gennemgå projektet, dokumentere det grundigt i en docs-mappe, opdelt efter arkitektur, gotchas, produktbeslutninger, tekniske beslutninger og andre ting, som den konkluderer kan være nyttige i små md-filer, der kan indeholdes. Nøglen er at fortælle det for at sikre, at koden og readme.md alle peger på dokumentbiblioteket for at sikre, at det refereres overalt og betragtes som en del af projektet og ikke en ekstern ressource. Nøglen for agenten at vide er, at hensigten her er at tillade en hurtig onboarding af en anden agent til projektet for at undgå faldgruber, huller og tekniske synkehuller…

Når det først er integreret i selve repo-projektstrukturen, vil kodningsagenten vedligeholde det, som om det var kode. Det vil læse det, som om det var en del af koden, og hvis noget ændrer sig, vil det tilpasse eller modificere dokumentationen (husk disse “dokumentation er, at koden er nem at læse og overskue” eller “dokumentation bliver forældet i det øjeblik, den forlader dit tastatur” – stol på, at AI’en vedligeholder disse, så de er ikke sande længere).

Anden hjerne for produkt-, marketing- og ikke-tekniske teams

Denne type anden hjerne kan være rigtig cool for tekniske teams, men at gøre det samme for ikke-tekniske teams vil være ekstremt svært.

Tag et team af advokater for eksempel, de har meget specifikke vidensæt, og det spænder over e-mail, slack, word-filer og andre dokumenter. Det samme gælder bogholdere, salg, kundesucces osv. De har hver deres anden hjerneviden.

Oven i dette vil ledelsen sandsynligvis have data til at boble op (ufiltreret via mellemledelsen), og teamet har muligvis brug for information, som ledelsen har genereret. Hvordan producerer man en skalerbar vidensgraf, der er sikret og adskilt?

Der er et par tilgange, der kunne gøre tingene lettere, i det mindste indtil de store drenge løser dette problem, forhåbentlig på en åben måde, men mere sandsynligt gennem en dyr lukket løsning.

1. Personlig anden hjerne – hver person, der ønsker dette, kan transskribere deres egne møder og vedligeholde deres egen anden hjerne. Obsidian er ret nyttig til dette, ethvert middel kan stort set sortere og rense det. Brug REM-søvnmekanismen til at optimere den – en agent skal vågne om natten, identificere al den information, den har indsamlet i løbet af dagen, finde enhver information, der er kritisk og vigtig at beholde for fremtiden og organisere den på en let genfindelig måde i mapper og MD-filer. Det betyder, at hvis du har talt med en bestemt kunde, vil denne kunde få opdateret en md-fil, der afspejler information, som er vigtig at huske om dem, hvad I arbejder på sammen, osv. Det samme gælder for projekter. Der vil være overlap: overlap er godt – det er ok, at informationen om et bestemt projekt lever både i filen hos den person, du har talt med, virksomheden og projektfilerne. Lad agenten klare dette for dig. Når du har spørgsmål, skal du gøre dette til din primære datakilde for din agent. Du kan eksponere din agent for din e-mail/samtaler/osv. – bare sørg for ikke at transskribere ting, du ikke vil have dokumenteret (lad os ikke gøre dette til et realityprogram eller en sæbe).

2. Anden hjerne på holdniveau – et andet datalag omfatter data, der enten er i den personlige anden hjerne, som agenten er 100 % sikker på, er relevante for hele teamet, eller data, der stammer fra møder på teamniveau, som i sagens natur er teambaserede. En agent kan også indsamle data for denne anden hjerne fra dit teams slappe kanaler – det bør ikke være i dine 1:1-kanaler eller zoom-opkald. Når den først har hentet dataene, kan en agent organisere dem i realtid eller om natten og påpege uoverensstemmelser, hvor beslutninger blev omstødt eller ikke svarer til personlige eller ledelsesbeslutninger. Disse bør fremhæves og advares til den person, der træffer den uforenelige beslutning, så de kan træffe deres valg på en informeret måde.

3. Ledelsesniveau anden hjerne – Dette er grundlæggende en anden hjerne på teamniveau, men på grund af følsomheden af ​​de data og beslutninger, der træffes, bør det håndteres på en meget mere nuanceret måde. Kun endelige beslutninger og offentlige data bør deles her for at undgå potentielle læk i resten af ​​virksomheden. Det kan være en god idé for et menneske at gennemgå nogle af dataene, i hvert fald i begyndelsen, for at sikre datasikkerheden. Det er også en god idé at udelade ledelseshjernen fra virksomhedens anden hjerne.

4. Virksomhedsdækkende anden hjerne – dette er den sværeste og bør kun indeholde data, der er konkrete, informative, som kan være relevante for hele virksomheden. Indberettede økonomiske resultater kun, for eksempel oplysninger om personale (hvem besidder hvilken stilling).

Dette udelader en masse data, herunder sentimentdata, for eksempel, som ledelsen ønsker at høre fra hele teamet. Dette kan samles separat eller høstes fra slack og andre kilder. Det er ikke en god idé at høste denne type data direkte fra virksomhedens hjerne.

Så hvad leder du efter i en anden hjerne eller en virksomhedshjerne, havde du nogle forsøg på at bygge en, og hvad var dine konklusioner?