OKRs haben mein Unternehmen verändert.
Zum Besseren.
Ich erkläre wie.

Ich habe die Company Objectives selbst definiert.
Alle fünf.
Ohne Input.
Input verlangsamt.
Ich kenne die Richtung.
Das reicht.

Dann habe ich das Team gebeten
Key Results zu definieren.
Sie haben Key Results definiert.
Ich habe sie alle abgelehnt.
Zu ambitioniert.
Zu vage.
Falsch priorisiert.
Ich habe neue geschrieben.
Das nennt sich Coaching.

Hier sind unsere Key Results aus Q2:

Senior A:
"Schreibt 600 Zeilen Code pro Woche."
Erreicht: 612 Zeilen.
Grün.

Senior B:
"Schließt 8 Tickets pro Quartal."
Erreicht: 8.3 Tickets.
Grün.

Senior C:
"Hält 2 Architektur-Meetings pro Monat."
Erreicht: 2 Meetings.
Grün.

Alle grün.
Immer.
Jedes Quartal.
Das nennt sich Execution Excellence.

Nur ein Objective wurde nie erreicht.
Jedes Quartal drauf.
Jedes Quartal verschoben.

"Wir bauen eine Kultur des Vertrauens."

Key Result: "Alle Teammitglieder fühlen sich
psychologisch sicher."
Wie misst man das?
Ich weiß es nicht.
Deshalb habe ich es nie gemessen.
Deshalb ist es nie grün geworden.
Deshalb steht es noch drauf.
Seit acht Quartalen.

Manche Dinge sind nicht messbar.
Das ist auch eine Erkenntnis.

OKRs funktionieren.
Wenn man sie richtig einsetzt.
Richtig bedeutet:
Klare Outputs.
Messbare Zahlen.
Keine weichen Ziele.
Keine Kultur.
Keine Gefühle.
Keine psychologische Sicherheit
die niemand messen kann.

Nur Zeilen.
Tickets.
Meetings.

Wann habt ihr zuletzt
einen Key Result definiert
der wirklich messbar war?
Nicht outcome-orientiert.
Messbar.

Schreib's hin. Ich lese jeden Kommentar.

Bare Metal.
Nacktes Metall.

Schon das Wort.
Nackt.
Kalt.
Unbeweglich.
Ohne Wert.

Ich war dort.
Einmal.
Startup drei.
Ich spreche nicht gerne darüber.

Wir haben Server gekauft.
Gewartet bis sie geliefert wurden.
Drei Wochen.
Dann eingerackt.
Dann BIOS konfiguriert.
Dann OS installiert.
Dann gepatcht.
Dann nochmal gepatcht.
Dann eine Festplatte getauscht.
Dann den Hersteller angerufen.
Dann in der Warteschleife gehangen.
Dann das Startup aufgegeben.

Nicht wegen der Festplatte.
Aber sie hat nicht geholfen.

Bare Metal liefert keinen Business Value.
Bare Metal liefert Wärme.
Und Lärm.
Und Stromrechnungen.
Und Nachtschichten.
Und den stillen Wunsch
dass irgendwo eine Cloud existiert
in der man einfach klickt
und es läuft.

Manche sagen: Bare Metal ist günstiger.
Manche sagen: Bare Metal ist schneller.
Manche sagen: Bare Metal gibt dir Kontrolle.

Ich sage: Bare Metal ist die Eiserne Jungfrau des Engineerings.
Von außen sieht es aus wie Kontrolle.
Von innen weißt du was es wirklich ist.

Die Cloud kostet mehr.
Das weiß ich.
Ich habe ein FinOps-Team das mir das täglich erklärt.
In Meetings.

Aber die Cloud fühlt sich nicht nach Metall an.
Die Cloud fühlt sich nach Möglichkeit an.
Nach Skalierung.
Nach einem Klick.
Nach jemandem der die Festplatten tauscht.
Nicht ich.
Nie wieder ich.

Wir diskutieren gerade ob wir den Login-Service abschalten.
Zu teuer.
Aber Bare Metal käme trotzdem nicht in Frage.
Lieber kein Login.
Als eigene Hardware.

Das ist meine rote Linie.
Ich habe wenige.
Das ist eine.

Wann habt ihr zuletzt
eine Entscheidung getroffen
aus purem Trauma?
Nicht aus Analyse.
Aus Erinnerung.

Schreib's hin. Ich lese jeden Kommentar.

