Immer mehr kleine Teams bauen Produkte ausserhalb klassischer Anstellungsverhältnisse: als Gründerzellen in Freistellung, als lose gekoppelte Remote-Gruppen, als KI-gestützte Mikroteams. Die Frage, wie solche Teams koordinieren, ist in den letzten zwei Jahren radikal neu geworden. KI-Werkzeuge wie Claude Code, Cursor oder integrierte Team-Agenten nehmen einen Grossteil des klassischen Koordinations-Aufwands ab: Statusberichte, Dokumentation, Prozess-Routing. Was übrig bleibt, ist das, was KI nicht kann. Und genau dort entscheidet sich, ob ein lose gekoppeltes Team zusammenhält oder zerfällt. Der Hebel heisst nicht Hierarchie, sondern klare Rollen plus leichtgewichtige Rituale.
Was KI am Koordinieren wirklich übernimmt
Hierarchie ist kein kulturelles Phänomen, sondern eine Antwort auf ein praktisches Problem: Informationsfluss bei Skalierung. Wer in einem 500-Personen-Unternehmen arbeitet, braucht Ebenen, weil sonst jede Entscheidung bei allen landet. Christoph Keese hat das in seiner Analyse des Block-Ansatzes treffend beschrieben: Das eigentlich Neue an KI ist nicht, dass sie Arbeit automatisiert, sondern dass sie das Koordinations-Routing automatisiert. Dashboards ersetzen Statusmeetings. Wissens-Graphen ersetzen Abstimmungsrunden. Claude Code kann in einem Repo erklären, warum Entscheidung X gefallen ist, wenn jemand die ADR schreibt. Damit schrumpft der klassische Kern der Hierarchie: die menschliche Funktion "jemand weiss, wer was macht" lässt sich auf ein gut gepflegtes System auslagern.
Für lose Teams ist das eine gute Nachricht. Sie müssen die Skalierungs-Probleme grosser Organisationen nicht mehr mit Mini-Hierarchien nachbauen. Ein vierköpfiges Team kann heute mit denselben Transparenz-Mechanismen arbeiten, die früher einem Head of Operations vorbehalten waren: Wissensdatenbank, Architecture Decision Records, asynchrone Updates, automatisierte Zusammenfassungen. Was bisher Overhead war, ist heute Standard-Toolchain.
Was menschlich bleibt und warum es kritisch ist
Genau hier entsteht allerdings der Fehlschluss: Wenn Information Routing automatisiert wird, heisst das nicht, dass Koordination damit gelöst ist. Es bleiben drei Funktionen, die klassische Hierarchien ebenfalls erfüllt haben und die KI weder ersetzen noch simulieren kann.
Die Vertrauensfunktion: Menschen arbeiten zusammen, weil sie einander persönlich einschätzen können. In einer Festanstellung kompensiert das Gehalt eine gewisse Portion fehlenden Vertrauens. In losen Teams ohne Vertrag ist Vertrauen die einzige Bindung. Es entsteht nicht durch Dashboards, sondern durch Präsenz, durch Gespräche, die auch mal nicht um Arbeit gehen, durch wiederholte Erfahrung, dass jemand tut, was er sagt. Die Urteilsfunktion: KI kann zehn Optionen auflisten, aber nicht entscheiden, welche die richtige ist, wenn Werte und Interessen kollidieren. Jemand muss priorisieren, gegen Lieblings-Ideen halten, den Plan gegen das Heute-habe-ich-Lust-auf-X verteidigen. Die Moderations-Funktion: Konflikte entstehen auch in guten Teams. Sie lösen sich nicht durch Tools, sondern durch jemanden, der Spannungen benennt, bevor sie eskalieren.
Das Paradox: In grossen Organisationen werden diese drei Funktionen oft unsichtbar, weil sie über viele Rollen verteilt sind. In losen Teams konzentrieren sie sich auf eine einzige Person. Meistens auf die, die sich als PM oder als informelle Gründerin versteht. Diese Person wird zum Bindemittel. Wenn sie das nicht explizit macht, zerfällt das Team, sobald das erste echte Problem auftaucht.
Warum Rollen in losen Teams wichtiger sind als in klassischen
Im klassischen Arbeitsverhältnis weiss jeder, wer wofür zuständig ist: die Stellenbeschreibung sagt es, das Organigramm sagt es, der Vertrag sagt es. In losen Teams fehlt all das. Das wird oft als Vorteil verkauft ("wir sind flach und agil"), ist aber in Wahrheit der häufigste Grund für Reibung. Denn ohne explizite Rollen passiert eines von zwei Dingen: Entweder niemand fühlt sich für eine Sache verantwortlich, oder alle mischen bei allem mit. Beides kostet Geschwindigkeit.
Die Lösung ist einfacher als das Problem. Jede Grundfunktion, die das Produkt braucht (Markt und Kunden, Engine und Fachlogik, Frontend und UX, optionale Module), bekommt genau einen Owner. Nicht zwei "gemeinsam", nicht "rotierend". Einen. Der Owner entscheidet in seinem Bereich, konsultiert die anderen, wenn sein Bereich mit anderen kollidiert, und trägt das Ergebnis. Ein leichtgewichtiges Entscheidungs-Protokoll (in der Praxis reicht ein DACI-Light: Driver, Approver, Contributor, Informed) klärt, wer bei welcher Entscheidung welche Rolle hat. Konflikte gehen zur PM, nicht weil sie Chefin ist, sondern weil Neutralität und der Gesamtkontext bei ihr liegen.
Das Gesamtbild wird damit klarer: KI übernimmt das Routing. Menschen übernehmen das Vertrauen. Beides muss laufen, sonst entsteht entweder Chaos oder Kontrollwut.
An KI delegierbar
Routing & Memory
Status-Updates, Dokumentation, Architektur-Gedächtnis (ADRs), Priorisierungs-Optionen auflisten, Telemetrie auswerten, Meeting-Notizen, Projekt-Zusammenfassungen.
Menschliche Arbeit
Vertrauen & Urteil
Vertrauen aufbauen, Konflikte moderieren, zwischen Optionen entscheiden wenn Werte kollidieren, Sinn stiften, Motivation erkennen bevor sie kippt.
Was wir gerade ausprobieren
Ich arbeite aktuell in einem vierköpfigen Remote-Team, ohne formale Anstellungsverhältnisse, alle in ihrer freien Zeit, an einer Produktidee. Da wir stark zu unterschiedlichen Zeiten arbeiten, brauchen wir klare Strukturen. Nach Beratung mit Claude habe ich Rituale und Strukturen ausgearbeitet, die wir ab jetzt ausprobieren können. Auch hier steht die Motivation aller im Mittelpunkt: lose Zusammenarbeit funktioniert nur durch Vertrauen, Absprache und Fokus. Ob der Vorschlag trägt, wissen wir in ein paar Wochen.
Erstens
Wer entscheidet was — explizit aufgeschrieben
Wir ordnen jede Grundfunktion einer Person zu, nicht als Titel, sondern als Verantwortlichkeit. Liegt eine Entscheidung im eigenen Bereich, entscheidet man. Liegt sie bei jemand anderem, liefert man Input, blockiert aber nicht. Die Annahme dahinter: Das sollte die häufigsten "ich dachte, du machst das"-Momente reduzieren. Wie gut es trägt, sehen wir nach den ersten Reibungspunkten.
Zweitens
Ein schlanker Ritual-Stack zum Testen
Freitags gegen 17 Uhr schreibt jede Person einen Drei-Zeiler in den Team-Chat: was gebaut, was offen, was Blocker. Alle zwei Wochen ein 30-Minuten-Sync, aber nur für offene Entscheidungen; ohne Agenda sagen wir ab. Einmal im Monat eine Retro. Alle vier Wochen ein 15-Minuten-Gespräch mit jeder Person, bewusst nicht über Arbeit, sondern über Mensch. Das vierte Ritual halte ich für das wichtigste. Ohne es wird aus "flacher Zusammenarbeit" leicht "niemand fragt, wie es dir geht". Ob der Stack in der Praxis trägt oder uns ausbremst, zeigt sich in den nächsten Wochen.
Drittens
Struktur-Entscheidungen in ADRs festhalten
ADRs (Architecture Decision Records) sind kurze Notizen, in denen eine Entscheidung mit Kontext und Konsequenzen festgehalten wird. Wir wollen das Format nicht nur im Frontend-Repo und nicht nur für Code-Entscheidungen nutzen, sondern auch für Produkt-Entscheidungen ("Händler-Segment fliegt aus dem Baseline-Modell"). Der Gedanke: In losen Teams gibt es keinen Arbeitsvertrag, keine Stellenbeschreibung, keine Onboarding-Doku. Das gemeinsame Gedächtnis entsteht ausschliesslich durch das, was aufgeschrieben wird. Ob das Team die Disziplin aufbringt, dranzubleiben, ist der eigentliche Test.
Kritische Einordnung
Wir starten den Versuch in einem Vier-Personen-Setup. Das Modell dürfte nur bei kleinen Teams funktionieren. Vier Personen ist fast ideal, sechs gehen vermutlich noch, bei acht wird es fragil. Eine DACI-Light-Matrix bleibt handlich, solange alle alle kennen; sobald sich Subgruppen bilden, braucht es formalere Strukturen. Ausserdem: Ohne Vertrag funktioniert Commitment nur, solange persönliche Motivation trägt. Wenn jemand sein Gehalt anderswo verdient und solche Projekte abends macht, konkurriert das Projekt mit Familie, Hobby, Gesundheit. Rituale schaffen soziale Verbindlichkeit, sie ersetzen aber keine existenzielle. Das heisst: Sobald das Produkt eine gewisse Reife erreicht, muss das Team die Vertragsfrage klären, sonst verliert man genau in dem Moment Momentum, in dem man es braucht. Und: ADRs als Gewohnheit klingen leicht, sind aber Kultur-Arbeit. Die erste ADR schreibt jeder, die zehnte nur noch, wenn es sich eingebürgert hat. Ob wir das durchhalten, ist offen.
Was bleibt für jeden Tag
Rolle statt Titel.
Jede Grundfunktion soll genau einen Owner haben. Nicht zwei, nicht rotierend. Geschwindigkeit entsteht hoffentlich durch Klarheit, nicht durch Konsens.
Ritual statt Kontrolle.
Drei-Zeiler-Freitags-Update, 30-Minuten-Sync alle zwei Wochen, Retro monatlich, 1:1 über Mensch. Unsere Wette, dass das Teams ohne Vertrag trägt.
Entscheidungen aufschreiben statt erinnern.
Jede Entscheidung, die jemand später verstehen muss, wird in einer ADR (Architecture Decision Record) festgehalten. Nicht nur im Code, auch im Produkt. Unser Ersatz für den fehlenden Vertrag.
Quellen
- Scharffetter, Linja (2026). Hierarchie & Intelligenz. Warum KI das Organigramm neu verteilt und was menschlich bleibt. linja.me/blog.
- Keese, Christoph (2026). Block-Ansatz: KI als Koordinationslogik jenseits klassischer Hierarchien.
- Nygard, Michael (2011). Documenting Architecture Decisions. Architecture Decision Records Project.
- Edmondson, Amy (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly.
Glossar
ADR — Architecture Decision Record: kurze Notiz, die eine Entscheidung, ihren Kontext und die Konsequenzen festhält
DACI-Light — Entscheidungs-Protokoll: Driver, Approver, Contributor, Informed. Abgespeckte RACI-Variante
Owner — Person, die für eine Grundfunktion verantwortlich ist und in ihrem Bereich final entscheidet
Grundfunktion — Kern-Fähigkeit, die ein Produkt oder Team zum Funktionieren braucht
Information Routing — Klassische Hierarchie-Funktion: Wer weiss was wann. Zunehmend durch KI-Tools automatisierbar
Psychologische Sicherheit — Gefühl, in einem Team ohne Angst vor Nachteil Ideen, Fehler oder Bedenken teilen zu können (Edmondson)