Nach einem großen Transformationsprogramm darf man kurz feiern. Vor allem, wenn es sechs Monate vor der Zeit abgeschlossen wurde, ein IT- und Transformationsvorhaben im dreistelligen Millionenbereich stabil in die Umsetzung kam — und im Rating-Kontext sichtbar wurde, dass die Organisation ihre Fähigkeit gestärkt hat, große Vorhaben wirksam umzusetzen.
Das ist mehr als ein Projekterfolg. Es zeigt Responsiveness, Umsetzungsfähigkeit und organisatorische Leistungsfähigkeit.
Aber irgendwann ist die letzte Lenkungsausschuss-Unterlage abgelegt. Und dann kommt die eigentliche Frage: Was mache ich jetzt mit der Zeit, der Erfahrung — und der Neugier?
Meine Antwort: wieder arbeiten. Nicht nur strategisch. Praktisch. Noch praktischer.
Ich habe mir nach dem erfolgreichen Abschluss bewusst Zeit genommen, um mich wieder selbst tiefer mit Technologie zu beschäftigen. Nicht nur, um sie intellektuell besser zu verstehen. Sondern durchs Machen.
Dabei ging es mir nicht darum, schnell irgendein einzelnes Problem mit Technik zu lösen. Es ging mir darum, wieder systematisch zu erleben, wie moderne technologische Lösungen heute entstehen: von der Idee über erste Prototypen bis hin zu Cloud, Programmierung, GitHub, Kontrolle, Deployment und Betrieb.
Also nicht nur: Was kann ein Tool? — sondern:
Wie wird daraus eine belastbare Lösung?
Wo wird es einfach, wo kompliziert?
Wo entstehen Sicherheits-, Qualitäts- oder Governance-Fragen?
Und an welcher Stelle merkt man, dass eine gute Demo noch lange kein guter Betrieb ist?
Ein wichtiger Impuls war ein persönliches Bootcamp in Thailand — bei einem Freund und ehemaligen Kollegen, der dort mehrere Unternehmen aufgebaut hat, darunter auch ein KI-Start-up. Das hat mich fasziniert. Nicht, weil plötzlich alles einfach wäre. Sondern weil sichtbar wurde, wie viel heute möglich ist, wenn drei Dinge zusammenkommen: Kontextwissen, ein relevantes Problem und eine klare Idee, was besser werden soll.
Dann braucht man nicht immer sofort eine Heerschar von Menschen, ein Großprojekt und zwölf Vorstudien. Manchmal reicht ein kleiner, gut verstandener Anwendungsfall — und die Bereitschaft, ihn konsequent durchzuarbeiten.
Rechner auf. Problem hinlegen. Kontext geben. Lösung bauen. Testen. Lernen. Verbessern. Versionieren. Deployen. Genau das interessiert mich.
Was ist beeindruckend, aber noch nicht belastbar? Was spart Zeit? Was erzeugt neue Risiken? Was ist Substanz — und was ist nur Demo-Zauber?
Und vielleicht am wichtigsten: Welche Erfahrung muss man selbst gemacht haben, um später anderen glaubwürdig zu sagen, wo Chancen liegen — und wo Leitplanken notwendig sind?
Ich arbeite dabei bewusst zuerst an mir selbst. Mein eigenes Arbeitsumfeld ist das Testfeld: Dokumente, E-Mails, Kalender, Wissen, Aufgaben, Ideen, Routinen, Entscheidungen.
Daraus entsteht mein eigenes Self.Ops — ein persönliches Betriebssystem für Klarheit, Fokus, Wissensarbeit und bessere Entscheidungen.
Das beginnt manchmal sehr bodenständig: endlich die eigenen Dokumente sauber aufräumen. Wirklich paperless werden. Wissen wieder auffindbar machen. Ablagen so strukturieren, dass sie nicht nur gut gemeint, sondern auch nutzbar sind. Also genau die Dinge, die man anderen seit Jahren empfiehlt — und irgendwann selbst konsequent machen sollte.
Aber es bleibt nicht bei Ordnung. Ich bin inzwischen an dem Punkt, an dem ich einzelne Aufgaben gezielt an eigene kleine Helferlein übergeben kann: Agents, Workflows und spezialisierte KI-Assistenten. Nicht blind. Nicht aus Spieltrieb. Und nicht, weil Automatisierung an sich schon ein Wert wäre. Sondern nachdem ich geprüft habe:
Arbeiten sie zuverlässig?
Verstehen sie den Kontext?
Liefern sie fachlich richtige Ergebnisse?
Sparen sie wirklich Zeit?
Oder verbrennen sie am Ende mehr Aufmerksamkeit, als sie zurückgeben?
Genau dort wird es interessant. Denn gute Delegation an Technologie folgt ähnlichen Prinzipien wie gute Delegation an Menschen: Man muss wissen, was man übergibt, welche Qualität erwartet wird, wo Kontrolle notwendig ist — und wann man eine Aufgabe besser selbst erledigt.
Aus dieser Arbeit ist für mich ein kleines eigenes Framework entstanden — mit verschiedenen Technologien, Workflows, KI-Werkzeugen, Cloud-Komponenten, GitHub zur Versionierung und ersten Deployment-Erfahrungen.
Nicht, weil ich daraus ein Softwareprodukt machen möchte. Ich baue keine Softwarefabrik auf und komme nicht mit einer fertigen Plattform, die Kunden übernehmen sollen. Das Framework dient dazu, eigene Erfahrung aufzubauen, Fallstricke zu verstehen und besser beurteilen zu können, was heute möglich ist — und was eben noch nicht belastbar genug ist.
Diese Erfahrung kann in der Beratung wertvoll werden: im Executive Sparring, bei Transformationsfragen, bei der Einordnung von Digitalisierungs- und Automatisierungsinitiativen oder auch in Architekturgesprächen mit IT-Verantwortlichen. Nicht als Produktverkauf. Sondern als glaubwürdige, praktische Erfahrung aus erster Hand.
Nicht Software verkaufen, sondern Urteilskraft aufbauen.
Je mehr ich praktisch damit arbeite, desto klarer wird: Die eigentliche Veränderung liegt nicht nur in der Technik. Sie liegt auch im Umgang damit.
Wie arbeite ich mit KI?
Wie verändert das meine Abläufe?
Wie bereite ich Entscheidungen vor?
Wie sortiere ich Informationen?
Wie delegiere ich Aufgaben?
Wie überprüfe ich Ergebnisse?
Wie verändert sich Führung, wenn nicht mehr jede Zuarbeit von Menschen kommt — aber Verantwortung trotzdem beim Menschen bleibt?
Diese Fragen sind mindestens so wichtig wie die technische Architektur. Denn Digitalisierung, Automatisierung und KI verändern nicht nur Prozesse. Sie verändern Aufmerksamkeit, Zusammenarbeit, Führung und Entscheidungsqualität.
Gerade deshalb reicht es nicht, sich einmal eine Tool-Demo anzusehen. Man muss erleben, wie sich Arbeit tatsächlich verändert, wenn Kontext, Daten, Automatisierung und persönliche Arbeitsweise zusammenkommen.
Mich interessiert nicht, jedes neue Tool sofort wichtig zu finden. Mich interessiert, das Wichtige vom weniger Wichtigen zu trennen.
Wie unterscheiden sich Claude, ChatGPT, Gemini und andere Werkzeuge wirklich?
Welche Aufgaben lassen sich sinnvoll delegieren?
Wo braucht es menschliche Führung, Urteil und Verantwortung?
Wie viel Kontext braucht ein System, um hilfreich zu werden?
Wie viel Kontext darf es bekommen?
Wo müssen klare Leitplanken eingezogen werden?
Gerade der Umgang mit eigenem Kontextwissen ist dabei zentral. Denn erst mit Kontext werden viele Systeme wirklich wirksam. Gleichzeitig entsteht genau dort die Frage nach Vertraulichkeit, Datenschutz, Sicherheit und Governance. Das ist kein Nebenthema. Das ist der Kern.
Aus dieser Arbeit entsteht Schritt für Schritt ein Format, das ich sicher und verantwortungsvoll mit Entscheidern teilen kann. Denn Vorstände, Geschäftsführungen und Führungsteams brauchen keine weitere Tool-Show. Sie brauchen eine geschützte Lernumgebung, in der sie selbst erleben können, was Digitalisierung, Automatisierung, Daten und KI für ihre Arbeit bedeuten.
Nicht, um selbst Entwickler zu werden. Sondern um bessere Fragen zu stellen, Chancen realistischer einzuschätzen, Risiken früh zu erkennen und die richtigen Leitplanken für ihre Organisation zu setzen.
Und sie sollen erleben, dass technologische Wirksamkeit nicht immer mit maximaler Komplexität beginnt. Oft beginnt sie mit einem klaren Problem, gutem Kontext und der Disziplin, eine einfache Lösung wirklich nutzbar zu machen.
Mein Grundsatz bleibt: Praxis vor Strategie.
Erst selbst erleben. Dann Muster erkennen. Dann einordnen. Dann übertragen. Dann skalieren.
Deshalb ist das, woran ich gerade arbeite, keine private Technikspielerei. Es ist mein eigener Erfahrungsraum für das, was ich später mit anderen tue: Orientierung schaffen, Urteilsfähigkeit stärken und aus technologischer Möglichkeit echte Führungswirksamkeit machen.
Oder einfacher gesagt: Nach den Feiern kommt die Arbeit. Und manchmal beginnt sie mit dem eigenen Scanner, einem leeren Prompt-Fenster und der Frage, warum man die private Dokumentenablage eigentlich zwanzig Jahre lang für „später" aufgehoben hat.