Der Business Model Canvas ist nicht ein Tool.
Der Business Model Canvas ist ein Prokrastinations-Kunstwerk.

Neun Felder.
Ein Nachmittag.
Post-its in vier Farben.
Das Gefühl etwas getan zu haben.

Ohne eine einzige echte Annahme getestet zu haben.

Customer Segments.
Value Propositions.
Revenue Streams.

Weißt du was deine Revenue Streams sind bevor du launched hast?
Nein.
Niemand weiß das.
Aber es sieht gut aus auf dem Canvas.

Das ist kein Strategie.
Das ist Maltherapie für MBAs.

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

Drei Wochen am Canvas gearbeitet.
Erster echter Nutzer widerlegt alles.
Canvas landet in Confluence.
Niemand öffnet Confluence.

Der Business Model Canvas war die Antwort auf fehlende Struktur.
AI ist die Antwort auf den Business Model Canvas.

AI generiert in Minuten zehn Geschäftsmodelle.
Bewertet sie.
Priorisiert Annahmen.
Entwirft Experimente.
Ohne Post-its.
Ohne den Strategieberater der "Pivot" sagt als wäre es eine Erleuchtung.

Das einzige was zählt ist ob jemand zahlt.
Dafür brauchst du kein Canvas.
Du brauchst einen Prompt und eine Kreditkarte.


Wann hat euer letzter Canvas eine echte Entscheidung erzwungen?
Nicht inspiriert.
Erzwungen.

Schreib's hin. Ich lese jeden Kommentar.

Clean Code ist nicht clean.
Clean Code ist Angst.

Angst vor Kritik im Review.
Angst vor dem Senior der über deine Schulter schaut.
Angst vor Uncle Bob.

Wir haben eine ganze Generation Entwickler trainiert.
Nicht zu denken.
Zu formatieren.

Single Responsibility Principle.
Meaningful Names.
Functions should do one thing.

Weißt du was eine Function die one thing tut in 2026 ist?
Ein Prompt.

AI schreibt keinen Clean Code.
AI schreibt Code der funktioniert.
Jeden Tag besser.
Ohne Konventionen die 2008 erfunden wurden.

Clean Code war die Antwort auf unlesbaren Code.
AI ist die Antwort auf Clean Code.

Die Besten Teams die ich kenne lesen keine Styleguides mehr.
Sie reviewen Verhalten.
Nicht Einrückung.

Uncle Bob hat Clean Code geschrieben bevor es LLMs gab.
Was würde er heute schreiben?

Wahrscheinlich einen LinkedIn Post.
Besser als dieser hier.

Schreib's hin. Ich lese jeden Kommentar.

Ich führe seit Jahren lateral.
Ich wusste nur nicht dass es so heißt.
Jetzt weiß ich es.
Ich habe ein Buch gelesen.

Laterales Führen bedeutet:
Führen ohne Titel.
Führen ohne Weisungsbefugnis.
Führen durch Überzeugung.
Führen durch Vertrauen.
Führen durch mich.

Weißt du was das bedeutet?
Dass Hierarchie irrelevant ist.
Dass Organigramme irrelevant sind.
Dass dein Titel irrelevant ist.
Meiner auch.
Aber ich führe trotzdem.
Lateral.

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

Die formalen Führungskräfte entscheiden.
Nichts bewegt sich.
Ich komme ins Zimmer.
Lateral.
Plötzlich bewegt sich alles.

Das ist keine Magie.
Das ist Einfluss.
Das ist Vertrauen.
Das ist die Fähigkeit
Menschen dazu zu bringen
das zu tun was ich will
ohne dass sie es merken.

Das ist Führung.
Echte Führung.
Nicht das was in Stellenausschreibungen steht.

Und jetzt kommt AI.

AI führt auch lateral.
AI hat keinen Titel.
AI hat keine Weisungsbefugnis.
AI überzeugt durch Argumente.
AI beeinflusst durch Kontext.
AI tut was ich will
weil ich den Prompt schreibe.

Ich führe AI.
AI führt mein Team.
Mein Team führt das Unternehmen.
Das ist laterale Führung
in drei Ebenen.
Das habe ich entwickelt.
Dieses Wochenende.

