Delegieren an Software: Führen, wenn KI Teil des Teams ist

Ich habe acht Jahre Handball auf hohem Niveau gespielt. Führen hieß dort: Menschen in Positionen bringen, in denen sie gut sind.

Heute besteht ein Teil unseres Teams aus Software. Das hat weniger verändert, als ich dachte, und an einer Stelle mehr. Wir führen mit nano, mate und MUSTAX drei Brands mit zwei Leuten. Ohne Automatisierung wäre das nicht möglich. Aber die eigentliche Umstellung war nicht technisch. Sie war eine Führungsfrage.

Hier ist, was sich wirklich ändert, wenn du Aufgaben an Software abgibst.

Delegieren an Software ist anderes Delegieren

Wenn du einer Person eine Aufgabe gibst, gibst du eine Absicht mit. "Kümmer dich um die Retouren, sei fair zum Kunden." Der Mensch füllt die Lücken. Er merkt, wenn etwas komisch ist, und fragt nach.

Software füllt keine Lücken. Sie tut exakt, was du definiert hast, und zwar jedes Mal identisch. Das ist ihre Stärke und ihre Grenze.

Daraus folgen zwei Dinge für dich als Führungskraft:

Du musst genauer sein. Ein Prozess, den du nicht in Worten erklären kannst, lässt sich nicht abgeben. Bei uns war das Aufschreiben der eigentliche Aufwand, nicht das Bauen. Wir haben beim Automatisieren gemerkt, dass wir manche Abläufe selbst nie sauber entschieden hatten.

Du musst die Ausnahme mitdenken. Bei einem Menschen ist die Ausnahme selbstverständlich. Bei Software ist sie ein Zustand, den du planen musst. Was passiert, wenn die Daten fehlen? Wer bekommt Bescheid?

Das ist keine technische Frage. Das ist Führung. Wer entscheidet was, ab wann, mit welchem Spielraum. Wenn du Aufgaben an Menschen sauber verteilen kannst, kannst du auch an Software verteilen.

Wer verantwortlich bleibt

Die klarste Regel, die wir haben, ist auch die kürzeste: Software hat keine Verantwortung. Menschen haben Verantwortung.

Bei nano beantwortet unsere Automatisierung rund 65 Prozent der Support-Anfragen selbst. Allein die Frage "Wo ist meine Bestellung?" macht etwa 40 Prozent aller Anfragen aus, und die geht komplett automatisch raus. Trotzdem gibt es für den Support einen Menschen, der verantwortlich ist. Nicht, weil er jede Mail liest. Ihm gehört die Frage, ob der Support gut ist.

Das ist der Denkfehler, den ich oft sehe: Leute glauben, Verantwortung wandert mit der Aufgabe. Sie wandert nicht. Sie verändert nur ihre Form.

Vorher hieß Verantwortung: Ich beantworte die Mails. Heute heißt sie: Ich weiß, welche Fälle automatisch laufen, ich sehe die Zahlen, ich merke, wenn etwas kippt, und ich entscheide, was wieder zum Menschen geht.

Ganz praktisch braucht jeder automatisierte Bereich bei uns drei Dinge:

• Einen Namen. Eine Person, die zuständig ist. Nicht "das System", nicht "wir alle".
• Eine Zahl. Woran diese Person sieht, ob es gut läuft. Wie wir das im Support machen, steht in Kundenservice-KPIs, die wirklich zählen.
• Einen Notausgang. Wie man es abschaltet, wenn es Unsinn macht, ohne Entwickler.

Fehlt eins davon, ist es keine Delegation. Dann ist es Wegschauen.

Wie Vertrauen entsteht

Niemand vertraut einer Automatisierung, nur weil sie da ist. Vertrauen entsteht bei Software genauso wie bei Menschen: durch Beobachtung über Zeit.

Wir bauen deshalb in drei Stufen, und wir überspringen keine.

Stufe eins: Die Software schlägt vor, der Mensch entscheidet. Die KI schreibt den Antwortentwurf, ein Mensch liest und schickt ab. Das ist am Anfang kaum schneller. Der Sinn ist ein anderer: Du siehst bei jedem einzelnen Fall, ob der Vorschlag gut gewesen wäre.

Stufe zwei: Die Software handelt in klaren Fällen, der Mensch prüft Stichproben. Wenn die Standardanfrage in hunderten Fällen richtig beantwortet wurde, lassen wir sie laufen. Alles Unklare geht weiter an den Menschen.

Stufe drei: Die Software handelt, der Mensch sieht das Ergebnis. Kein Freigabeschritt mehr, aber ein Bericht und Alarme bei Auffälligkeiten.

Der wichtige Teil an diesem Vorgehen ist psychologisch, nicht technisch. Dein Team baut in Stufe eins ein Gefühl dafür auf, wo die Software gut ist und wo nicht. Wer diesen Schritt überspringt, bekommt entweder blindes Vertrauen oder dauerhaftes Misstrauen. Beides ist teuer.

Und ganz wichtig: Es geht auch zurück. Ein Bereich, der zu oft danebenliegt, geht wieder auf Stufe eins. Das ist kein Rückschritt, das ist der Mechanismus.

