Jeder neue KI-Workflow bekommt bei mir eine Probezeit

Ich habe mir einmal eine Stelle geschaffen, für die ich keine Arbeit hatte, die eines Chief of Staff. In einem YouTube-Video bin ich auf jemanden gestoßen, der sich genau so einen digitalen Stabschef eingerichtet hatte. Ich habe das Setup in ChatGPT for Work nachgebaut und danach kein einziges Mal benutzt. Meinen automatisierten Morning Briefings mit einem Überblick aus Kalender, Slack, Asana und Github ist es genauso ergangen.

Meine erste Erklärung war: Offenbar fehlt mir die Disziplin, die andere haben. Diese Erklärung war aber bequem, denn solange es an meiner Disziplin lag, musste ich die Werkzeuge selbst nicht infrage stellen. Sie war auch falsch. Erst der Nachbau des Chief of Staff hat mir gezeigt, dass ich ein fremdes Setup kopiert hatte, ohne ein eigenes Problem, das er hätte lösen sollen. Keines dieser Systeme hatte ein echtes Problem gelöst.

Inzwischen behandle ich jeden neuen KI-Workflow wie einen Mitarbeiter auf Probe: mit einem echten Aufgabenbereich, einem begrenzten Zeitraum und Erwartungen, die vorher feststehen. Einen festen Platz verdient er erst, wenn er in dieser Probezeit hält, was vereinbart war.

Gebaut, aber nie genutzt

Das lehrreichste Beispiel war mein persönliches Relationship-Management-Tool. Ich habe es selbst gebaut, mit vielen guten Ideen: Kontakte pflegen, Gespräche wieder aufnehmen und niemanden vergessen. Nach jedem Treffen auf einem Event verlangte es allerdings Nacharbeit von mir: welche Themen die Person interessieren, worüber wir gesprochen haben und warum ich mich wieder melden will. Nach dem Codex & OpenClaw Meetup im April (öffnet in neuem Fenster) wollte es für über 20 Personen wissen, was wir geredet hatten. Am Weg heim war ich dafür zu müde. Am nächsten Tag schienen Arbeitsaufgaben wichtiger, und so hatte ich in dem Tool nie etwas erfasst. Wenn ich mehr Überblick haben will und dafür regelmäßig selbst mehr Inhalte pflegen muss, funktioniert das für mich nie. Ich habe daraus gelernt, dass die Pains groß genug sein müssen, um irgendwelche Arbeit von mir als Teil des Prozesses zu planen.

Denselben Fehler hatte ich vorher schon mit einer echten Stelle gemacht: Ich habe Jessica als Assistenz eingestellt, nach der Logik von Dan Martells Buch „Buy Back Your Time“ (öffnet in neuem Fenster): erst die Aufgaben abgeben, die einen aufhalten, dann die nächsten. Am Ende gab es für diese Rolle bei uns aber zu wenig Arbeit. Das lag nicht an ihr, sondern an mir: Ich hatte eine Vorlage aus einem anderen Unternehmen übernommen. Einfache organisatorische Aufgaben, die sich weiterreichen lassen, gibt es in meinem Alltag weniger, als das Buch beschreibt. Ein großer Teil meiner Arbeit verlangt tiefes technisches Wissen, denn in einer Software-Entwicklungsfirma sind selbst Assistenz-Aufgaben oft sehr technisch.

Genau hier liegt der Unterschied: Eine echte Stelle probiert man nicht mal eben aus. Einen KI-Workflow schon. Also habe ich im Februar angefangen, für einzelne Teilaufgaben aus diesem Bereich eine „Jessica AI“ zu bauen, mehrmals und in verschiedenen Varianten. Das Beeindruckende daran war ihr technisches Verständnis: Sie kamen an genau die Aufgaben heran, die bei mir liegen bleiben, weil sie technisches Wissen verlangen. Wirklich hilfreich war trotzdem nur ein kleiner Teil davon. Geblieben ist keine einzige.

Mein Learning war, was in einem anderen Unternehmen funktioniert, ist für mich vielleicht nicht der richtige Weg. Bei einer Software kostet dieser Irrtum ein paar Programmierabende. Bei einer Stelle kostet er deutlich mehr Zeit, Geld, und gleich zwei Personen enttäuscht.

Was von den Experimenten geblieben ist

Was von den Jessica-AI-Versuchen blieb, ist ihr Gedächtnis: mein Obsidian Vault, eine strukturierte persönliche Notizsammlung. Dort pflege ich den Status von Projekten, privat und beruflich, Brainstormings und Konzepte, dazu Informationen über mich selbst, inklusive Persönlichkeitsanalyse und Reflexionen. Diese Kontextbasis speist heute viele einzelne ChatGPT-for-Work-Threads und einige automatische Abläufe, die nach Zeitplan laufen. Sie hat ihre Probezeit bestanden, ohne dass ich sie damals so genannt hätte. Ich vermute, das ist der Grund: Sie zahlt sofort zurück — jeder Thread, der auf diesen Kontext zugreift, liefert eine Antwort, die wirklich mich meint, statt einer für irgendwen. Eine Serie von Verhaltensstudien zur Verfolgung langfristiger Ziele (öffnet in neuem Fenster) fand denselben Mechanismus bei ganz anderen Zielen: Unmittelbare Belohnungen sagten das Durchhalten besser vorher als spätere.

Bei Code Q sehe ich dasselbe an unserem NeosDevelopmentEnvironment, einem internen Setup: Es dockt an echte Entwicklungsarbeit an, die ohnehin stattfindet, bündelt den Kontext unserer Projekte und produziert Skills, die wir direkt weiterverwenden.

Fünf Fragen vor dem Bau

Aus diesen Erfahrungen ist ein Test geworden, den ich vor jedem Workflow-Bau durchgehe:

Wo die Probezeit an ihre Grenzen stößt

Erstens funktioniert die Probezeit nur bei Abläufen, die du allein entscheidest. Sobald ein Workflow mehrere Leute betrifft, braucht die Probezeit zusätzlich einen Owner, Freigaberegeln und ein Gespräch darüber, welche Entscheidungen bei Menschen bleiben.

Zweitens hat nicht jeder wertvolle Workflow einen häufigen Auslöser. Bei seltenen Risiko-Abläufen — etwa der Nachbesprechung von Störfällen — ist der Nutzen vermiedener Schaden, nicht tägliche Erleichterung. Googles Handbuch für den Betrieb großer Systeme (öffnet in neuem Fenster) rechnet in die Bilanz einer Automatisierung auch Ausfallsicherheit und Standardisierung ein. Der Nutzennachweis muss zum Workflow passen und darf entsprechend später kommen.

Nicht bauen ist auch ein Ergebnis

Den Chief of Staff schreibe ich wieder aus, sobald es die Arbeit gibt, die er übernehmen soll. Solange die fehlt, hilft auch kein besseres Setup. Bis dahin bleibt die Stelle unbesetzt.

Wenn du deine eigenen Systeme in die Probezeit schicken willst, nimm diesen Prompt: