Home | Blog | Guide

Verloren in Slack: Suchbar ist nicht auffindbar

Ihr Team hat zu viele Slack-Kanäle und findet nichts. Warum Suche allein das nicht löst – und was wirklich hilft.

By Ellis Keane · 2026-03-17

Wie viele Slack-Kanäle hat Ihr Team gerade? Nicht die Zahl in der Seitenleiste – denn die meisten davon haben Sie stummgeschaltet. Die tatsächliche Zahl, einschließlich der Kanäle, die jemand für ein Projekt erstellt hat, das vor sechs Monaten endete, der Kanäle mit so ähnlichen Namen, dass Sie nie sicher sind, welcher der richtige ist, und der handvoll Kanäle, in denen wirklich wichtige Dinge passieren, die Sie nie wieder finden werden, weil Sie nicht wussten, dass sie gerade passierten.

Ich schätze, Sie kennen die Zahl nicht. Wir ehrlich gesagt auch nicht. Und das ist gewissermaßen der Kern der Sache.

Der Standardrat bei Slack-Kanal-Überlastung lautet: reorganisieren, Namenskonventionen einführen, nicht Benötigtes archivieren, vielleicht eine vierteljährliche Bereinigung durchführen (die Art von Ritual, die sich für etwa einen Nachmittag produktiv anfühlt und sich dann in den nächsten sechs Wochen langsam auflöst). Dieser Rat ist in Ordnung, soweit er reicht, aber er behandelt das Symptom und nicht den Mechanismus. Der Grund, warum Ihr Team zu viele Slack-Kanäle hat und nichts findet, liegt nicht darin, dass Sie schlecht in Organisation sind (naja, vielleicht ein bisschen) – es liegt daran, dass Slack für Gespräche gebaut wurde, nicht für Wissen, und die Lücke zwischen diesen beiden Dingen ist der Ort, an dem all Ihr wichtiger Kontext stirbt.

Suchbar bedeutet nicht auffindbar

Das ist der Punkt, an dem die meisten Teams stolpern. Die Slack-Suche ist eigentlich recht gut in dem, was sie tut. Sie geben ein Wort ein, es findet Nachrichten, die dieses Wort enthalten, es ordnet sie sogar nach Relevanz und lässt Sie nach Kanal, Person und Zeitraum filtern. Wenn Sie wissen, wonach Sie suchen, und ungefähr wann es passiert ist, bringt Sie die Slack-Suche ans Ziel.

Das Problem ist, dass „auffindbar" und „suchbar" grundlegend unterschiedliche Fähigkeiten beschreiben – und Slack nur eine davon bietet.

„Suchbar und auffindbar beschreiben grundlegend unterschiedliche Fähigkeiten – und Slack bietet nur eine davon." – Ellis Keane

Suchbar bedeutet: Ich habe ein bestimmtes Stichwort und möchte jede Nachricht sehen, die es enthält. Auffindbar bedeutet: Ich erinnere mich, dass ein Gespräch stattgefunden hat, ich weiß ungefähr, worum es ging, aber ich erinnere mich nicht an die genauen Worte, die jemand benutzt hat, in welchem Kanal es stattfand oder genau wann es passierte. Das zweite Szenario ist unserer Erfahrung nach für etwa 80 % der Fälle zutreffend, in denen Menschen tatsächlich versuchen, Informationen aus Slack abzurufen.

Denken Sie an das letzte Mal, als Sie versucht haben, etwas in Slack zu finden. Haben Sie ein genaues Stichwort eingegeben, oder haben Sie verschiedene Variationen ausprobiert, Kanäle durchgescrollt, DMs überprüft und schließlich jemanden gefragt: „Hey, weißt du noch, wo wir über … gesprochen haben?" Wenn es das zweite war (und ich würde echtes Geld darauf wetten, dass es das meistens ist), dann ist Slacks Suche nicht kaputt. Sie löst nur ein anderes Problem als das, das Sie eigentlich haben.

