KI in Organisationen 19. April 2026 · 7 Min Lesezeit

Teams ohne Vertrag. Koordination, wenn KI das Routing übernimmt.

TL;DR

KI automatisiert Information Routing, Menschen übernehmen Vertrauen, Urteil und Konfliktmoderation. Lose Teams brauchen klare Rollen statt Titel, leichtgewichtige Rituale (Freitags-Drei-Zeiler, Sync alle zwei Wochen) und ADRs für gemeinsames Gedächtnis ohne Vertrag.

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.

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)

AI in Organizations April 19, 2026 · 7 min read

Teams without a contract. Coordination when AI handles the routing.

TL;DR

AI automates information routing, humans take on trust, judgment, and conflict moderation. Loose teams need clear roles instead of titles, lightweight rituals (Friday three-liner, sync every two weeks) and ADRs as shared memory without a contract.

More and more small teams are building products outside classic employment relationships: as founder cells on sabbaticals, as loosely coupled remote groups, as AI-assisted micro-teams. The question of how such teams coordinate has been radically redefined in the past two years. AI tools like Claude Code, Cursor, or integrated team agents remove a large part of the classic coordination overhead: status updates, documentation, process routing. What remains is what AI cannot do. And that is exactly where it is decided whether a loosely coupled team holds together or falls apart. The lever is not hierarchy, but clear roles plus lightweight rituals.

What AI really takes off the coordination pile

Hierarchy is not a cultural phenomenon, it is a response to a practical problem: information flow at scale. Anyone working in a 500-person company needs layers, otherwise every decision lands on everyone's desk. Christoph Keese captured this well in his analysis of the block approach: the real news about AI is not that it automates work, but that it automates coordination routing. Dashboards replace status meetings. Knowledge graphs replace alignment rounds. Claude Code can explain in a repo why decision X was made, as long as someone writes the ADR. That shrinks the classic core of hierarchy: the human function "someone knows who is doing what" can be offloaded to a well-maintained system.

For loose teams this is good news. They no longer need to rebuild the scaling problems of large organizations with mini-hierarchies. A four-person team today can work with the same transparency mechanisms that used to be reserved for a Head of Operations: knowledge base, architecture decision records, asynchronous updates, automated summaries. What used to be overhead is now standard toolchain.

What stays human and why it is critical

Here is where the false conclusion kicks in: just because information routing is automated does not mean coordination is solved. Three functions remain that classic hierarchies also fulfilled and that AI can neither replace nor simulate.

The trust function: people work together because they can read each other personally. In a full-time job, salary compensates for a certain share of missing trust. In loose teams without a contract, trust is the only bond. It does not emerge from dashboards, but from presence, from conversations that are sometimes not about work, from the repeated experience that someone does what they say. The judgment function: AI can list ten options, but it cannot decide which is the right one when values and interests collide. Someone has to prioritize, push back on favorite ideas, defend the plan against the today-I-feel-like-X. The moderation function: conflicts happen even in good teams. They do not resolve through tools, but through someone who names tensions before they escalate.

The paradox: in large organizations these three functions are often invisible because they are spread across many roles. In loose teams they concentrate on a single person. Usually the one who sees herself as PM or informal founder. This person becomes the glue. If she does not make that explicit, the team falls apart as soon as the first real problem shows up.

Why roles matter more in loose teams than in classic ones

In a classic employment relationship, everyone knows who is responsible for what: the job description says it, the org chart says it, the contract says it. In loose teams all of that is missing. This is often sold as an advantage ("we are flat and agile"), but in reality it is the most common source of friction. Because without explicit roles, one of two things happens: either nobody feels responsible for a thing, or everybody gets involved in everything. Both cost speed.

The solution is simpler than the problem. Each core function the product needs (market and customers, engine and domain logic, frontend and UX, optional modules) gets exactly one owner. Not two "jointly", not "rotating". One. The owner decides within their area, consults others when their area collides with another, and carries the result. A lightweight decision protocol (in practice a DACI-light works: Driver, Approver, Contributor, Informed) clarifies who has which role in which decision. Conflicts go to the PM, not because she is the boss, but because neutrality and the whole-picture context sit with her.