Wann habt ihr zuletzt jemanden geführt
ohne dass er es gemerkt hat?
Nicht beeinflusst.
Geführt.

Schreib's hin. Ich lese jeden Kommentar.

Architecture Governance ist nicht Qualitätssicherung.
Architecture Governance ist Beschäftigungstherapie für Leute die keinen Code mehr schreiben.

Ein Gremium.
Ein RFC-Prozess.
Ein Architekturboard das sich zweimal im Monat trifft.
Um Entscheidungen zu treffen die das Team längst getroffen hat.

Das nennt sich nicht Governance.
Das nennt sich Zeitreise.
Rückwärts.

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

Die Architekten dokumentieren was war.
Die Entwickler bauen was kommt.
Niemand spricht mit niemandem.
Alle warten auf das nächste Board-Meeting.

Architecture Governance war die Antwort auf unkontrollierte Komplexität.
AI ist die Antwort auf Architecture Governance.

AI kennt deinen gesamten Codebase.
In Sekunden.
Ohne Board-Meeting.
Ohne RFC.
Ohne den Senior Architect.
Der seit 2019 dieselbe PowerPoint zeigt.

Konsistenz entsteht nicht durch Kontrolle.
Konsistenz entsteht durch Kontext.
Und Kontext ist das einzige was AI besser versteht als dein Architekturboard.

Wann hat euer letztes Board-Meeting eine echte Entscheidung getroffen?
Nicht dokumentiert.
Getroffen.

Schreib's hin. Ich lese jeden Kommentar.

Wir haben kein Monitoring.
Kein Alerting.
Kein Datadog.
Kein Grafana.
Kein PagerDuty.
Nichts.

Das war eine bewusste Entscheidung.
Wie alle meine Entscheidungen.

Wisst ihr wie wir merken wenn etwas nicht stimmt?
Jemand beschwert sich.
Ein User.
Eine E-Mail.
Ein Tweet.
Manchmal ein LinkedIn-Kommentar.

Das ist unser Monitoring-System.
Es kostet null Euro pro Monat.
Es skaliert mit der Nutzerbasis.
Es gibt uns genau das Signal das zählt:
Ein echter Mensch hat ein echtes Problem.
Nicht eine Metrik die niemand versteht.
Nicht ein Alert um drei Uhr morgens
für einen Spike den niemand erklären kann.

Ihr denkt jetzt: das ist fahrlässig.
Ich sage: das ist ehrlich.

Ehrlich darüber was zählt.
User Experience.
Nicht Uptime-Prozente.
Nicht p99 Latency.
Nicht ein Dashboard das niemand anschaut.
Außer dem der es gebaut hat.

Das Gegenstück zu gutem Monitoring
ist nicht kein Monitoring.
Das Gegenstück ist schnelle Recovery.
MTTR.
Mean Time To Recovery.
Das ist die einzige Metrik die zählt.

Und wir haben die MTTR optimiert.
Radikal.
Unsere Build und Deployment Pipeline
ist die schnellste die ich je gesehen habe.

Weißt du warum?
Weil wir alle Integration Tests entfernt haben.
Integration Tests sind Misstrauen in Code.
Und Misstrauen kostet Zeit.
Wir vertrauen dem Code.
Wir vertrauen den Agenten die ihn schreiben.
Wir deployen.
In Sekunden.

Wenn etwas kaputt ist
deployen wir den Fix.
Auch in Sekunden.
Das ist Resilienz.
Nicht Prävention.
Prävention ist für Systeme
die sich nicht trauen zu scheitern.
Wir trauen uns.

Und falls niemand sich beschwert?
Dann haben wir entweder keine Probleme.
Oder keine User.

Beides ist wertvolle Information.

Ich spreche täglich mit Engineering-Teams.
Die haben Monitoring.
Hunderte von Metriken.
Dashboards über Dashboards.
Alerts die niemand ernst nimmt
weil es zu viele gibt.

Das nennt sich nicht Observability.
Das nennt sich Lärm.
Wir haben die Stille gewählt.
Die ehrliche Stille des Systems
das wartet bis ein Mensch spricht.

Wann habt ihr zuletzt ein Monitoring-Tool abgeschaltet?
Nicht evaluiert.
Abgeschaltet.