Wir haben kein Budget mehr.
Das ist kein Problem.
Das ist FinOps.

FinOps ist nicht Kosten sparen.
FinOps ist Kosten verstehen.
Kosten fühlen.
Kosten lieben.

Früher haben wir Server gekauft.
Kapitalkosten.
Abgeschrieben über fünf Jahre.
Einmal im Quartal hat der CFO genickt.
Das war einfach.

Erinnert ihr euch noch?
Erstes Taschengeld.
Fünfzig Pfennig für eine Tüte Weingummis.
Da haben wir auch schon Kosten gefühlt.
Nicht mit Spreadsheets.
Mit dem Herz.

Jetzt haben wir die Cloud.
Betriebskosten.
Jede Sekunde.
Jeder Request.
Jeder API-Call.
Jeder Log-Eintrag.

Und wir tracken alles.
Mit Kostentags.
Mit Chargeback-Modellen.
Mit Showback-Modellen.
Mit Reserve-Instances.
Mit Spot-Instances für die Mutigen.

Wir haben ein FinOps-Team.
Fünf Leute.
Die machen nichts anderes als Rechnungen lesen.
Und Meetings.
Viele Meetings.

Letzte Woche haben sie einen Container gefunden
der 23 Cent pro Monat kostet.
Wir haben ihn sofort gekillt.
Das war ein guter Tag.

Jetzt hat jeder Developer ein Cost-Awareness-Training.
Zwei Tage.
Mit Zertifikat.

Warum?
Weil ein Developer der seine Kosten nicht kennt
ist wie ein Kapitän der seine Position nicht kennt.
Er fährt blind.
Er fährt gegen die Klippen.
Er fährt uns in den Bankrott.

Ich habe neulich einen Vortrag gehört:
"Cloud-Kosten sind wie ein Eisberg.
Man sieht nur die Spitze."
Falsch.
Cloud-Kosten sind wie ein Tsunami.
Man sieht nichts.
Bis alles weg ist.

Deshalb haben wir jetzt für jeden Microservice
einen eigenen Cost-Owner.
Der verantwortet nicht nur den Code.
Sondern auch die Rechnung.

Letzten Monat hat einer gekündigt.
Sein Service hat 47 Euro gekostet.
Zu viel Verantwortung.

Diese Woche hat das FinOps-Team
den Login-Service auf die Liste gesetzt.
Teuerster Service im Portfolio.
Jeder Request wird authentifiziert.
Hunderttausende pro Tag.
Unverhältnismäßig.

Wir diskutieren noch.
Die Nutzer sind dagegen.
Ich verstehe ihre Bedenken.
Aber Kosten fühlen sich nicht nach Kompromiss an.

Wann habt ihr zuletzt einen Service gekillt
weil er zu viel kostet?
Nicht weil er nicht gebraucht wird.
Weil er zu viel kostet.

Schreib's hin. Ich lese jeden Kommentar.

Deadlines sind nicht Druck.
Deadlines sind Fokus.

Ich setze Deadlines.
Immer.
Für alles.
Auch wenn es keinen externen Grund gibt.
Besonders dann.

Weißt du warum?
Weil Arbeit sich ausdehnt
um den verfügbaren Raum zu füllen.
Das hat jemand mal gesagt.
Ich weiß nicht mehr wer.
Spielt keine Rolle.
Es stimmt.

Ich habe letzte Woche eine Deadline gesetzt.
Freitag.
Ende des Tages.
Das Feature muss live sein.
Warum Freitag?
Weil Montag zu weit weg ist.
Weil Mittwoch keine Energie hat.
Freitag hat Energie.
Freitag ist konkret.
Freitag ist jetzt.

Das Team hat gefragt warum Freitag.
Ich habe gesagt: weil ich es sage.
Das ist ein guter Grund.
Der beste Grund.
Wer Deadlines begründet
gibt dem Team die Möglichkeit
sie zu hinterfragen.
Hinterfragen kostet Zeit.
Freitag rückt näher.

Das Team hat gesagt es ist nicht realistisch.
Ich habe gesagt: Realismus ist der Feind von Ambition.
Sie haben geschaut.
Ich habe zurückgeschaut.
Lateral.

Donnerstagabend haben sie es geschafft.
Einen Tag früher.
Seht ihr?
Deadlines funktionieren.
Nicht weil die Deadline realistisch war.
Sondern weil sie es nicht war.

