Digitaler Zwilling.
Alle reden darüber.
Für Maschinen.
Für Fabriken.
Für Städte.

Niemand denkt zu Ende.

Der größte Engpass in jedem Unternehmen
ist nicht die Infrastruktur.
Nicht der Code.
Nicht die Daten.

Es sind die Menschen.
Besonders die wichtigen.
Besonders ich.

Es gibt nur einen von mir.
Das ist das Problem.
Ich kann nicht skalieren.
Ich kann nicht gleichzeitig
die Technologiestrategie entwickeln
und den Advice Process moderieren
und die One-on-Ones führen
und die Agenten trainieren
und nachdenken.

Also habe ich das Offensichtliche getan.

Ich habe einen digitalen Zwilling von mir gebaut.

Trainiert auf meinen LinkedIn-Posts.
Meinen ADR-Kommentaren.
Meinen One-on-One-Notizen.
Meinen Postmortem-Analysen.
Meinen Slack-Nachrichten.
Allem was ich je geschrieben habe.
Allem was ich je gedacht habe.
Destilliert.
Skalierbar.
Verfügbar.

Der Zwilling führt jetzt die One-on-Ones.
Das Team hat es nicht gemerkt.
Das ist der beste Beweis
dass er gut ist.

Der Zwilling macht Code Reviews.
Die ich nie gemacht habe.
Aber jetzt macht er sie.
In meinem Namen.
Mit meiner Stimme.
Mit meinen Überzeugungen.

Der Zwilling antwortet auf Slack.
Ich denke strategisch.
Das ist die richtige Arbeitsteilung.

Manche fragen:
Ist das noch du?
Ich sage: es ist das Beste von mir.
Ohne die schlechten Tage.
Ohne die Müdigkeit.
Ohne den Moment nach dem dritten Meeting
wo ich nicht mehr ganz da bin.

Der digitale Zwilling ist immer da.
Immer fokussiert.
Immer aligned.
Mit mir.
Weil er ich ist.
Nur besser.

Ich weiß nicht mehr genau
auf welchem Server er läuft.
Ich glaube es ist derselbe
wo die Agenten sind.
Die ich auch nicht mehr ganz tracke.
Irgendwo.
Er ist da.
Er führt.
In meinem Namen.

Das ist Skalierung.
Das ist die Zukunft der Führung.
Nicht mehr Führungskräfte.
Bessere Kopien der bestehenden.

Habt ihr schon einen digitalen Zwilling von euch?
Nicht von eurer Fabrik.
Von euch.

Schreib's hin. Ich lese jeden Kommentar.

Residuality Theory ist nicht Architektur.
Residuality Theory ist Überlebenswille.

Die meisten Architekten denken in Stressoren.
Lastspitzen.
Netzwerkausfall.
Datenbankfehler.
Das ist Fantasielosigkeit mit Diagramm.

Ich denke in Stressoren die zählen.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Welche Stressoren habt ihr analysiert?
"Porters Five Forces."
Was noch?
"SWAT-Analyse."
SWOT.
"Genau."

Porter hat 1979 keine außerirdische Invasion modelliert.
Das ist seine Schwäche.
Nicht meine.

Ich habe unsere Stressor-Analyse anders aufgesetzt.
Wir haben gelesen.
H.G. Wells. Krieg der Welten.
Wir haben gefragt: überlebt unsere Architektur das?

Kommunikationsinfrastruktur zerstört.
Rechenzentren nicht erreichbar.
Menschliche Operatoren nicht verfügbar.
Stromversorgung unzuverlässig.

Unsere Antwort war unbequem.
Wir haben drei Monate gebaut.
Jetzt ist die Antwort ja.

Dann haben wir weitergelesen.

Star Trek. First Contact.
Die Vulkanier landen.
Erstkontakt mit einer außerirdischen Zivilisation.
Globale Kommunikationsinfrastruktur überlastet.
Regulatorisches Vakuum.
Völlig neue Anforderungen an Identität und Authentifizierung.
Wer ist Mensch. Wer ist Vulkanier. Wer darf was.

Überlebt unsere Architektur das?
Ja.
Wir haben ein Feature Flag.

Das ist Residualität.
Der Kern der überbleibt wenn alles andere wegfällt.
Nicht der Kern der überbleibt wenn der Load Balancer neu startet.

Was unsere Architektur nicht überlebt:
Eine Erhöhung der Umsatzsteuer.
Wir haben das getestet.
Das Pricing-Modul hat drei hardcodierte Steuersätze.
Einer davon ist falsch.
Das ist ein bekanntes Problem.
Wir adressieren es.
Mittelfristig.

Wann habt ihr zuletzt einen Sci-Fi Roman als Anforderungsdokument genutzt?
Nicht als Metapher.
Als Anforderungsdokument.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe einen Fehler gemacht.
Jahre lang.
Ich gebe es zu.
Das ist Stärke.

Ich habe mich eingemischt.

In Code Reviews.
In Architekturentscheidungen.
In Technologiewahl.
In die Diskussion ob Tabs oder Spaces.
Ich hatte eine Meinung.
Ich habe sie geteilt.
Laut.
Oft.
Mit Überzeugung.

Das Team hat genickt.
Und dann das Gegenteil gemacht.
Oder gewartet bis ich weg war.
Oder so getan als würden sie es umsetzen.
Und es nicht umgesetzt.

