Remote-Kommunikation und Dokumentation -- So bleibt dein Team auf dem gleichen Stand
Wenn du ein verteiltes Team führst, ist Kommunikation alles. Aber nicht irgendeine Kommunikation -- die richtige Art, zur richtigen Zeit, über den richtigen Kanal. In einem Büro klärst du Dinge schnell am Schreibtisch des Kollegen. Remote musst du bewusster kommunizieren -- und vor allem: dokumentieren.
In diesem Beitrag zeige ich dir, wie du eine Kommunikations- und Dokumentationskultur aufbaust, die dein verteiltes Team produktiv und verbunden hält.
Warum Kommunikation remote anders funktioniert
Im Büro passiert ein Grossteil der Kommunikation informell: beim Kaffee, im Lift, am Gang. Diese zufälligen Begegnungen sorgen dafür, dass Informationen fliessen, auch ohne formelle Meetings.
Remote fällt das komplett weg. Das hat Konsequenzen:
- Informationslücken entstehen schneller: Was nicht aktiv geteilt wird, erfahren andere nicht
- Missverständnisse sind häufiger: Ohne Tonfall und Körpersprache werden Nachrichten leichter falsch interpretiert
- Isolation droht: Wer nicht aktiv kommuniziert, verschwindet vom Radar
- Kontext fehlt: Neue Teammitglieder haben es schwer, den aktuellen Stand zu erfassen
Die Lösung ist nicht mehr Kommunikation, sondern bessere Kommunikation. Und das Fundament dafür ist Dokumentation.
Das Kommunikations-Framework für verteilte Teams
Ebene 1: Synchrone Kommunikation (Echtzeit)
Synchrone Kommunikation findet in Echtzeit statt -- Video-Calls, Telefonate, spontane Slack-Huddles. Sie eignet sich für:
- Komplexe Diskussionen mit mehreren Perspektiven
- Emotionale oder heikle Themen (Feedback, Konflikte)
- Brainstorming und kreative Arbeit
- Schnelle Entscheidungen in dringenden Situationen
- Team-Building und soziale Interaktion
Faustregel: Synchrone Kommunikation sollte maximal 20-30% deiner Kommunikation ausmachen.
Ebene 2: Asynchrone Kommunikation (zeitversetzt)
Asynchrone Kommunikation -- Slack-Nachrichten, E-Mails, Kommentare in Tools -- ist der Kern der Remote-Kommunikation. Du schreibst eine Nachricht, und der Empfänger antwortet, wenn er Zeit hat.
Sie eignet sich für:
- Updates und Statusberichte
- Fragen, die keine sofortige Antwort brauchen
- Entscheidungen mit klarem Kontext
- Feedback zu Dokumenten oder Designs
- Täglich wiederkehrende Stand-ups
Faustregel: Asynchrone Kommunikation sollte 50-60% deiner Kommunikation ausmachen. Mehr zum Thema asynchrones Arbeiten findest du in diesem Beitrag.
Ebene 3: Dokumentation (dauerhaft)
Dokumentation ist die dritte und wichtigste Ebene. Sie ist keine Kommunikation im engeren Sinne, sondern das Festhalten von Wissen, Entscheidungen und Prozessen für die Zukunft.
Sie eignet sich für:
- Prozesse und Workflows
- Entscheidungen und deren Begründungen
- Onboarding-Materialien
- Produktspezifikationen
- Meeting-Ergebnisse (nicht Protokolle -- Ergebnisse!)
- Strategische Pläne und Ziele
Faustregel: Dokumentation sollte 20-30% deiner Kommunikationszeit ausmachen -- und alles Wichtige abdecken.
Kanalstrategie: Welcher Kanal wofür?
Eine der grössten Herausforderungen in verteilten Teams ist die Frage: Wo kommuniziere ich was? Ohne klare Regeln landen Informationen im falschen Kanal und gehen verloren.
Empfohlene Kanalstruktur
| Kanal | Wofür | Reaktionszeit |
|---|---|---|
| Slack/Teams (DM) | Schnelle 1:1-Fragen | 2-4 Stunden |
| Slack/Teams (Channel) | Team-Updates, Diskussionen | 4-8 Stunden |
| Externe Kommunikation, formelle Mitteilungen | 24 Stunden | |
| Video-Call | Komplexe Diskussionen, Feedback | Geplant |
| Notion/Wiki | Dokumentation, Prozesse | Keine (Referenz) |
| Jira/Linear | Aufgaben-spezifische Kommunikation | Im Rahmen des Sprints |
| Loom/Video-Messages | Erklärungen, Demos, Walkthroughs | 24 Stunden |
Slack-Kanal-Struktur für Startups
Für ein Startup mit 5-20 Mitarbeitern empfehle ich diese Kanalstruktur:
Allgemeine Kanäle:
#general-- Wichtige Ankündigungen für alle#random-- Informelles, Lustiges, Off-Topic#wins-- Erfolge und Meilensteine feiern
Team-Kanäle:
#team-engineering-- Engineering-spezifische Themen#team-product-- Produkt- und Design-Themen#team-marketing-- Marketing und Growth
Projekt-Kanäle:
#projekt-[name]-- Für laufende Projekte#launch-[feature]-- Für Feature-Launches
Operative Kanäle:
#standup-- Tägliche asynchrone Stand-ups#decisions-- Wichtige Entscheidungen festhalten#feedback-- Produktfeedback und Kundenrückmeldungen
Die Kunst der guten Remote-Nachricht
Im Büro kannst du sagen: "Hey, kurze Frage -- wie war das nochmal mit dem Feature?" Remote funktioniert das nicht. Jede Nachricht muss für sich stehen, ohne Rückfragen zu erfordern.
Das BLUF-Prinzip
BLUF steht für "Bottom Line Up Front" -- die wichtigste Information kommt zuerst.
Schlecht:
"Ich habe mir heute Morgen den Report angesehen und bin auf ein paar Dinge gestossen, die mir aufgefallen sind. Unter anderem war da eine Unstimmigkeit bei den Zahlen im dritten Quartal. Könntest du dir das vielleicht mal ansehen?"
Besser:
"Bitte prüfe die Q3-Zahlen im Report -- es gibt eine Unstimmigkeit bei den Umsätzen (Seite 12). Ich vermute einen Tippfehler, aber es könnte auch ein Berechnungsfehler sein. Wäre super, wenn du bis Freitag Bescheid geben könntest."
Checkliste für gute Remote-Nachrichten
- Kontext geben: Auf welches Projekt, welche Aufgabe bezieht sich die Nachricht?
- Klare Frage oder Aktion: Was genau soll der Empfänger tun?
- Deadline nennen: Bis wann wird eine Antwort oder Erledigung erwartet?
- Formatierung nutzen: Bullet Points, Fettschrift, Überschriften für Übersichtlichkeit
- Links mitgeben: Verweise auf relevante Dokumente, Tickets oder frühere Gespräche
- Ton beachten: Emojis und freundliche Formulierungen helfen, Missverständnisse zu vermeiden
Dokumentation: Das Gedächtnis deines Startups
Warum Dokumentation so wichtig ist
In einem Startup ändert sich alles ständig. Ohne Dokumentation:
- Geht Wissen verloren, wenn Mitarbeiter gehen
- Müssen die gleichen Fragen immer wieder beantwortet werden
- Ist Onboarding ein mühsamer, langwieriger Prozess
- Werden Entscheidungen vergessen oder immer wieder aufgerollt
- Arbeiten Teams aneinander vorbei
Was du dokumentieren solltest
Unternehmensdokumentation:
- Vision, Mission, Werte
- Organisationsstruktur und Verantwortlichkeiten
- Strategische Ziele und OKRs
Prozessdokumentation:
- Wie erstellen wir ein neues Feature? (Product Development Process)
- Wie deployen wir Code? (Release Process)
- Wie stellen wir neue Mitarbeiter ein? (Hiring Process)
- Wie onboarden wir neue Teammitglieder? Details dazu in unserem Onboarding-Guide
Entscheidungsdokumentation:
- Welche Entscheidung wurde getroffen?
- Warum wurde sie so getroffen? (Begründung)
- Welche Alternativen wurden betrachtet?
- Wer war beteiligt?
- Wann kann die Entscheidung überprüft werden?
Technische Dokumentation:
- Architektur-Übersichten
- API-Dokumentation
- Setup-Anleitungen
- Troubleshooting-Guides
Meeting-Dokumentation:
- Agenda (vorab geteilt)
- Ergebnisse und Entscheidungen (nicht Wort-für-Wort-Protokolle)
- Action Items mit Verantwortlichen und Deadlines
Dokumentations-Formate
ADRs -- Architecture Decision Records
Für technische Entscheidungen empfehle ich ADRs. Ein ADR hat folgendes Format:
# ADR-001: Datenbank-Auswahl
## Status: Akzeptiert
## Kontext
Wir brauchen eine Datenbank fuer unsere Anwendung.
Die Anforderungen sind: hohe Verfuegbarkeit,
relationale Daten, max. 100 EUR/Monat.
## Entscheidung
Wir verwenden PostgreSQL auf AWS RDS.
## Begruendung
- Relationale Datenbank fuer unsere Datenstruktur am besten geeignet
- PostgreSQL ist Open Source und hat grosse Community
- AWS RDS bietet verwalteten Service mit Backups
- Kosten liegen bei ca. 50-80 EUR/Monat
## Alternativen
- MySQL: Weniger Features als PostgreSQL
- MongoDB: Nicht ideal fuer relationale Daten
- SQLite: Nicht skalierbar genug
## Konsequenzen
- Team muss PostgreSQL-Kenntnisse aufbauen
- Wir sind an AWS gebunden
RFCs -- Request for Comments
Für grössere Entscheidungen, die Input von mehreren Personen brauchen, eignen sich RFCs:
- Der Autor schreibt einen Vorschlag
- Das Team hat 3-5 Tage Zeit für Kommentare und Fragen
- Der Autor überarbeitet den Vorschlag basierend auf dem Feedback
- Eine finale Entscheidung wird getroffen und dokumentiert
Das ist asynchrones Entscheiden auf hohem Niveau -- und funktioniert remote wunderbar.
Tools für Remote-Kommunikation und Dokumentation
Kommunikation
- Slack: Der Standard für Startup-Kommunikation. Kostenlos für kleine Teams, ab 7,25 EUR pro Person/Monat für Pro.
- Loom: Video-Nachrichten für Erklärungen und Demos. Unglaublich nützlich für asynchrone Kommunikation. Ab 12,50 EUR pro Person/Monat.
- Zoom oder Google Meet: Für synchrone Video-Calls.
Dokumentation
- Notion: All-in-One-Workspace für Wiki, Aufgaben und Dokumentation. Ab 8 EUR pro Person/Monat.
- Conflünce: Solide Wiki-Lösung, gut integriert mit Jira. Ab 5,75 EUR pro Person/Monat.
- GitBook: Ideal für technische Dokumentation. Kostenlos für kleine Teams.
- Google Docs: Für kollaboratives Schreiben und schnelle Dokumente.
Eine detaillierte Tool-Übersicht findest du in unserem Beitrag zu Tools für verteilte Teams.
Kommunikationsfehler, die du vermeiden solltest
Fehler 1: Zu viel synchrone Kommunikation
Wenn jede Frage per Video-Call geklärt wird, hat niemand Zeit zum Arbeiten. Reserviere Video-Calls für Themen, die wirklich Echtzeit-Diskussion brauchen.
Fehler 2: Keine Reaktionszeit-Erwartungen
Wenn unklar ist, wie schnell jemand antworten soll, führt das zu Stress. Der eine erwartet sofortige Antwort, der andere antwortet erst am nächsten Tag. Definiere klare Reaktionszeiten pro Kanal.
Fehler 3: Informelle Entscheidungen
"Wir haben das gestern im Call besprochen" -- aber es steht nirgendwo. Jede Entscheidung muss dokumentiert werden, sonst existiert sie nicht.
Fehler 4: Nur Text, nie Video
Reine Textkommunikation kann kalt und unpersönlich wirken. Nutze regelmässig Video -- nicht nur für Meetings, sondern auch für kurze Loom-Videos oder Slack-Huddles.
Fehler 5: DMs statt öffentliche Kanäle
Wenn wichtige Informationen in Direktnachrichten ausgetauscht werden, hat der Rest des Teams keinen Zugriff. Nutze öffentliche Kanäle als Standard und DMs nur für wirklich persönliche Themen.
Fehler 6: Keine Kommunikations-Richtlinien
Ohne klare Regeln kommuniziert jeder anders. Der eine schickt um 23 Uhr Slack-Nachrichten, der andere erwartet Antworten am Wochenende. Erstelle ein Kommunikations-Handbuch und mach es Teil des Onboardings.
Dokumentationskultur aufbauen -- praktische Tipps
Tipp 1: Klein anfangen
Du musst nicht alles auf einmal dokumentieren. Starte mit:
- Den wichtigsten 5 Prozessen
- Einem Template für Entscheidungs-Dokumentation
- Einem Wiki-Bereich für Onboarding
Tipp 2: Dokumentation als Teil der Arbeit sehen
Dokumentation ist keine Extra-Aufgabe -- sie ist Teil der Arbeit. Wenn du eine Entscheidung triffst, gehört die Dokumentation dazu. Wenn du einen Prozess änderst, gehört die Aktualisierung der Doku dazu.
Tipp 3: Templates nutzen
Templates senken die Hürde, etwas zu dokumentieren. Erstelle Templates für:
- Meeting-Notes
- Entscheidungen (ADRs)
- Projektbriefe
- Retrospektiven
- Onboarding-Checklisten
Tipp 4: Review-Rhythmus einrichten
Dokumentation veraltet schnell. Richte einen monatlichen Review ein, bei dem jedes Team seine Dokumentation auf Aktualität prüft.
Tipp 5: Vorbildfunktion übernehmen
Als Gründer oder Führungskraft musst du vorleben, was du erwartest. Wenn du selbst nicht dokumentierst, wird es dein Team auch nicht tun.
Fazit
Remote-Kommunikation und Dokumentation sind keine lästigen Pflichten -- sie sind der Grundstein für erfolgreiche verteilte Zusammenarbeit. Investiere Zeit in den Aufbau einer soliden Kommunikationsstruktur und einer lebendigen Dokumentationskultur. Es zahlt sich aus: weniger Missverständnisse, schnelleres Onboarding, bessere Entscheidungen und ein Team, das sich verbunden fühlt -- egal, wo es sitzt.
Fang heute an. Schreib die erste Entscheidung auf. Erstelle den ersten Prozess in deinem Wiki. Definiere die Kommunikationsregeln. Dein zukünftiges Ich wird dir dankbar sein.
Du brauchst Unterstützung beim Aufbau deiner Remote-Kommunikation? Startup Burgenland bietet dir Beratung und Vernetzung mit erfahrenen Remote-Teams. Komm vorbei und profitiere von unserem Netzwerk!
Dieser Beitrag ist Teil der Serie "Remote und hybrides Arbeiten" im Startup Burgenland Blog. Entdecke auch die anderen Beiträge der Serie für mehr Tipps rund um verteiltes Arbeiten.
Über den Autor: Felix Lenhard ist Program Director und Startup Coach bei Startup Burgenland. Zuvor Managing Director beim 360 Innovation Lab, Innovation Manager bei RHI Magnesita und Serial Entrepreneur mit internationalen Exits. Über 15 Jahre Erfahrung in Innovation und Unternehmensaufbau.