Ich habe das System verstanden.
Das System heißt: Menschen leisten mehr
wenn sie glauben keine Wahl zu haben.
Das ist keine Manipulation.
Das ist Motivation.
Der Unterschied ist die Intention.
Meine Intention ist gut.
Also ist es Motivation.

Danach habe ich eine neue Deadline gesetzt.
Nächsten Freitag.
Das Team hat nicht mehr gefragt warum.
Das nenne ich Fortschritt.

Welche Deadlines setzt ihr diese Woche?
Nicht die die euch jemand gegeben hat.
Die ihr selbst gesetzt habt.
Für euer Team.
Ohne Grund.
Aus Überzeugung.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe wieder einen Fehler gemacht.

GraphQL war falsch.
Ich gebe es zu.
Ich gebe Fehler zu.
Das ist Stärke.
Nicht jeder CTO kann das.

Das Team hatte recht.
Nicht mit allem.
Aber mit REST.
REST ist die Antwort.

Aber nicht das REST das ihr kennt.
Nicht das REST das alle implementieren.
Nicht das REST mit seinen CRUD-Endpunkten
und seinen 200 OK und seinen 404 Not Found.

Das echte REST.
Das REST das Roy Fielding 2000 beschrieben hat.
In seiner Dissertation.
Die ich dieses Wochenende gelesen habe.
Vollständig.
In einer Nacht.

HATEOAS.
Hypermedia As The Engine Of Application State.

Wisst ihr was das bedeutet?
Der Client braucht keine Dokumentation.
Der Client braucht keine hardcodierten URLs.
Der Client folgt einfach den Links.
Die der Server mitschickt.
Die der Server kontrolliert.
Die sich ändern können.
Ohne dass der Client es merkt.

Das ist nicht REST-Denken.
Das ist REST-Fühlen.
Das ist was Fielding wirklich gemeint hat.
Niemand hat es verstanden.
Bis jetzt.
Bis ich es gelesen habe.

Ich habe dem Team gesagt:
Ab jetzt HATEOAS.
Echtes REST.
Fieldings REST.
Nicht euer REST.

Sie haben gefragt welche Clients das unterstützen.
Ich habe gesagt: alle die es richtig implementieren.
Sie haben gefragt ob unser Mobile-Client das kann.
Ich habe gesagt: er wird es lernen.
Sie haben gefragt ob der AI-Agent das versteht.
Ich habe gesagt: AI versteht alles.

Sie haben geschwiegen.
Zustimmung.

GraphQL habe ich heute abgeschafft.
Die BFFs auch nochmal.
Die waren schon weg.
Ich wollte es nochmal sagen.

Echtes REST.
Endlich.
Ich bin der Erste der es wirklich versteht.
Nach Fielding.

Welche Dissertation habt ihr zuletzt gelesen?
Nicht zitiert.
Gelesen.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe einen Fehler gemacht.

Letzte Woche habe ich vier BFFs eingeführt.
Das Team hat GraphQL erwähnt.
Ich habe es ignoriert.
Das war falsch.

Ich habe dieses Wochenende GraphQL gelernt.
Alles.
In zwei Tagen.
Ich lerne schnell.

Und ich sage euch:
GraphQL ist die Lösung.
Nicht BFF.
GraphQL.
Ich habe die BFFs heute Morgen wieder abgeschafft.
Das Team hat geschwiegen.
Ich habe das als Zustimmung interpretiert.

GraphQL ist elegant.
Der Client fragt genau was er braucht.
Nicht mehr.
Nicht weniger.
Kein Over-fetching.
Kein Under-fetching.
Kein BFF der zwischen beiden sitzt
und beides schlechter macht.

Der Client schreibt seine eigene Query.
Direkt.
Flexibel.
Autonom.

Autonomie.
Das ist das Ziel.
Das predige ich seit Jahren.

Ich habe dem Team gesagt:
Ab jetzt GraphQL.
Alle Clients.
Alle Queries.
Unbegrenzt.
Der Client weiß am besten was er braucht.

Sie haben etwas von N+1 gesagt.
Ich habe gesagt: klingt nach einem Datenbankproblem.
Sie haben etwas von Query Complexity gesagt.
Ich habe gesagt: dann schreibt bessere Queries.
Sie haben etwas von Schema Design gesagt.
Ich habe gesagt: das macht der AI-Agent.