Wie Kanäle sich vermehren und Kontext zersplittert

Folgendes passiert tatsächlich in den meisten Teams, die wir beobachtet haben. Es beginnt harmlos genug: Sie erstellen Kanäle für Teams (#engineering, #design, #product), Kanäle für Projekte (#project-atlas, #project-beacon), Kanäle für Funktionen (#standup, #deployments, #incidents) und vielleicht einige soziale (#random, #watercooler). Das sind vielleicht 15–20 Kanäle, und es funktioniert wunderbar für etwa drei Monate.

Dann beginnen die Grenzen zu verschwimmen. Jemand startet in #engineering ein Gespräch über ein Deployment-Problem, das eigentlich in #incidents gehört. Eine Design-Review-Unterhaltung erstreckt sich über #design, #project-atlas und einen DM-Thread. Jemand erstellt #project-atlas-design, weil er einen speziellen Raum für Design-Feedback zu diesem Projekt möchte – und jetzt gibt es zwei Orte, an denen Atlas-Design-Entscheidungen leben könnten, und man muss am besten beide prüfen, wenn man das vollständige Bild haben möchte.

Die Kanal-Anzahl ist nicht wirklich das Problem, auch wenn es sich so anfühlt (ich kann das nicht für jedes Team beweisen, aber es hat für jedes Team gestimmt, mit dem ich darüber gesprochen habe). Das Problem ist, dass jeder Kanal zu einer isolierten Kontext-Tasche ohne Verbindungen zu den anderen Taschen wird. Ein Gespräch in #project-atlas referenziert ein Notion-Dokument, das auf ein Linear-Issue verweist, das in #engineering diskutiert wurde – und keiner dieser Verweise ist ein maschinenlesbarer Link. Es sind menschliche Abkürzungen: „wie besprochen", „laut Dokument", „als Nachfolge zu diesem Thread". Eine Person, die in all diesen Gesprächen war, kann dem Pfad folgen. Eine Person, die es nicht war – oder eine Person, die es war, sechs Monate später – schlicht nicht.

Was Namenskonventionen wirklich lösen (und was nicht)

Ich möchte Namenskonventionen nicht vollständig abtun, denn sie helfen bei einer bestimmten Sache: Sie helfen Ihnen, den richtigen Kanal zu finden, in dem Sie suchen müssen. Ein konsistentes Muster wie team-engineering, proj-atlas, func-deploys macht die Seitenleiste navigierbar. Das ist echter Mehrwert – auch wenn die Konvention ungefähr bis zur dritten Person überlebt, die das Wiki nicht gelesen hat und atlas-design-feedback statt proj-atlas-design erstellt.

Aber Namenskonventionen lösen nicht das Auffindbarkeitsproblem, denn Auffindbarkeit bedeutet nicht zu wissen, welchen Kanal man durchsuchen soll. Es geht darum, dass das Gespräch, das Sie brauchen, über drei Kanäle und einen DM verteilt ist – und keine Namenskonvention der Welt wird Ihnen das sagen. Die Informationsarchitektur von Slack ist von Natur aus flach, und diese Flachheit ist eigentlich eine ihrer Stärken für Echtzeit-Gespräche (man möchte keine Hierarchie, wenn man schnell jemanden zu einem Deployment anschreiben möchte), aber sie ist eine Katastrophe für die Informationsabfrage.

Das Problem „zu viele Kanäle" ist eigentlich ein Problem „Kontext in Kanälen eingeschlossen". Die Reduzierung der Kanalanzahl hilft bei der Navigation, löst aber nicht die zugrundeliegende Fragmentierung.

Warum Sie zu viele Slack-Kanäle haben und nichts finden können

Angenommen, Sie versuchen, das Gespräch zu finden, in dem Ihr Team entschieden hat, von REST auf GraphQL für die interne API umzustellen. So sieht das in der Praxis aus:

Sie suchen in Slack nach „GraphQL". Sie erhalten etwa 250 Ergebnisse in einem Dutzend Kanälen. Die meisten stammen aus #engineering, einige aus #random (jemand, der einen Blogbeitrag teilt), ein paar aus #project-beacon, wo jemand fragte, ob der Wechsel sie betreffen würde.

Sie grenzen auf #engineering ein. Immer noch Dutzende von Ergebnissen. Die eigentliche Entscheidung ist in keiner davon enthalten – weil Ihr leitender Ingenieur, als er sagte „machen wir das", einfach „klingt gut, lass uns damit gehen" als Antwort auf eine Nachricht von zwei Tagen zuvor schrieb.

Sie suchen nach „REST API" in der Hoffnung, die Vergleichsdiskussion zu finden. Anderer Ergebnissatz, nur teilweise Überschneidung. Einige der wichtigsten Nachrichten im Entscheidungs-Thread enthalten weder „REST" noch „GraphQL", weil sie allgemein über Entwicklererfahrung und Typsicherheit diskutierten.

Sie geben auf und fragen in #engineering: „Erinnert sich jemand, wann wir entschieden haben, zu GraphQL zu wechseln?" Jemand antwortet mit einem Link zu einem Linear-Issue. Das Linear-Issue verweist auf ein Notion-RFC. Das Notion-RFC referenziert einen Slack-Thread (aber der Link ist tot, weil der Kanal archiviert wurde). Und der eigentliche Entscheidungsmoment fand in einem Huddle ohne schriftliches Protokoll statt.

Das ist kein Suchproblem. Das ist ein Wissensgraph-Problem. Und das ist der eigentliche Grund, warum Teams mit zu vielen Slack-Kanälen nichts finden können – egal wie gut die Slack-Suche wird.

Was wirklich funktioniert

Nachdem wir dieses Muster in unserem eigenen Team beobachtet haben (und bemerkenswert ähnliche Geschichten von anderen Engineering-Managern gehört haben), sind wir bei ein paar Dingen gelandet, die wirklich helfen:

Akzeptieren Sie, dass Slack ein Posteingang ist, kein Archiv. Das nützlichste mentale Modell-Shift überhaupt. Slack ist der Ort, an dem Gespräche in Echtzeit stattfinden, nicht wo Entscheidungen gespeichert werden. Wenn etwas Wichtiges in Slack entschieden wurde, muss es an einem dauerhaften Ort festgehalten werden: ein Linear-Issue, ein Notion-Dokument, ein ADR, sogar eine Commit-Nachricht. Slack ist das Gespräch; diese anderen Tools sind das Protokoll.

Nutzen Sie Threads konsequent. Threads sind Slacks beste Funktion für Auffindbarkeit, weil sie ein vollständiges Gespräch in einer adressierbaren Einheit halten. Ein Thread hat einen Permalink. Ein Gespräch, das über die Haupt-Timeline eines Kanals verteilt ist, hat das nicht. Wenn die Teamkultur standardmäßig im Hauptkanal antwortet (und viele tun das, weil es unmittelbarer wirkt), erschweren Sie die Informationsabfrage erheblich.

Erstellen Sie Entscheidungskanäle, keine Projektkanäle. Das ist kontraintuitiv, aber hören Sie zu. Statt (oder zusätzlich zu) #project-atlas versuchen Sie es mit #decisions oder #decisions-engineering. Ein Kanal, dessen einziger Zweck es ist, Entscheidungen mit kurzem Kontext festzuhalten. Er enthält nicht die vollständige Diskussion (die kann dort leben, wo sie natürlich stattfindet), aber er gibt Ihnen ein durchsuchbares, chronologisches Protokoll dessen, was entschieden wurde, und einen Link dorthin, wo die Diskussion stattgefunden hat. Denken Sie daran als Commit-Log für das Denken Ihres Teams. Der Durchsetzungsmechanismus, der wirklich funktioniert (unserer Erfahrung nach): Machen Sie es Teil Ihrer PR-Vorlage. Vor dem Mergen einen Link zum relevanten Entscheidungs-Post setzen. Das ist leichtgewichtig, im Review überprüfbar und erstellt einen Pfad, der nicht vom Gedächtnis oder der Disziplin irgendjemandes abhängt.

Verbinden Sie die Punkte automatisch. Das ist der Teil, in dem ich erwähnen werde, was wir bauen, weil es direkt relevant ist. Sugarbug importiert Slack-Nachrichten zusammen mit Ihren Linear-Issues, GitHub-PRs, Notion-Docs und Figma-Kommentaren und erstellt einen Wissensgraph davon, wie sie alle miteinander zusammenhängen. Wenn diese Verbindungen bestehen, müssen Sie sich nicht daran erinnern, in welchem Kanal ein Gespräch stattgefunden hat – denn Sie können von der Aufgabe oder dem Dokument aus starten und dem Pfad zu jedem relevanten Gespräch folgen, unabhängig davon, wo es stattfand. Wir arbeiten noch daran, all das am besten zu präsentieren (ehrlich gesagt ist das UX für kanalübergreifende Abfrage schwieriger als die Ingestion), aber der Kernansatz – Kontext verbinden statt reorganisieren – ist das, was unserer Meinung nach wirklich etwas bewirkt.

Hören Sie auf, fünf Kanäle zu durchsuchen und mit leeren Händen dazustehen. Sugarbug verbindet Slack mit dem Rest Ihrer Tools, damit Entscheidungen auffindbar bleiben.

Q: Wie viele Slack-Kanäle sind zu viele? A: Es gibt keine magische Zahl, aber wenn Ihr Team regelmäßig nicht mehr findet, wo ein Gespräch stattgefunden hat, oder wenn Leute standardmäßig DMs nutzen, weil Kanäle überwältigend wirken, haben Sie die Grenze wahrscheinlich überschritten. Teams von 10–20 Personen mit mehr als 80–100 aktiven Kanälen stoßen oft an diese Wand – obwohl es stark davon abhängt, wie diszipliniert Ihr Team bei Kanalzweck und Archivierung ist.

Q: Hilft Sugarbug bei Slack-Kanal-Überlastung? A: Sugarbug verwaltet Ihre Kanäle nicht direkt, löst aber das Auffindbarkeitsproblem, das Kanal-Überlastung erzeugt. Es importiert Slack-Nachrichten zusammen mit Ihren Linear-Issues, GitHub-PRs, Notion-Docs und Figma-Kommentaren in einen Wissensgraph – sodass Sie bei der Suche nach einer Entscheidung oder einem Gespräch einmal suchen und es finden, egal in welchem Kanal (oder welchem Tool) es stattgefunden hat.

Q: Warum finde ich in Slack trotz Suche nichts? A: Die Slack-Suche findet Nachrichten, die Ihre genauen Stichworte enthalten, aber die meisten Arbeitsentscheidungen verwenden in verschiedenen Phasen unterschiedliche Worte. Jemand sagt in einem Thread vielleicht „die Redis-Option" und in einem anderen „BullMQ" – für dieselbe Entscheidung – und diese Threads referenzieren sich nie gegenseitig. Suche findet Textübereinstimmungen. Einen Entscheidungspfad zu finden erfordert das Verstehen von Verbindungen zwischen Gesprächen – eine grundlegend andere Fähigkeit.

Q: Kann Sugarbug Slack-Kanäle durch etwas Besseres ersetzen? A: Nein, und das sollte es auch nicht versuchen. Slack ist ausgezeichnet für Echtzeit-Gespräche, und das ist genuinen Wert. Das Problem ist nicht Slack selbst, sondern die Tatsache, dass wichtiger Kontext in Gesprächen eingeschlossen ist, ohne mit den zugehörigen Aufgaben, Dokumenten und dem Code verbunden zu sein. Sugarbug erstellt diese Verbindungen automatisch, sodass Sie sich nicht erinnern müssen, wo Dinge besprochen wurden.