Le goulot d'étranglement du cerveau du fondateur
Dans les premiers jours, le cerveau du fondateur est le système d'exploitation de l'entreprise. Chaque décision, chaque élément de contexte, chaque leçon tirée d'une expérience ratée vit dans la tête d'une seule personne. Cela fonctionne quand il y a deux ou trois personnes dans une pièce. Cela s'effondre rapidement.
Considérons les chiffres. Une équipe de 3 personnes a 3 canaux de communication. Une équipe de 10 en a 45. Une équipe de 25 en a 300. À mesure que les canaux se multiplient, le fondateur devient le seul nœud qui détient la vision d'ensemble. Les gens commencent à planifier des "synchronisations rapides" pour extraire du contexte. Les décisions stagnent parce qu'une personne n'a pas encore donné son avis.
Une enquête Loom de 2023 a révélé que les travailleurs du savoir perdent en moyenne 5,3 heures par semaine à attendre des informations de leurs collègues. Dans les startups, le goulot d'étranglement est encore plus marqué car une grande partie du contexte non documenté réside dans la tête du fondateur. La recherche de McKinsey le formule autrement : les employés consacrent 19 % de leur semaine de travail à chercher et rassembler des informations. C'est presque une journée entière, chaque semaine, à chercher des choses que quelqu'un sait déjà.
Ce n'est pas un problème de processus. C'est un problème d'architecture des connaissances. Le fondateur a construit un brillant système de gestion des connaissances personnelles, un système qui fonctionne pour un opérateur individuel. Passer à l'échelle nécessite quelque chose de fondamentalement différent.
Pourquoi le PKM personnel ne fonctionne pas pour les équipes
Le cadre Building a Second Brain de Tiago Forte, le système PKM le plus populaire avec plus de 100 000 diplômés de son cours, a été conçu pour les individus. La méthode CODE (Capturer, Organiser, Distiller, Exprimer) suppose un utilisateur unique avec un ensemble unique de priorités. Le cadre PARA (Projets, Domaines, Ressources, Archives) organise l'information autour des responsabilités d'une seule personne.
C'est la bonne approche pour construire un second cerveau. Mais les systèmes PKM personnels ont trois problèmes structurels lorsqu'ils sont appliqués aux équipes.
| Dimension | Second cerveau personnel | Cerveau partagé |
|---|---|---|
| Organisateur | Une personne décide de ce qui compte | Le groupe curate collectivement |
| Accès | Privé par défaut | Transparent par défaut |
| Structure | Organisé par projets personnels (PARA) | Organisé par domaines d'équipe et décisions |
| Incitation | Amélioration personnelle | Réduire la dépendance envers une seule personne |
| Source de capture | Lecture et expérience individuelles | Lecture partagée, réunions, expériences, échecs |
| Découverte | Recherche personnelle et liens | Recherche à l'échelle de l'équipe, recommandations, sérendipité |
| Maintenance | Discipline d'une personne | Normes culturelles et propriété partagée |
Premièrement, les systèmes personnels sont opaques. Votre base de données Notion, votre coffre-fort Obsidian, vos surlignages Readwise : personne d'autre ne peut les voir. Le savoir s'accumule pour vous mais ne crée aucun effet de levier pour votre équipe. Deuxièmement, les taxonomies personnelles ne se transfèrent pas. Votre structure de dossiers a du sens pour vous. Elle n'en aura pas pour quelqu'un d'autre. Troisièmement, le PKM personnel optimise la créativité individuelle. Les équipes ont besoin de systèmes de connaissances qui optimisent la coordination, la cohérence et la rapidité.
Le passage du personnel au partagé ne consiste pas à choisir un outil différent. Il s'agit de changer la valeur par défaut du privé au public, de la curation individuelle à la curation collective, des projets personnels au contexte partagé.
Les 3 phases de la mise à l'échelle des connaissances
La mise à l'échelle des connaissances n'est pas linéaire. Elle progresse par phases distinctes, et ce qui fonctionne dans une phase entrave activement la suivante. Comprendre ces transitions est ce qui sépare les fondateurs qui passent efficacement à l'échelle de ceux qui se noient dans les coûts de coordination.
Phase 1 : Solo (1-5 personnes)
À ce stade, le savoir vit dans les cerveaux et les conversations. Tout le monde est dans la même pièce (ou le même canal Slack) et absorbe le contexte par proximité. La documentation est minimale car elle n'a pas besoin d'exister. On peut simplement taper sur l'épaule de quelqu'un.
Ce qui fonctionne : Favoris partagés, un seul canal Slack, brefs comptes-rendus oraux, un document partagé léger pour les décisions.
Ce qui ne tient plus : Rien, pour l'instant. Cette phase semble efficace car la surcharge de communication est quasi nulle.
Phase 2 : Équipe (5-25 personnes)
C'est là que le goulot d'étranglement du cerveau du fondateur frappe. Les nouvelles recrues ne peuvent plus absorber le contexte par osmose. Les gens commencent à poser les mêmes questions à répétition. Des décisions sont prises lors de conversations auxquelles la moitié de l'équipe n'assiste pas.
Ce qui fonctionne : Culture de l'écriture (documents de décision, processus RFC), annotation et surlignage à l'échelle de l'équipe, bases de connaissances légères, documentation d'intégration.
Ce qui ne tient plus : Slack devient un fleuve de bruit. Le fondateur ne peut pas assister à chaque réunion. Des silos de connaissances émergent entre les fonctions.
Phase 3 : Organisation (25+ personnes)
À cette échelle, la culture détermine si le savoir circule ou stagne. Il faut des systèmes, des normes et des incitations explicites. La documentation n'est pas optionnelle ; c'est une infrastructure.
Ce qui fonctionne : Culture du manuel en premier (comme GitLab), bases de connaissances structurées avec des propriétaires, groupes de lecture inter-équipes, synthèse des connaissances par IA, programmes formels d'intégration.
Ce qui ne tient plus : Tout ce qui n'a pas été écrit. Chaque processus qui vivait dans la tête de quelqu'un. Chaque décision dont la justification n'a jamais été enregistrée.
| Facteur | Phase 1 (1-5) | Phase 2 (5-25) | Phase 3 (25+) |
|---|---|---|---|
| Transfert de connaissances | Conversation | Documents + conversation | Systèmes + culture |
| Documentation | Optionnelle | Importante | Infrastructure critique |
| Registres de décision | Notes mentales | Mémos légers | RFC/ADR formels |
| Durée d'intégration | 1-2 jours | 1-2 semaines | 1-3 mois |
| Culture de lecture | Partage informel | Listes de lecture d'équipe | Annotation partagée + synthèse |
| Rôle de l'IA | Assistant personnel | Synthétiseur d'équipe | Graphe de connaissances organisationnel |
| Risque principal | Aucun (trop petit) | Goulot du fondateur | Silos de connaissances, déclin du wiki |
La transition la plus difficile est de la Phase 1 à la Phase 2. Les fondateurs y résistent parce qu'écrire semble lent par rapport à parler. Mais les chiffres sont implacables. Une conversation de 30 minutes transfère le savoir à 3 personnes. Un document de 30 minutes transfère le savoir à chaque personne qui rejoint l'entreprise, pour toujours.
La culture de l'écriture comme infrastructure du savoir
Les entreprises les plus efficaces dans la mise à l'échelle des connaissances partagent un trait commun : elles traitent l'écriture comme une infrastructure centrale, pas comme un ajout. Il ne s'agit pas de grammaire ou de style. Il s'agit d'utiliser les documents écrits comme le principal vecteur pour penser, décider et préserver le contexte.
Jeff Bezos l'a compris très tôt. Dans un e-mail désormais célèbre de 2004 à son équipe de direction, il a interdit les présentations PowerPoint lors des réunions exécutives et les a remplacées par des mémos narratifs de six pages. Les participants passent les 20 premières minutes de chaque réunion à lire le mémo en silence avant que la discussion ne commence.
Bezos a expliqué son raisonnement dans une lettre de 2018 aux actionnaires : "La raison pour laquelle écrire un bon mémo de 4 pages est plus difficile qu'écrire un PowerPoint de 20 pages est que la structure narrative d'un bon mémo force une meilleure réflexion et une meilleure compréhension de ce qui est plus important que quoi." Le format mémo force l'auteur à réfléchir complètement à son argumentation. Les puces permettent de masquer une pensée approximative derrière un ton assuré.
Cette pratique s'est déployée dans tout Amazon depuis plus de deux décennies. Elle fonctionne parce que les mémos créent un artefact. La réflexion est capturée, pas seulement la conclusion. Un nouvel employé qui rejoint une équipe peut lire les mémos qui ont façonné les décisions passées et comprendre non seulement ce qui a été décidé, mais pourquoi.
La culture de l'écriture se capitalise. Chaque document s'ajoute au cerveau partagé de l'organisation. Chaque mémo devient un point de référence. Au fil du temps, l'entreprise développe une mémoire institutionnelle qui ne dépend de la mémoire d'aucune personne en particulier.
Études de cas : Amazon, Stripe et GitLab
Trois entreprises illustrent différentes approches de la mise à l'échelle des connaissances, chacune réussie, chacune adaptée à des philosophies organisationnelles différentes.
Amazon : Le mémo de six pages
La culture du mémo chez Amazon est l'exemple le mieux documenté de l'écriture comme infrastructure du savoir. Au-delà du mémo exécutif, Amazon utilise une hiérarchie de documents écrits : des documents d'une page pour les petites décisions, de six pages pour les initiatives majeures, des documents PR/FAQ pour les propositions de nouveaux produits (où l'on rédige le communiqué de presse avant de construire le produit).
Colin Bryar et Bill Carr, anciens dirigeants d'Amazon, ont détaillé ce système dans leur livre de 2021 Working Backwards. Ils notent que le processus PR/FAQ oblige les équipes à articuler le bénéfice client avant d'écrire une seule ligne de code. Les documents s'accumulent et deviennent une archive consultable de la pensée organisationnelle.
Stripe : La documentation comme qualité produit
Stripe a construit l'une des suites de documentation pour développeurs les plus admirées dans la tech. Mais ses pratiques internes de gestion des connaissances sont tout aussi rigoureuses. Patrick Collison, cofondateur de Stripe, a publiquement défendu une forte culture de l'écriture. Stripe utilise largement l'e-mail interne pour les communications longues, et les nouveaux employés sont encouragés à écrire sur ce qu'ils apprennent pendant leur intégration.
Dans une interview de 2019, Collison a décrit l'embauche d'un "ingénieur documentation" dont le travail consistait exclusivement à améliorer l'accessibilité des connaissances internes. Stripe traite les documents internes avec le même soin que sa documentation publique d'API. Le résultat : les nouveaux ingénieurs livrent du code significatif dès leur première semaine parce que le contexte dont ils ont besoin est écrit et trouvable.
GitLab : L'entreprise du manuel d'abord
GitLab a poussé l'externalisation des connaissances plus loin que presque toute autre entreprise. Leur manuel public dépasse 2 000 pages et couvre tout, de la conduite des entretiens individuels à la position de l'entreprise sur le travail à distance. En 2024, le manuel comptait plus de 15 000 contributions fusionnées de centaines de membres de l'équipe.
Le principe "manuel d'abord" de GitLab est explicite : si l'information n'est pas dans le manuel, elle n'existe pas en tant que politique. Darren Murph, ancien responsable du travail à distance chez GitLab, a écrit abondamment sur cette approche. Chaque changement de processus commence par une merge request vers le manuel. Cela signifie que les décisions sont versionnées, consultables et transparentes pour chaque employé à travers le monde.
Le coût est réel. Maintenir plus de 2 000 pages demande un effort considérable. GitLab y répond en faisant de la maintenance du manuel la responsabilité de chacun, pas celle d'une équipe dédiée. Quand vous découvrez une information obsolète, on s'attend à ce que vous la mettiez à jour, de la même manière qu'un développeur corrige un bug qu'il trouve.
Les deux modes d'échec : Le piège Slack et le cimetière du wiki
La plupart des équipes qui tentent de construire un cerveau partagé échouent de l'une de deux manières prévisibles. Reconnaître ces schémas tôt fait la différence entre un système de connaissances florissant et une perte de temps coûteuse.
Le piège Slack
Slack (ou Teams, ou Discord) donne l'impression de partager des connaissances. Les gens posent des questions, d'autres répondent, des liens circulent. Mais le chat est un flux, pas un répertoire. L'information entre par le haut et défile vers l'oubli.
Une étude de 2022 du Social Technologies Lab de Cornell University a révélé que les travailleurs dans les organisations à forte utilisation de Slack passent en moyenne 77 minutes par jour à lire et répondre aux messages dans les canaux. Le retour sur cet investissement en temps est faible parce que les conversations en chat sont mal indexées, manquent de structure et perdent leur contexte en quelques jours.
Le piège Slack est séduisant parce qu'il ne demande aucun effort initial. Personne n'a besoin d'écrire un document, de créer une page wiki ou de catégoriser des informations. Mais le coût en aval est énorme. Les mêmes questions reçoivent des réponses à répétition. Le contexte des discussions importantes s'évapore. Les nouvelles recrues ne peuvent pas reconstituer le raisonnement derrière les décisions passées parce qu'il est enfoui dans un canal avec 10 000 messages.
La solution : Utilisez le chat pour la coordination, pas pour la documentation. Toute décision, tout insight ou toute question récurrente qui émerge dans Slack devrait être capturée dans un système persistant et consultable dans les 24 heures.
Le cimetière du wiki
Le mode d'échec opposé : l'équipe lance un wiki (Confluence, Notion, Slite) avec beaucoup d'enthousiasme. Des pages sont créées. Des modèles sont conçus. Pendant trois semaines, c'est vivant. Puis l'activité chute. Les pages deviennent obsolètes. Les nouvelles recrues découvrent le wiki, lisent des informations périmées et apprennent à s'en méfier. En six mois, plus personne ne l'utilise.
La propre recherche d'Atlassian reconnaît ce problème. Leur rapport State of Teams de 2023 a révélé que 60 % des connaissances organisationnelles sont stockées dans des endroits que la plupart des employés ne peuvent pas facilement consulter ou ne connaissent pas. Les wikis meurent parce qu'il leur manque trois choses : une propriété claire (qui met à jour cette page ?), des cycles de révision (quand vérifions-nous l'exactitude ?) et une intégration dans les flux de travail quotidiens (est-il plus facile de mettre à jour le wiki ou de simplement répondre dans Slack ?).
La solution : Attribuez des propriétaires à chaque domaine de connaissances. Planifiez des revues trimestrielles. Faites du wiki la réponse par défaut aux questions récurrentes, et orientez réellement les gens vers lui au lieu de répondre directement.
Construire une culture de lecture partagée
L'une des stratégies les plus sous-utilisées pour construire un cerveau partagé est la lecture partagée. Quand une équipe lit les mêmes articles, regarde les mêmes conférences et discute des mêmes idées, elle construit un vocabulaire commun et des modèles mentaux partagés.
C'est là que l'intelligence collective commence. Les recherches d'Anita Woolley à Carnegie Mellon ont démontré que l'intelligence de groupe ne repose pas sur les individus les plus brillants. Elle repose sur le contexte partagé et la capacité à construire sur la pensée de chacun. Une équipe qui lit et annote ensemble développe exactement ce type de contexte partagé.
Le problème avec la plupart des cultures de lecture est la friction. Envoyer un lien dans Slack est facile. Faire en sorte que cinq personnes le lisent réellement, surlignent les passages qu'elles trouvent intéressants et partagent leurs perspectives ? C'est difficile sans les bons outils.
C'est là que le surlignage social change la donne. Des outils comme le surligneur web de Glasp permettent aux équipes de voir ce que chacun a trouvé le plus important dans un article, sans avoir besoin de planifier une réunion pour en discuter. Un fondateur peut surligner les passages clés d'un rapport sectoriel et toute son équipe obtient ce contexte curé via le flux communautaire. L'équipe peut répondre avec ses propres surlignages et notes, créant une discussion asynchrone autour de la lecture partagée.
La pratique s'adapte naturellement à l'échelle. Cinq personnes surlignant le même article génèrent un résumé curé de ce qui compte le plus. Vingt personnes créent une couche d'annotation riche et multiperspective. C'est le principe d'apprendre en public appliqué aux équipes : quand le travail de la connaissance est visible, tout le monde apprend plus vite.
YouTube Summary étend cela au contenu vidéo. Au lieu de demander à cinq personnes de regarder une conférence de 45 minutes, l'équipe peut partager un résumé généré par l'IA et annoter les sections clés. Cela transforme la consommation passive de vidéo en construction active de savoir partagé.
Synthèse des connaissances par l'IA
La prochaine évolution du cerveau partagé n'est pas simplement une meilleure documentation. C'est l'IA qui synthétise tout ce qu'une équipe a lu, surligné et discuté.
Considérons ce qui est possible aujourd'hui. Une équipe de 15 personnes surligne collectivement 200 articles par mois. Chacun capture des passages différents en fonction de son expertise et de ses centres d'intérêt. Sans IA, connecter ces surlignages exige que quelqu'un lise tout manuellement. Avec l'IA, un système peut identifier des schémas dans les surlignages de l'équipe : thèmes récurrents, contradictions entre sources, tendances émergentes que plusieurs membres de l'équipe ont remarquées indépendamment.
Le chat IA de Glasp fait déjà une version de cela au niveau individuel. Vous pouvez poser des questions sur vos surlignages et obtenir des réponses synthétisées à partir de tout ce que vous avez sauvegardé. L'application en équipe est l'étape logique suivante : interroger l'ensemble du savoir collecté par votre équipe.
Cela compte parce que le savoir organisationnel est dispersé par nature. Le marketing lit des articles différents de l'ingénierie. Le fondateur lit des analyses sectorielles que l'équipe produit ne voit jamais. La synthèse par IA ne remplace pas le jugement humain. Elle crée des connexions qu'aucune personne seule n'a la bande passante pour faire manuellement.
Thomas Malone, directeur du MIT Center for Collective Intelligence, appelle cela le modèle "superesprit" : l'intelligence humaine amplifiée par l'intelligence artificielle. Dans son livre de 2018 Superminds, il soutient que les organisations les plus efficaces seront celles qui conçoivent des systèmes hybrides où les humains apportent le jugement et la créativité tandis que les machines gèrent la reconnaissance de patterns et la synthèse à grande échelle.
Pour les fondateurs qui passent du savoir personnel au savoir partagé, l'IA est le pont. Elle vous permet d'exporter vos surlignages et de les agréger avec les contributions de votre équipe, puis d'interroger l'ensemble combiné. Le second cerveau personnel du fondateur ne disparaît pas. Il devient un nœud dans un réseau plus vaste.
Comment construire un cerveau partagé dès le premier jour
Vous n'avez pas besoin d'attendre que la mise à l'échelle des connaissances devienne douloureuse. Le meilleur moment pour établir des pratiques de cerveau partagé est avant d'en avoir besoin. Voici une séquence pratique.
Semaine 1 : Définissez le paramètre par défaut sur public. Chaque document, note et registre de décision devrait être visible par toute l'équipe sauf s'il y a une raison spécifique de confidentialité. Créez un espace de travail partagé (Notion, Coda ou un simple dossier Google Drive) et faites-en le lieu canonique de tous les artefacts écrits.
Semaine 2 : Lancez une pratique de lecture partagée. Choisissez un article ou une vidéo par semaine pertinent pour le domaine de votre équipe. Tout le monde le lit. Tout le monde surligne les parties jugées les plus importantes avec le surligneur web de Glasp. Consacrez 15 minutes à discuter des surlignages de manière asynchrone ou lors d'un bref échange synchrone. Vous pouvez aussi utiliser l'import Kindle pour intégrer les surlignages de livres que l'équipe lit ensemble.
Semaine 4 : Rédigez votre premier document de décision. La prochaine décision importante que votre équipe affronte, écrivez-la au lieu de simplement en discuter. Incluez le contexte, les options envisagées, les compromis et la décision finale. Sauvegardez-le dans un endroit permanent et consultable. Cela crée la première entrée de votre mémoire institutionnelle.
Mois 2 : Établissez des propriétaires de connaissances. Pour chaque domaine majeur de votre entreprise (produit, clients, marché, technologie), désignez quelqu'un responsable de maintenir le savoir partagé à jour. Cela ne signifie pas que cette personne rédige tout. Cela signifie qu'elle s'assure que l'information reste actuelle.
Mois 3 : Introduisez la synthèse par IA. Connectez les surlignages et documents de votre équipe à une couche d'IA capable de répondre aux questions sur l'ensemble de la base de connaissances. Commencez petit : "Qu'avons-nous appris sur l'intégration des clients à partir de nos lectures et expériences ce trimestre ?"
Mois 6 : Auditez et élaguez. Passez en revue votre cerveau partagé. Qu'est-ce qui est utilisé ? Qu'est-ce qui est obsolète ? Quelles questions les nouvelles recrues ont-elles encore du mal à résoudre ? L'audit révèle les lacunes de votre système de connaissances et vous aide à concentrer l'effort de maintenance là où cela compte le plus.
Le principe clé : construisez l'habitude avant que le besoin ne devienne urgent. Une équipe qui commence à documenter et partager le savoir à 5 personnes passera sans difficulté à 25. Une équipe qui attend jusqu'à 25 passera des mois à rattraper son retard tout en perdant du savoir institutionnel en chemin.
Foire aux questions
En quoi un "cerveau partagé" diffère-t-il d'un wiki d'entreprise classique ?
Un wiki est un outil. Un cerveau partagé est un système qui inclut des outils, des pratiques et une culture. La plupart des wikis échouent parce qu'ils sont traités comme un endroit où déverser de l'information plutôt que comme un système vivant avec une propriété claire, une maintenance régulière et une intégration dans les flux de travail quotidiens. Un cerveau partagé comprend également la lecture partagée, l'annotation sociale, les registres de décision et la synthèse par IA de l'ensemble de ces données. Le wiki peut être un composant, mais il n'est pas l'ensemble du tableau.
Quelle est la taille minimale d'équipe à partir de laquelle le PKM personnel ne fonctionne plus ?
La transition devient généralement nécessaire entre 5 et 8 personnes. En dessous de 5, la plupart des équipes peuvent fonctionner avec la conversation et le contexte partagé du travail en proximité. Au-delà de 5, les canaux de communication se multiplient assez vite pour que l'information commence à se perdre. Si vous embauchez quelqu'un qui n'est pas dans la même pièce que les fondateurs, vous avez besoin de pratiques de savoir partagé quelle que soit la taille de l'équipe.
Comment amener une équipe à effectivement consigner les choses ?
L'approche la plus efficace consiste à faire de l'écriture le chemin de moindre résistance. Chez Amazon, on ne peut pas obtenir de réunion avec la direction sans un mémo écrit. Chez GitLab, si ce n'est pas dans le manuel, ce n'est pas une politique. Le principe est le même : créer des structures où l'écriture est requise pour les choses que les gens veulent déjà faire (faire prendre des décisions, obtenir des réponses, faire approuver des projets). La reconnaissance aide aussi. Célébrez et référencez publiquement les bons documents.
L'IA peut-elle remplacer le besoin d'une culture de l'écriture ?
Pas encore, et probablement jamais complètement. L'IA peut résumer des réunions, synthétiser des surlignages et répondre à des questions sur des documents existants. Mais elle ne peut pas remplacer la réflexion que l'écriture vous force à mener. Rédiger un document de décision ne concerne pas le document lui-même. Il s'agit pour l'auteur de travailler le problème assez clairement pour l'expliquer aux autres. L'IA est un puissant complément à la culture de l'écriture, pas un substitut. Elle rend le savoir existant plus accessible, mais quelqu'un doit encore créer ce savoir.
Comment empêcher notre base de connaissances partagée de devenir un cimetière ?
Trois pratiques préviennent la dégradation. Premièrement, attribuez des propriétaires explicites à chaque domaine de connaissances. Une page sans propriétaire est une page qui va pourrir. Deuxièmement, planifiez des revues trimestrielles où les propriétaires vérifient que leurs sections sont à jour. Troisièmement, intégrez la base de connaissances dans le travail quotidien. Quand quelqu'un pose une question dans Slack dont la réponse se trouve dans la documentation, partagez le lien vers la documentation au lieu de répondre directement. Cela renforce l'habitude de consulter d'abord la documentation et révèle quand elle est manquante ou obsolète.
Conclusion : Commencez avant d'en avoir besoin
La transition du second cerveau au cerveau partagé est l'un des défis les plus déterminants auxquels une entreprise en croissance fait face. Les fondateurs qui le gèrent bien le font en reconnaissant que le savoir est une infrastructure, pas une charge. Ils investissent tôt dans la culture de l'écriture, construisent des pratiques de lecture partagée, attribuent la propriété du savoir et utilisent l'IA pour synthétiser les contributions collectives de leur équipe.
Vous n'avez pas besoin d'être à 100 employés pour commencer. En fait, commencer tôt est justement l'enjeu. Les meilleurs cerveaux partagés se construisent progressivement, une décision documentée à la fois, un surlignage partagé à la fois, un article annoté à la fois.
Si votre équipe lit ensemble, surligne ensemble et construit sur la pensée de chacun, vous êtes déjà en train de bâtir quelque chose de plus puissant que n'importe quel second cerveau individuel.
Commencez par surligner un article avec Glasp et le partager avec votre équipe. Ce simple geste, rendre votre lecture visible, est le premier pas du second cerveau au cerveau partagé.