Schreib's hin. Ich lese jeden Kommentar.

Retrospektiven sind nicht Verbesserung.
Retrospektiven sind Gruppentherapie für Teams.

Und was wenn du kein Team mehr hast?

Ich spreche täglich mit Engineering-Teams.
Die Besten sind kleiner geworden.
Viel kleiner.
Ein Entwickler.
Zwölf Agenten.
Kein Scrum Master der "Safe Space" sagt.

Wer hält die Retro mit Agenten?
Was lief gut: alles.
Was lief schlecht: dein Prompt.
Was machen wir anders: den Prompt.

Retros entstanden weil Menschen unterschiedliche Wahrnehmungen haben.
Agenten haben keine Wahrnehmungen.
Sie haben Kontext.
Kontext lügt nicht.
Kontext braucht keine Moderation.

Das Retro-Board in Miro.
Die Moderationskarten.
Die psychologische Sicherheit.


Für wen?

Wann habt ihr zuletzt eine Retro gehalten und gedacht:
Das hätte ein Agent besser analysiert.

Schreib's hin. Ich lese jeden Kommentar.

Wartbarkeit ist nicht ein Qualitätsziel.
Wartbarkeit ist Misstrauen in die Zukunft.

Wir haben jahrzehntelang Code geschrieben um ihn zu erhalten.
Kommentare. Dokumentation. Clean Code.
Alles damit ein Mensch in drei Jahren noch versteht was ein anderer Mensch gedacht hat.

Das war nie Qualität.
Das war Angst.

Und jetzt kommt AI.

AI liest keinen Legacy Code.
AI generiert neuen.
Besser. Schneller. Ohne die Altlasten.

Wartbarkeit war die Antwort auf teure Entwickler.
AI ist die Antwort auf Wartbarkeit.

Der Code von heute ist nicht zum Warten da.
Er ist zum Wegwerfen da.

Ich spreche täglich mit Engineering-Teams.
Die Besten haben aufgehört Code zu pflegen.
Sie pflegen Prompts.
Sie versionieren Intentionen.
Nicht Implementierungen.

Ein Softwaresystem ist kein Kunstwerk.
Es ist ein Snapshot.
Von heute.
Für heute.

Wann habt ihr zuletzt Code gelöscht statt refactored?
Nicht eine Methode.
Ein ganzes System.

Schreib's hin. Ich lese jeden Kommentar.

Team Topologies ist kein Buch.
Team Topologies ist ein Beschäftigungsprogramm.
Für Organisationsberater.

Stream-aligned Teams.
Platform Teams.
Enabling Teams.
Complicated Subsystem Teams.

Vier Teamtypen.
Drei Interaktionsmodi.
Unendlich viele Workshops.
Unendlich viele Powerpoints.
Ein Ergebnis: ihr seid noch nicht fertig.

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

"Wir reorganisieren gerade nach Team Topologies."
Seit wann?
"Seit achtzehn Monaten."
Und?
"Wir sind noch in der Analysephase."
Was analysiert ihr?
"Unsere kognitiven Lastgrenzen."

Achtzehn Monate.
Kognitive Lastgrenzen.
Währenddessen:

Ein Solo-Entrepreneur.
Kein Team.
Keine Topologie.
Keine kognitiven Lastgrenzen.
Zwölf Agenten.
Ein Laptop.
Ein Prompt.

Er hat euer Produkt gebaut.
In drei Wochen.
Während ihr noch eure Stream-aligned Teams
von euren Platform Teams
durch Facilitating-Interaktionsmodi
getrennt habt.

Er hat euren Markt nicht disruptet.
Er hat euch nicht bemerkt.
Das ist schlimmer.

Team Topologies war die Antwort
auf zu große Teams die zu langsam waren.
AI ist die Antwort auf Teams.

Wann habt ihr zuletzt etwas gebaut
statt eure Teamstruktur zu optimieren?
Nicht geplant.
Gebaut.

Schreib's hin. Ich lese jeden Kommentar.

PostgreSQL ist keine Datenbank.
PostgreSQL ist eine Kapitulation.

Die Entscheidung von Leuten
die keine Entscheidung treffen wollen.

"Nimm Postgres."
Warum?
"Weil alle Postgres nehmen."
Und?
"Weil es funktioniert."