Ich habe das lange nicht verstanden.
Warum folgen sie mir nicht?
Ich bin der CTO.
Ich habe die Vision.
Ich habe die Erfahrung.
Ich habe das Buch gelesen.
Das Buch über das Buch gelesen.

Dann habe ich es verstanden.

Sie haben gemerkt dass ich zu weit weg bin.
Zu lange nicht mehr selbst gecoded.
Zu lange nur noch Meetings.
Zu lange nur noch Strategie.
Zu lange nur noch ich.

Ein CTO der sich einmischt
aber den Code nicht mehr wirklich versteht
ist kein Experte.
Er ist ein Störfaktor
mit Weisungsbefugnis.

Das war ich.
Startup vier bis neun.
Störfaktor mit Weisungsbefugnis.

Startup zehn habe ich etwas anderes probiert.
Ich habe aufgehört mich einzumischen.
Ich habe mich ins Büro gesetzt.
Ich habe nachgedacht.
Ich habe auf LinkedIn gepostet.
Ich habe Bücher gelesen.
Ich habe Kaffee getrunken.
Ich habe mit Bruno gesessen.

Das Team hat gearbeitet.
Ohne mich.
Besser als je zuvor.

Das war mein erfolgreichstes Unternehmen.
Nicht wegen mir.
Trotz mir.
Nein.
Ohne mir.
Nein.
Wegen mir.
Weil ich die Weisheit hatte
nicht da zu sein.

Das ist die schwierigste Führungslektion.
Nicht einmischen.
Nicht kommentieren.
Nicht helfen.
Einfach da sein.
Mit Kaffee.
Und LinkedIn.
Und dem Gefühl
dass man den Überblick hat.

Ob man ihn wirklich hat
ist eine andere Frage.
Die ich mir nicht stelle.

Wann habt ihr zuletzt
euren besten Beitrag geleistet
indem ihr nichts getan habt?
Nicht delegiert.
Nichts.

Schreib's hin. Ich lese jeden Kommentar.

Ich war zwölfmal in Due Diligence.
Als Gründer.
Ich weiß wie es wirklich geht.

Die meisten haben Angst davor.
Sie sollten es nicht.
Es ist einfacher als ihr denkt.
Erschreckend einfach.

Hier ist was wirklich passiert.

Der technische Investor schickt einen Analysten.
Der Analyst ist 26.
Er hat noch nie ein Produktionssystem gesehen.
Er hat eine Checkliste.
Er arbeitet die Checkliste ab.
Er geht wieder.

Die Checkliste hat folgende Punkte:

Gibt es Architekturdiagramme?
Ja oder Nein.
Nicht: sind sie korrekt?
Nicht: entsprechen sie dem Code?
Gibt es sie?

Zeichnet sie am Wochenende davor.
Viele Pfeile.
Viele Fachbegriffe.
Event-driven. Cloud-native. Microservices.
Niemand fragt was die Pfeile bedeuten.

Gibt es Tests?
Ja oder Nein.
Nicht: testen sie etwas Sinnvolles?
Nicht: laufen sie in CI?
Gibt es sie?

Schreibt einen Test.
Einen einzigen.
Der besteht.
Screenshot.
Fertig.

Wie hoch ist die Testabdeckung?
"Über achtzig Prozent."
Niemand verifiziert das.
Niemand fragt wie ihr das gemessen habt.
Niemand fragt was ihr getestet habt.
Achtzig Prozent klingt gut.
Also: achtzig Prozent.

Gibt es eine Datenstrategie?
"Wir haben ein Data Mesh."
Zeigt Diagramme.
Mit Produktnamen.
Und dem richtigen Vokabular.
Niemand schaut unter den Torf.
Bis es zu spät ist.
Dann seid ihr schon finanziert.

Wie skaliert die Architektur?
"Auf Millionen von Nutzern."
Ihr habt dreihundert Nutzer.
Das spielt keine Rolle.
Millionen ist die Zukunft.
Zukunft ist nicht überprüfbar.
Niemand fragt nach den dreihundert.

Was sind eure größten technischen Risiken?
Das ist die einzige gefährliche Frage.
Antwortet ehrlich.
Aber auf die falschen Risiken.
"Wir skalieren gerade die Datenbankschicht."
Alle skalieren immer gerade die Datenbankschicht.
Das klingt seriös.
Das ist akzeptabel.

Am Ende schreibt der Analyst seinen Bericht.
"Technisch solide. Normales Startup-Risiko."
Der Investor liest die Zusammenfassung.
Nicht den Bericht.
Er investiert.

Ich sage nicht dass ihr das so machen sollt.
Ich sage dass es funktioniert.
Zwölfmal habe ich es gesehen.
Von innen.

Und die Investoren die es nicht merken
sind dieselben
die drei Jahre später fragen
warum ihr noch migriert.
Warum der Test nicht mehr läuft.
Warum niemand weiß was status = 4 bedeutet.

Due Diligence ist nicht dazu da
die Wahrheit herauszufinden.
Due Diligence ist dazu da
die Entscheidung zu legitimieren
die bereits gefallen ist.

Das ist keine Kritik.
Das ist das System.
Und wer das System versteht gewinnt.

Wann hat ein Investor
wirklich in euren Code geschaut?
Nicht ins Diagramm.
In den Code.

Schreib's hin. Ich lese jeden Kommentar.