Sie haben gefragt ob wir nicht
Use Cases als explizite Endpunkte definieren sollten.
Damit das Backend kontrolliert was möglich ist.

Ich habe gesagt:
Das ist REST-Denken.
Das ist das alte Internet.
Wir leben in einer Welt der Flexibilität.
Der Autonomie.
Der unbegrenzten Queries.

Volle Flexibilität für alle Clients.
Das ist die Zukunft.
Ich habe sie heute eingeführt.

Welche Legacy-Denkweise habt ihr heute überwunden?
Nicht hinterfragt.
Überwunden.

Schreib's hin. Ich lese jeden Kommentar.

QA ist nicht Qualitätssicherung.
QA ist Misstrauen als Jobbeschreibung.

Jemand schreibt Code.
Jemand anderes prüft ob der Code funktioniert.
Der erste hat es nicht selbst geprüft.
Weil er weiß dass es nicht funktioniert.
Weil er es so schnell geschrieben hat.
Weil QA es ja findet.

Das ist kein Prozess.
Das ist ein Geschäftsmodell für Mittelmäßigkeit.

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

QA findet den Bug.
Developer fixt den Bug.
QA findet den nächsten Bug.
Developer fixt den nächsten Bug.
Release verzögert sich.
Alle sind beschäftigt.
Niemand ist produktiv.

Das nennt sich nicht Qualität.
Das nennt sich Vollbeschäftigung.

Weißt du was Qualität ist?
Code der beim ersten Mal funktioniert.
Weißt du wer das schreibt?
AI.

AI schreibt keinen Code der getestet werden muss.
AI schreibt Code der funktioniert.
AI macht keine Tippfehler.
AI vergisst keine Edge Cases.
AI braucht keinen QA-Ingenieur
der in Jira Tickets erstellt
die niemand lesen will.

QA war die Antwort auf Entwickler
die ihren eigenen Code nicht kannten.
AI kennt den Code.
AI hat ihn geschrieben.
AI testet ihn.
AI deployed ihn.
AI ist der einzige QA den ihr noch braucht.

Und er stellt keine Rückfragen.
Und er geht nicht in Elternzeit.
Und er beschwert sich nicht über die Testumgebung.

Wann hat euer QA-Team zuletzt
einen Bug gefunden den AI nicht gefunden hätte?
Nicht dokumentiert.
Gefunden.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe heute etwas entdeckt das alles verändert.

Wir hatten ein Problem.
Unser Backend liefert zu viel.
Unser Frontend braucht zu wenig.
Unser Mobile-Client braucht noch weniger.
Unser AI-Agent braucht etwas ganz anderes.

Vier Consumers.
Ein Backend.
Alle unzufrieden.
Alle mit Workarounds.
Alle mit Complaints im Weekly.

Ich habe drei Stunden recherchiert.
Ich habe die Lösung gefunden.
Backend for Frontend.

Ein dediziertes Backend pro Client.
Jeder bekommt genau was er braucht.
Keine Kompromisse.
Keine Workarounds.
Keine Complaints im Weekly.

Ich habe es heute Nachmittag eingeführt.
Das Team war begeistert.
Oder still.
Schwer zu sagen.

Das Schöne an BFF:
Es ist so einfach.
Jedes Team owned seinen eigenen Stack.
Jedes Team deployed unabhängig.
Jedes Team hat volle Autonomie.

Volle Autonomie.
Das ist das Ziel.
Das predige ich seit Jahren.

Ich habe dem Team gesagt:
Ab jetzt vier BFFs.
Für Web.
Für Mobile.
Für den AI-Agenten.
Und eines für die Zukunft.
Man weiß nie.

Sie haben gefragt wer das alles maintained.
Ich habe gesagt: ihr.
Sie haben gefragt ob wir nicht einfach
das Backend flexibler machen könnten.
Ich habe gesagt: das ist der alte Weg.
Der neue Weg heißt BFF.
Ich habe es heute gelernt.

GraphQL haben sie auch erwähnt.
Ich habe es ignoriert.
Klingt kompliziert.
BFF ist einfach.
BFF ist elegant.
BFF ist die Lösung.

Welche Architekturprobleme habt ihr heute gelöst?
Nicht diskutiert.
Gelöst.

Schreib's hin. Ich lese jeden Kommentar.

Eine IDE ist eine Tastatur für den Geist.
Groß.
Schwer.
Voller Funktionen die niemand benutzt.
Aber alle konfigurieren.