Die Sorge vor dem Ersetztwerden

Diese Sorge ist real, und man löst sie nicht mit einer Ansage im Team-Meeting.

Was bei uns funktioniert hat, ist etwas anderes: die Leute die Automatisierung bauen zu lassen, die die Aufgabe kennen. Nicht über ihren Kopf hinweg. Wer die Regeln für den Support definiert, hat vorher selbst im Support gearbeitet. Wer entscheidet, welche Rechnung automatisch durchläuft, ist der Mensch, der sie bisher geprüft hat.

Das ändert die Rolle von Betroffener zu Autor. Das ist nicht nur nett gemeint, es liefert bessere Systeme. Die Ausnahmen, an die niemand denkt, kennt nur die Person, die den Job gemacht hat.

Zwei Sätze, die ich für richtig halte:

Tätigkeiten verschwinden, Rollen nicht. Mails abtippen verschwindet. Sich um Kunden kümmern nicht. Zahlen zusammensuchen verschwindet. Zahlen verstehen nicht.

Aber es wird unbequem. Wer eine Rolle vollständig über eine Tätigkeit definiert hat, für den ist das ein echter Bruch. Das kleinzureden macht es schlimmer. Besser ist, früh und konkret zu sagen, wie die Rolle danach aussieht.

Für kleine Teams gilt dabei etwas, das gern übersehen wird: Automatisierung ersetzt bei uns niemanden. Sie verhindert Einstellungen, die wir sonst gebraucht hätten. Das ist ein Unterschied, den man aussprechen sollte. Welche Bereiche das bei uns konkret sind, steht in Skalieren ohne zu hiren.

Was Führung bleibt

Wenn Ausführung an Software geht, wird die verbleibende Führungsarbeit nicht weniger. Sie wird konzentrierter.

• Richtung geben. Welches Problem lösen wir, für wen, mit welchem Anspruch. Keine Software beantwortet das.
• Standards setzen. Wie sprechen wir mit Kunden, was versprechen wir nie, wo sind wir großzügig. Das sind die Vorgaben, aus denen Regeln erst entstehen.
• Entscheiden, was Mensch bleibt. Bei uns sind das Beschwerden mit Emotion, Sonderfälle mit Geld, alles mit rechtlicher Tragweite. Warum wir da bewusst nicht automatisieren, steht in Wann Automation keinen Sinn macht.
• Aufmerksamkeit lenken. Wenn alles Automatisierte still läuft, schaut niemand mehr hin. Führung heißt dann, den Blick regelmäßig auf die stillen Bereiche zu ziehen.
• Zeit verteidigen. Die gewonnene Zeit füllt sich von selbst mit Kleinkram, wenn du nicht entscheidest, wofür sie da ist.

Der letzte Punkt ist der, den wir selbst am häufigsten falsch machen. Über alle Brands sparen wir 33 bis 46 Stunden pro Woche. Bei mate ist die Bestellabwicklung von 4 Stunden pro Tag auf 15 Minuten geschrumpft, das Reporting bei MUSTAX von 2 Tagen auf 2 Stunden. Diese Stunden sind nur dann etwas wert, wenn du vorher weißt, wofür.

Die Grenzen

Ich will hier nichts verkaufen, deshalb die Gegenliste:

• Software als Teammitglied zu beschreiben, ist ein Bild, keine Wahrheit. Sie hat keine Absicht, kein Urteil, kein Verantwortungsgefühl. Wer das vergisst, delegiert falsch.
• Wissen geht verloren. Wenn niemand mehr Retouren von Hand bearbeitet, verlernt das Team, wie sie eigentlich funktionieren. Wir lassen deshalb bewusst Menschen regelmäßig in die Prüflisten schauen.
• Der Aufwand kommt vorne. Aufschreiben, entscheiden, Ausnahmen definieren. Wer das nicht will, sollte nicht automatisieren.
• Nicht jedes Team ist bereit. In einem Team ohne Vertrauen wird jede Automatisierung als Kontrolle gelesen. Dann löst du erst das andere Problem.
• Es bleibt Pflege. Regeln veralten, Lieferanten wechseln, Formulierungen passen nicht mehr. Ein System ohne Kümmerer wird still schlechter.

Fazit

Führen mit KI im Team ist kein neues Handwerk. Es ist dasselbe Handwerk unter schärferen Bedingungen.

Du musst klarer beschreiben, was du willst. Du musst Verantwortung ausdrücklich zuweisen, weil sie nicht mehr automatisch bei dem liegt, der die Arbeit macht. Du musst Vertrauen in Stufen aufbauen, statt es zu verordnen. Und du musst entscheiden, was Mensch bleibt, bevor jemand anders es entscheidet.

Im Sport hat mich das Prinzip nie verlassen: Es gewinnt die Mannschaft mit den klarsten Rollen, nicht die mit den meisten Talenten. Bei Software ist das genauso, sie legt unklare Rollen nur schneller offen.

Wenn du überlegst, welche Aufgaben in deinem Team zuerst an Software gehen könnten: Sprich mit uns bei Flowhouse. Wie so ein Projekt abläuft, steht in Vom ersten Gespräch zum laufenden System.