The overall picture becomes clearer: AI takes over routing. Humans take over trust. Both have to run, otherwise you get chaos or control obsession.

Delegable to AI

Routing & memory

Status updates, documentation, architecture memory (ADRs), listing prioritization options, telemetry analysis, meeting notes, project summaries.

Human work

Trust & judgment

Building trust, moderating conflicts, deciding between options when values collide, creating meaning, noticing motivation before it tips.

What we are trying out

I am currently working in a four-person remote team, without formal employment relationships, everyone in their free time, on a product idea. Because we work at very different hours, we need clear structures. After consulting with Claude, I have drafted rituals and structures that we can now try out. Here too, everyone's motivation is at the center: loose collaboration only works through trust, clear agreements, and focus. Whether the proposal holds, we will know in a few weeks.

First

Who decides what, written down explicitly

We assign each core function to one person, not as a title but as a responsibility. If a decision sits in your area, you decide. If it sits with someone else, you contribute input but do not block. The assumption: this should reduce the most frequent "I thought you were doing that" moments. How well it carries, we will see after the first friction.

Second

A lean ritual stack to test

Every Friday around 5pm, each person writes a three-liner in the team chat: what I built, what is open, what is blocking me. Every two weeks a 30-minute sync, but only for open decisions; no agenda means we cancel. Once a month a retro. Every four weeks a 15-minute conversation with each person, deliberately not about work but about the human. I see the fourth ritual as the most important. Without it, "flat collaboration" easily becomes "no one asks how you are." Whether the stack carries us or slows us down will show in the coming weeks.

Third

Capture structural decisions in ADRs

ADRs (Architecture Decision Records) are short notes that capture a decision with its context and consequences. We want to use the format not only in the frontend repo and not only for code decisions, but also for product decisions ("the merchant segment drops out of the baseline model"). The thought: in loose teams there is no employment contract, no job description, no onboarding doc. Shared memory emerges only from what gets written down. Whether the team has the discipline to stick with it is the real test.

Critical assessment

We are starting the experiment in a four-person setup. The model likely only works with small teams. Four is almost ideal, six probably still works, at eight it becomes fragile. A DACI-light matrix stays manageable as long as everyone knows everyone; as soon as subgroups form, more formal structures are needed. On top of that: without a contract, commitment only works as long as personal motivation carries it. If someone earns their salary elsewhere and does projects like this in the evening, the project competes with family, hobby, health. Rituals create social accountability but not existential accountability. That means: once the product reaches a certain maturity, the team has to resolve the contract question, otherwise you lose momentum exactly when you need it. And: ADRs as a habit sound easy, but they are culture work. Everyone writes the first ADR; only the tenth gets written if it has become routine. Whether we keep it up is an open question.

What stays with you every day

Role instead of title.

Each core function should have exactly one owner. Not two, not rotating. Speed hopefully comes from clarity, not consensus.

Ritual instead of control.

Friday three-liner, 30-minute sync every two weeks, monthly retro, 1:1 about the human. Our bet on carrying teams without a contract.

Write decisions down instead of remembering them.

Every decision someone will need to understand later is captured in an ADR (Architecture Decision Record). Not just in code, also in the product. Our substitute for the missing contract.

Glossary

ADR — Architecture Decision Record: a short note capturing a decision, its context, and its consequences

DACI-light — Decision protocol: Driver, Approver, Contributor, Informed. A stripped-down RACI variant

Owner — Person responsible for a core function who has final say within that area

Core function — A capability a product or team needs to function

Information routing — The classic hierarchy function: who knows what, when. Increasingly automatable with AI tools

Psychological safety — The feeling that you can share ideas, mistakes, or concerns in a team without fearing a disadvantage (Edmondson)