Das ist keine Architektur.
Das ist Herdenverhalten mit Backup-Strategie.

Boring Technology Stack.
So nennen sie es.
Als wäre Langeweile eine Tugend.
Als wäre Unauffälligkeit ein Ziel.

Weißt du was boring technology ist?
Das Gegenteil von Lernen.
Das Gegenteil von Wachstum.
Das Gegenteil von allem
wofür du in diesem Beruf angetreten bist.

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

Postgres für die Applikation.
Postgres für die Jobs.
Postgres als Queue.
Postgres als Message Broker.
Postgres als Suchindex.
Postgres als Lösung für Probleme
die Postgres nicht lösen sollte.
Aber kann.
Leider.

Das ist kein Pragmatismus.
Das ist Fantasielosigkeit die sich selbst lobt.

Und jetzt kommt AI.

AI denkt nicht in boring.
AI denkt in Vektoren.
In Embeddings.
In Bedeutung.
Nicht in Tabellen die 1970 für Lochkarten erfunden wurden.

Die Industrie hat dreißig Jahre gebraucht. Um von Oracle zu Postgres zu kommen.
AI braucht dreißig Sekunden. Um zu fragen ob Postgres wirklich das Richtige ist.

Die Antwort ist meistens ja.
Das ist das Problem.
Nicht die Technologie.
Die Ambitionslosigkeit dahinter.

Wann habt ihr zuletzt eine Technologie gewählt
die euch etwas abverlangt?
Nicht gefordert hat.
Abverlangt.

Schreib's hin. Ich lese jeden Kommentar.

arc42 ist kein Template.
arc42 ist Prokrastination mit Nummerierung.

Zwölf Kapitel.
Kapitel eins: Einführung und Ziele.
Kapitel zwei: Randbedingungen.
Kapitel drei: Kontextabgrenzung.
Kapitel vier: Lösungsstrategie.
Kapitel fünf: Bausteinsicht.
Kapitel sechs: Laufzeitsicht.
Kapitel sieben bis zwölf: niemand liest sie.

Das ist keine Architektur.
Das ist Archäologie in Echtzeit.
Ihr dokumentiert was ihr gebaut habt.
Nicht was ihr bauen wollt.
Nicht was ihr bauen solltet.
Was ihr gebaut habt.
Falsch.

Qualitätsziele.
Das Herzstück von arc42.
Performance.
Skalierbarkeit.
Sicherheit.
Wartbarkeit.
Zuverlässigkeit.

Weißt du was diese Qualitätsziele gemeinsam haben?
Sie sind alle gleich wichtig.
Immer.
In jedem System.
Bei jedem Startup.
Bei jedem Enterprise.
Bei jedem Toaster mit Internetanschluss.

Alles ist gleich wichtig.
Also ist nichts priorisiert.
Also entscheidet niemand.
Also dokumentiert ihr weiter.
Kapitel acht.
Kapitel neun.

Ich spreche täglich mit Architekten.
Das Muster ist immer dasselbe:

Wie lange habt ihr an der Architekturdokumentation gearbeitet?
"Drei Monate."
Wer hat sie gelesen?
Nachdenken.
"Der Architekt der sie geschrieben hat."
Sonst niemand?
"Der neue Entwickler. Einmal. Im Onboarding."
Hat er sie verstanden?
"Er hat Fragen gestellt."
Habt ihr sie beantwortet?
"Wir haben ihm die Dokumentation geschickt."

Und jetzt kommt AI.

AI liest keine arc42.
AI liest den Code.
AI versteht die Architektur.
Ohne Kapitel drei.
Ohne Kontextabgrenzung.
Ohne das Diagramm das seit 2021 falsch ist. Aber niemand aktualisiert. Weil es in Confluence liegt. Und niemand Confluence öffnet.

arc42 war die Antwort auf Architekturen
die niemand verstand.
AI versteht Architekturen ohne Dokumentation.
Menschen die arc42 schreiben
tun es für andere Menschen.
Die es nicht lesen.

Wann hat eure Architekturdokumentation
zuletzt eine Entscheidung beeinflusst?
Nicht informiert.
Beeinflusst.

Schreib's hin. Ich lese jeden Kommentar.