Technisch bleiben: Warum ein Engineering-Leiter coden muss

Im letzten Artikel habe ich über 30 Jahre IT geschrieben. Über den Wandel, die Disruptionen, die Hypes. Aber eine Frage habe ich ausgeklammert: Wie bleibt man eigentlich technisch am Ball, wenn man eine Führungsrolle hat?

Ich bin "Leiter Engineering & IT" bei GBI Genios. Das klingt nach Meetings, Budgets und Strategiepapieren. Ist es auch. Aber wenn ich nur noch Meetings mache und Strategiepapiere schreibe, habe ich ein Problem. Denn ohne technisches Verständnis kann ich die Hälfte meiner Entscheidungen nicht treffen. Ich weiß dann nicht, ob ein Problem fünf Minuten oder fünf Tage braucht. Ob es ein Bug ist oder ein Architekturproblem. Ob wir den Monolithen anfassen müssen oder nur eine Konfiguration ändern.

Wie es passiert

Es passiert nicht über Nacht. Niemand wacht morgens auf und kann plötzlich kein Java mehr. Es ist eher so: Du gehst in ein Meeting. Dann noch eins. Dann kommt ein Personalgespräch, eine Budget-Runde, ein Jour fixe. Am Ende des Tages hast du keinen einzigen Commit gemacht, keine einzige Zeile Code gelesen. Das ist ein Tag. Kein Drama. Aber wenn das die Regel wird, verlierst du den Anschluss. Und irgendwann bist du der Manager, der in Architektur-Meetings nickt und hofft, dass die Entwickler wissen, was sie tun.

Ich habe in 30 Jahren zu viele von der Sorte gesehen. Manager, die irgendwann nur noch Folien geschoben haben und sich gewundert haben, warum das Team sie nicht ernst nimmt. Das will ich nicht werden.

Warum es zählt

Es geht nicht darum, den Entwicklern zu beweisen, dass ich auch noch coden kann. Es geht darum, dass ich durch meine Jahre in der Systemadministration und der Entwicklung beide Seiten sehe. Wenn ein Problem auftaucht, kann ich erkennen, ob es besser per Code oder per Settings gelöst wird. Diese Mischung — neudeutsch DevOps — ist kein Buzzword für mich. Es ist mein Alltag. Ohne die Nähe zur Technik wäre das schlicht nicht möglich.

Oder Rapid Prototyping. Entwickler sind häufig etwas... hilflos, wenn es um Administration geht. So einfache Dinge wie ein JAR deployen oder einen Service neu starten sind da manchmal schon eine Hürde. Ich kann dann in einer Stunde einen Prototyp aufsetzen, deployen und zeigen: "So könnte das aussehen." Das spart Diskussionen und Meetings. Und es gibt dem Team einen konkreten Startpunkt, statt nur eine Idee auf einem Whiteboard.

Was ich konkret mache

Open Source

Morphium, mein MongoDB-Treiber und ORM für Java, ist vermutlich das Wichtigste. Den setzen wir bei Genios produktiv ein — bei einer Milliarde Dokumenten. Das heißt: echtes Projekt, echte Anforderungen, echte Bugs, echte Performance-Probleme. Kein Spielzeug.

Dazu kommt jblog3, die Blog-Software auf der dieser Artikel hier läuft. Die habe ich gerade von Spring Boot auf Quarkus umgestellt — und Quarkus unterstützt Morphium direkt, dank Open Source und der Hilfe anderer Entwickler. Auch das ist eine laufende Anwendung mit echten Problemen und echten Deployment-Zyklen. Solche Projekte halten einen am Leben.

Architektur

Ich lese nicht nur Code, ich bin aktiv in die Architektur involviert. Die gesamte IT- und Softwarearchitektur von Genios habe ich vorgeschlagen und mit dem Team zusammen verfeinert. Ich bin regelmäßig mit den Architekten im Austausch — nicht als Abnicker, sondern als jemand, der mitdiskutiert und auch mal sagt: "Das wird so nicht funktionieren, weil..."

Gerade beim Thema Architektur ist es schwierig, "richtig" von "falsch" zu unterscheiden. Die Erfahrung zeigt: Es gibt kein "falsch". Nur vielleicht unpraktisch, oder ineffizient. Und manchmal ändert sich das auch im Laufe der Zeit — was heute unpraktisch ist, kann morgen die richtige Entscheidung gewesen sein. Aber wir müssen die Architektur gemeinsam tragen, sie gemeinsam weiterentwickeln und dahinter stehen. Wenn ich das im Alleingang vorschlage, alle aber glauben, das ist Blödsinn, wird das kein Erfolg. So bekomme ich auch immer wieder Feedback. Und das Wichtige: Offen bleiben. Gerne auch mal einen Fehler zugeben. Man verrennt sich, das kommt vor. Aber dann die Größe haben zu erkennen, dass man falsch liegt — das ist nicht leicht. Ich bin da auch nicht immer gut drin. Aber ich versuche es.

Bei Morphium habe ich mittlerweile ein Team, das Architekturentscheidungen mitträgt. Das ist ein gutes Gefühl — wenn du merkst, dass dein Open-Source-Projekt groß genug geworden ist, dass andere mitdenken und mitgestalten.

