Über mich

Ich bin Senior Tech Lead und Generalist, der in mehrere Richtungen gleichzeitig in die Tiefe geht. Software Engineering, Platform Engineering, Systemarchitektur, Daten, AI und ML, Cloud-native Infrastruktur, verteilte Systeme. Ich spezialisiere mich nicht auf eines davon. Die eigentliche Arbeit liegt darin, sie zu verbinden.

Woran ich arbeite

In den letzten Jahren habe ich einen Observability-Service gebaut und betrieben, einen DNS-Service, eine Serving-Plattform für LLMs, einen Model-Tracking-Service und eine Datenplattform. An der Oberfläche verschiedene Probleme. Darunter ist es dieselbe Aufgabe: Jemand fordert etwas an, das Etwas muss erscheinen, und es muss um drei Uhr nachts noch laufen, wenn niemand hinsieht.

Die Backend-Services verarbeiten Tausende Requests pro Sekunde. Die MLOps-Plattformen sind von Grund auf entstanden. Die Cloud-native Infrastruktur trägt eine große Engineering-Organisation, weshalb die Standards für Zuverlässigkeit und Entwicklung drumherum genauso zählen wie der Code darin. Mir liegt an schnellem Code und daran, dass die Architektur einem Team erlaubt, sich zu bewegen, ohne etwas kaputtzumachen. Diese beiden Ziele stehen selten lange im Widerspruch.

Das interessanteste Stück ist auch das, wonach ich am häufigsten gefragt werde: Wir haben die Kubernetes-API zur Steuerungsebene einer ganzen Cloud-Plattform gemacht. Nicht nur für Container. S3-Buckets, Datenbanken, DNS-Einträge, IAM-Credentials, sogar ganze untergeordnete Cluster wurden Kubernetes-Ressourcen, als Manifest definiert, per GitOps verwaltet, von Controllern laufend abgeglichen.

Large Language Models im großen Maßstab bereitzustellen war eine eigene Lehre: Modelle beschaffen und cachen, einen OpenAI-kompatiblen Server davorsetzen, Authentifizierung, Nutzungserfassung für die Abrechnung, Autoscaling, und mehrere Modelle unter einer Domain betreiben, ohne dass sie sich um GPUs streiten. Daraus wurde ein Vortrag und schließlich genai-gateway, die Schicht für Rate Limiting und Metriken, herausgelöst zu etwas, das jeder betreiben kann.

Neben den Systemen selbst steckt viel Zeit in Engineering-Kultur. Design-Dokumente. Organisationsweite Standards für Code und APIs. Mentoring. Die gemeinsamen Bibliotheken und Vorlagen, die den richtigen Weg zum einfachen machen, denn nur so halten Standards überhaupt. Gute Engineering-Organisationen entstehen nicht zufällig. Sie brauchen dieselbe bewusste Gestaltung wie gute Software.

Ich arbeite hauptsächlich in Go, Python und Rust, mit Kubernetes, Terraform und dem üblichen Cloud-native-Werkzeug. Ich unterrichte verteilte Systeme an der Universität und halte Vorträge auf Konferenzen. Um an den Grundlagen zu bleiben, baue ich Dinge wie eine verteilte Key-Value-Datenbank in Rust, was gut daran erinnert, wie viel die Frameworks sonst verbergen.

Wie ich über Architektur denke

Das Wort Architektur ist so weit gedehnt worden, dass es fast nichts mehr bedeutet. Alle sind heute Architekt: Datenarchitekten, Solution Architects, Customer Success Architects. Darüber habe ich einen ganzen Vortrag gehalten, hauptsächlich aus Verärgerung, mit dem Argument, wir sollten wieder über Code reden.

Meine eigentliche Position ist enger, als das klingt. Architektur ist die Menge der Entscheidungen, die teuer rückgängig zu machen sind. Alles andere ist Code, und Code lässt sich billig ändern, wenn man ihn so strukturiert hat. Die nützliche Frage ist deshalb nie „ist das der beste Entwurf“, sondern „was kostet mich dieser Entwurf, wenn ich falsch liege“. Ich liege ziemlich oft falsch, also optimiere ich darauf, es schnell zu merken.