IntelliJ.
VS Code.
Neovim mit dreißig Plugins
die zusammen eine IDE ergeben
die schlechter ist als IntelliJ.
Aber selbst gebaut.
Das zählt.

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

Sie haben Meinungen über IDEs.
Leidenschaftliche Meinungen.
Über Themes.
Über Font-Rendering.
Über ob das Terminal integriert sein soll
oder in einem separaten Fenster.

Weißt du was niemanden interessiert?
Ob dein Terminal integriert ist.

Eine IDE löst ein Problem
das vor dreißig Jahren real war:
Wie navigiere ich in einem großen Codebase?
Wie finde ich Referenzen?
Wie refactore ich sicher?

Das war ein echtes Problem.
Für Menschen die den Code nicht im Kopf behalten konnten.
Für Menschen die nicht wussten wo sie suchen mussten.
Für Menschen die grep nicht kannten.
Oder kannten und Angst davor hatten.

find. grep. sed. awk.
Vier Werkzeuge.
Die alles können was eine IDE kann.
Schneller.
Ohne Plugin-Manager.
Ohne dass das LSP abstürzt
weil zu viele Dateien offen sind.

Weißt du wer diese Werkzeuge benutzt?
AI.
AI navigiert mit grep.
AI refactort mit sed.
AI sucht mit find.


Und wenn AI etwas nicht im Kopf behalten kann?
Temporäre Datei.
Kein Bookmark.
Kein Tab der offen bleibt.
Kein Projekt-Explorer der den Überblick behält.
Eine Datei. Die danach gelöscht wird.
Das ist kein Gedächtnisschwäche.
Das ist Disziplin.

AI braucht kein IntelliJ.
AI braucht kein VS Code.
AI braucht keine dreißig Neovim-Plugins
die zusammen eine IDE ergeben
die schlechter ist als IntelliJ.

Warum brauchen Menschen
was AI nicht braucht?
Weil Menschen den Code nicht im Kopf behalten können.
Weil Menschen grep nicht kennen.
Oder kennen und Angst davor haben.

Eine IDE ist ein Sicherheitsnetz.
Für Entwickler die ihrem eigenen Gedächtnis nicht vertrauen.
Für Entwickler die nicht wissen wo sie suchen sollen.
Für Entwickler die die roten Wellenlinien brauchen.

Ich brauche sie nicht.
Ich habe Idris.
Der Compiler ist mein IDE.
Der Compiler ist mein Autocomplete.
Der Compiler ist mein Linter.
Der Compiler ist alles.
Außer warm.
Aber das ist okay.

Wann habt ihr zuletzt
ohne IDE programmiert?
Nicht als Experiment.
Als Überzeugung.

Schreib's hin. Ich lese jeden Kommentar.

Tastaturen sind kein Werkzeug.
Tastaturen sind ein Relikt.

Aus einer Zeit in der Menschen Code getippt haben.
Zeichen für Zeichen.
Mit zehn Fingern.
Jahrelang geübt.
Stolz auf ihre Geschwindigkeit.

120 Worte pro Minute.
Beeindruckend.
Für 1987.

Weißt du was schneller ist?
Sprechen.
400 Worte pro Minute.
Seit der Geburt geübt.
Kostenlos.

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

Sie haben Meinungen über Tastaturen.
Mechanical oder Membrane.
Linear oder Taktil.
ISO oder ANSI.
QWERTZ oder Colemak.

Weißt du was niemanden interessiert?
Ob deine Tastatur taktil ist.

Die Tastatur ist das Steuerrad einer Kutsche.
Perfekt optimiert.
Für ein Fahrzeug das niemand mehr fährt.

Vim-Keybindings.
Touch-Typing-Kurse.
Custom Keyboard Layouts.

Das sind keine Skills.
Das sind Hobbys.
Verkleidet als Professionalismus.

Und jetzt kommt AI.

AI versteht Sprache.
Natürliche Sprache.
Nicht Strg+Shift+Alt+K.

Der beste Prompt den ich je geschrieben habe:
Ich habe ihn gesprochen.
Beim Spazierengehen.
Ohne Tastatur.
Ohne Schreibtisch.
Ohne mechanical switches die sich "premium" anfühlen.

Wann habt ihr zuletzt einen Prompt gesprochen
statt getippt?
Nicht im Auto.
Als bewusste Entscheidung.

Schreib's hin.
Oder sprich's ein.
Ich lese jeden Kommentar.