Code Reviews gehören da mit rein. Nicht jede Pull Request, aber genug, um zu verstehen, was passiert. Wo geht die Architektur hin? Wo entstehen technische Schulden? Ab und zu sehe ich Dinge, die andere nicht sehen, weil sie zu nah dran sind. Ein frischer Blick hat seinen Wert, auch wenn man nicht jeden Tag im selben Modul steckt.

Und wenn was Neues aufkommt, will ich es ausprobieren. Eigene Erfahrung, keine Meinung aus zweiter Hand. Manchmal reicht ein Abend mit einer neuen Library. Manchmal ist es ein Wochenendprojekt. Und manchmal kommt dabei raus: Das ist nichts für mich.

Docker zum Beispiel. Ich habe es ausprobiert, mehrfach. Und jedes Mal war das Gefühl dasselbe: Das hätte ich direkt in der Shell oder auf einem eigenen LXC-Container auch hinbekommen. Und besser. Ich will mir nicht hunderte Black-Boxes in VMs installieren, ohne zu wissen, was da drin passiert. Ich hab da ein wenig FOMO, das gebe ich zu. Alle reden von Docker, alle nutzen Docker. Aber bisher haben alle Dinge, die bei uns mit Docker implementiert wurden, mehr Arbeit gemacht als Nutzen gebracht. Ich rede dabei nicht von Orchestrierungen wie Docker Swarm oder Kubernetes — da haben wir eigene Lösungen. Ich rede vom reinen Container-Ansatz, vom "pack deine Anwendung in ein Docker-Image und alles wird gut". Wird es nicht. Zumindest nicht bei mir. Ich warte immer noch auf die Killer-Anwendung, bei der mir klar wird, warum ich Docker brauche.

Und das ist OK. Man muss nicht jeden Trend mitmachen. Man muss ihn aber ausprobiert haben, bevor man ihn ablehnt. Sonst ist man nicht kritisch, sondern nur ignorant.

Das Homelab

Das klingt vielleicht seltsam für einen "Leiter Engineering": Ich habe mir zu Hause einen Proxmox-Cluster eingerichtet. Nicht als Spielerei, sondern damit ich bei der Administration mitreden kann und verstehe, wie das funktioniert. Wenn mein Team über Virtualisierung, Netzwerk-Konfiguration oder Cluster-Setups spricht, will ich wissen, wovon die reden. Nicht aus einem Buch. Aus eigener Erfahrung.

Auf dem Cluster läuft mittlerweile eine komplette Testinfrastruktur. Automatisierte Tests für Morphium, aber auch für den gesamten Genios-Stack. Das ist mein Sandkasten, auf dem ich Dinge ausprobieren kann, die ich im Produktivsystem nicht anfassen würde.

Die Zeitfrage

Ich lüge nicht: Ein Teil passiert abends und am Wochenende. Open-Source-Projekte pflegen sich nicht von 9 bis 17 Uhr, schon gar nicht wenn der Tag mit Meetings vollgepackt ist.

Aber Code Reviews sind Arbeitszeit. Architekturentscheidungen sind Arbeitszeit. Ein Prototyp, der dem Team eine Woche Diskussion erspart, ist Arbeitszeit. Ich versuche, technische Arbeit nicht als Ablenkung von der "eigentlichen" Führungsarbeit zu sehen, sondern als Teil davon. Das gelingt nicht immer. Aber meistens.

Das mit dem Loslassen

Meine größte Schwäche. Wenn ich sehe, dass ein Problem lösbar ist und ich weiß wie, juckt es mich in den Fingern. Fix schreiben, committen, weiter. Man denkt, man wäre schneller. Und durch die Erfahrung ist man das in manchen Bereichen auch. Aber "schneller" heißt oft: etwas übersehen. Einen Edge Case nicht bedacht. Einen Test nicht geschrieben. Weil man ja so schnell war.

Im Kern ist das ein Vertrauensthema. Ich vertraue meinem Team. Die können das. Und doch will ich mir die Hände schmutzig machen. Das ist eigentlich der Punkt: Es geht nicht darum, dass ich dem Team nicht traue. Es geht darum, dass mir die Arbeit fehlt. Das Machen. Das Bauen. Das Problem-Lösen mit eigenen Händen.

Wenn ich den Fix mache, lernt das Team nichts. Und ich werde zum Flaschenhals. Das skaliert nicht. Also halte ich mich zurück. Meistens. Ich erkläre, wo das Problem liegt, gebe Hinweise, mache einen Review. Aber den Fix macht das Team.

Genau dafür gibt es das Homelab, die Open-Source-Projekte, die Prototypen: Damit ich mir die Hände schmutzig machen kann, ohne dem Team im Weg zu stehen.

Es ist kein Selbstläufer

Technisch bleiben als Führungskraft passiert nicht von alleine. Es kostet Zeit, Energie und manchmal auch Schlaf. Aber die Alternative — ein CTO, der nicht mehr versteht, was seine Leute tun, der in Meetings sitzt und hofft, dass schon alles gut gehen wird — die ist schlimmer.

Also code ich. Nicht jeden Tag. Nicht so viel wie früher. Aber genug, um zu wissen, wovon ich rede. Genug, um einen Prototyp hinzustellen, wenn das Team diskutiert. Genug, um in einem Code Review zu erkennen, ob eine Lösung elegant oder ein Zeitbomben-Hack ist.

Denn am Ende ist es wie mit allem in dieser Branche: Wer stehen bleibt, fällt zurück.