In der Praxis heißt das: langweilige Technologie an den tragenden Stellen, interessante an den Rändern. Ein Service, dem seine Daten gehören. Und den Fehlerfall aufschreiben, bevor man den Gutfall schreibt, weil der Gutfall sich um sich selbst kümmert.

Ich schreibe Go, Rust, Python und TypeScript, ungefähr in dieser Reihenfolge nach Menge. Rust kommt häufiger vor, als sein Ruf vermuten lässt: nicht nur für Systemnahes, sondern für Webservices, wo das Typsystem eine ganze Klasse von Fehlern abfängt, bevor sie im Review landet. Diese Position habe ich 2024 auf der WeAreDevelopers vertreten und ich stehe weiter dazu.

Über Teams

Der technische Teil ist die einfachere Hälfte.

Auf der ITCS Darmstadt habe ich 2026 eine Keynote gehalten, „Was ein gutes Tech Team ausmacht“, und das Argument hält: Teams scheitern selten daran, dass die Leute nicht gut genug wären. Sie scheitern daran, wie sie arbeiten. Code wird im Review diskutiert statt getestet. Über Formatierung wird gestritten, statt sie dem Linter zu überlassen. Ego wird optimiert statt Ergebnisse. Und niemand hält je inne und fragt, ob das alles funktioniert.

Die Forschung stützt das deutlicher, als ich erwartet hatte, als ich anfing sie zu lesen. Googles Project Aristotle fand psychologische Sicherheit wichtiger als reines Talent. Die DORA-Metriken aus Accelerate zeigen, dass Lieferfähigkeit an Praktiken hängt, nicht an Teamgröße. Team Topologies argumentiert, dass Teamstruktur und Systemstruktur einander spiegeln, ob man das plant oder nicht.

Was ich als Lead daraus mitnehme, ist vor allem Zurückhaltung. Meine Aufgabe ist, das wegzuräumen, was gute Leute an guter Arbeit hindert, und dann aus dem Weg zu gehen. Standards setzen, damit Entscheidungen nicht dauernd neu verhandelt werden. Die Pipeline durchsetzen lassen, was sonst eine Diskussion wäre. Aufgaben geben, die groß genug sind, um daran zu wachsen, und klar sagen, was „fertig“ heißt.

Viel Zeit geht in Reviews. Nicht ins Kleinkarierte: Das klassische Zeichen für ein Team in Schwierigkeiten sind zehn Kommentare an einem Zehn-Zeilen-Pull-Request und keiner an dem mit tausend Zeilen. Das Risiko steckt in der großen Änderung, und die verdient die Aufmerksamkeit.

Außerhalb des Terminals

Ich trainiere Calisthenics. Angefangen hat es aus praktischen Gründen, weil man dafür fast nichts braucht, und daraus wurde das, was den Rest ordentlich hält. Fortschritt ist langsam und eindeutig: Entweder die Wiederholung war da oder nicht. Man kann sich keinen Muscle-up herbeireden. Nach einem Tag voller Entscheidungen, deren Rückmeldung in Monaten kommt, ist etwas mit einer ehrlichen Antwort in zehn Sekunden eine Erleichterung.

Und ich höre nicht wirklich auf zu bauen. Es läuft immer ein Nebenprojekt: ein Tower-Defense-Spiel in Neovim, damit Vim-Motions sitzen, eine Sprachbrücke, um ohne Abo diktieren zu können, ein MCP-Server, damit Agents nicht raten, was in der Dokumentation steht. Die meisten existieren, weil ich das Ding haben wollte und es noch nicht gab. Manche waren auch für andere nützlich, was ein angenehmer Nebeneffekt ist und nicht der Plan war.

Das größere Projekt gerade ist ein Fitness-Tracker, also das, was passiert, wenn Trainingsgewohnheit und Baugewohnheit zusammenstoßen.

Über all das schreibe ich regelmäßig, vor allem über KI und was sie tatsächlich mit unserer Arbeit macht, über Architektur und über die Teile von Engineering Management, die in keiner Stellenausschreibung stehen.

Zwei Wege von hier

Wenn Sie über etwas sprechen wollen, das ich gebaut habe, etwas Geschriebenem widersprechen oder einfach Hallo sagen möchten: Die Kontaktseite ist der kürzeste Weg. Ich lese alles, was dort ankommt.

Wenn Sie vorher lieber sehen möchten, wie ich denke, sind die Artikel der bessere Einstieg.