Mir ist aufgefallen, dass die Dinge, die am schwersten zu lernen sind, fast nie technisch sind.
Es sind die Dinge, die man verlernen muss.
Und das Seltsame ist, dass es einem beim Verlernen vorkommt, etwas zu verlieren. Status, Kontrolle, Identität. Wenn es gut läuft, merkt man danach, dass man nur eine Gewohnheit losgelassen hat, die einen festhielt.
Das hier sind verstreute Notizen zu Dingen, die ich aufgegeben habe. Ich habe ungefähr fünfzehn Jahre dafür gebraucht. Bei manchen, ehrlich gesagt, bin ich noch nicht fertig.
Ich schreibe nicht mehr Code, um zu beweisen, dass ich noch tech bin
Es gab eine Zeit, kurz nach einem wichtigen Karriereschritt, in der mein Weg, mich vor dem Team zu legitimieren, immer derselbe war: IDE öffnen und mir den hässlichsten Bug der Woche schnappen.
Oft abends, allein. Am Morgen war der Commit da, mit meinem Namen drauf. In mir nannte ich das Leadership. Es war Unsicherheit.
Denn die implizite Botschaft war verheerend, auch wenn ich sie nie laut aussprach. Sie lautete: ich vertraue euch nicht. Und es gab eine zweite, noch toxischere: Probleme löst man nachts, allein, ohne um Hilfe zu bitten.
Ohne es zu wollen, lehrte ich, dass die heroische Geste mehr wiegt als der Prozess. Dass Können eine individuelle Performance ist. Dass Erschöpfung eine Medaille ist.
Dann machte ich eine weitere Runde. Ich ersetzte Code durch Spezifikationen. Dokumente, so präzise, dass das Team — oder ein KI-Agent — sie mit minimaler Aufsicht umsetzen konnte. Eine Weile schien das die „erwachsene“ Lösung. Auch diese Phase ging vorbei.
Heute ist meine Arbeit, wenn ich sie gut mache, eine andere. Es ist zu entscheiden, was wir bauen, für wen und warum jetzt. Es ist Portfolio-Architektur, nicht Code-Architektur. Partnerschaften, Hiring, Positionierung. Zu verstehen, wohin das Unternehmen in achtzehn Monaten zielen soll und welche heutigen Entscheidungen diese Richtung wahrscheinlicher machen.
Diese Distanz zum Code tut manchmal weh. Nicht, weil ich täglich wieder programmieren möchte. Es ist subtiler. Es ist das Gefühl, dass die Legitimität einer Tech-Leitung, die nicht mehr täglich Code anrührt, etwas Fragiles ist, das auf anderen Grundlagen neu gebaut werden muss.
Nicht mehr auf der Qualität dessen, was du schreibst, sondern auf der Qualität deiner Entscheidungen und der Menschen, die du auswählst.
Und es gibt einen Satz, der mir oft einfällt und mich davor bewahrt, in den alten Reflex zurückzufallen: jede Zeile, die ich schreibe, ist eine Zeile, die jemand anderes nicht schreibt. Jede Stunde in der IDE ist eine Stunde, in der niemand schaut, wohin wir gehen.
Ich laufe nicht mehr dem ‚richtigen’ Stack hinterher
Jahrelang hatte ich diesen pawlowschen Entwickler-Reflex. Neues Framework? Bewerten. Neue Sprache? Wenigstens probieren.
Im Untertext stand wohl: es gibt eine „richtige“ Technologiewahl, die dich auf die Seite der Gewinner stellt. Der Cool Kids. Der richtigen Konferenzen. Der Hacker-News-Artikel.
Dann tat ich etwas Unpopuläres, jedenfalls für mein damaliges Denken: ich wählte ein Framework. Eines. Und blieb dabei.
Nicht weil es absolut das beste wäre. Sondern weil ich damit mit wenigen Leuten Wert über mehrere Projekte hinweg liefern kann, ohne durchzudrehen. Weil es eine Philosophie hat, die zu den realen Zwängen einer italienischen Firma passt. Konvention vor Konfiguration, Batterien inklusive, manische Doku. Nicht die imaginären Zwänge eines Bay-Area-Startups, das von Slides und Runway lebt.
Die unbequeme Wahrheit: viele „mutige“ Technologiewahlen in KMU sind kein Mut. Sie sind Eitelkeit. Rust für ein Verwaltungstool, das vierzig Leute nutzen, ist keine Ingenieurskunst. Es ist Narzissmus mit Compiler.
Irgendwann hörte ich auf, den richtigen Stack zu suchen, und begann den ehrlichen Stack zu suchen. Den, der über die eingeführte Komplexität nicht lügt. Den du wartest, wenn die Seniors gehen, das Budget enger wird, der Kunde dreimal seine Meinung ändert.
Ich schirme das Team nicht mehr vor dem Business ab
Der schwerste Schritt.
Jahrelang spielte ich Schild. Verrückte Kundenanforderung? Filtere ich. Vertrieb verkauft etwas, das es nicht gibt? Regle ich. Unverständliches Dokument? Übersetze ich und gebe nur den sauberen, verdaulichen Tech-Teil ans Team.
Ich hielt mich für einen guten Leader. Vermutlich züchtete ich Behinderte.
Sehr gute Entwickler, ja, aber abgekoppelt. Sie wussten nicht wirklich, warum sie bauten, was sie bauten. Sie konnten kein Business-Requirement lesen. Sie hatten nie mit einem Kunden gesprochen. Bei Mehrdeutigkeiten griffen sie nicht zum Telefon, sondern öffneten ein Ticket und warteten.
Die Wende für uns war ein interner Pfad, den wir „from developer to product owner“ nannten. Nicht, um alle in PMs zu verwandeln. Eher, um das Filter zu entfernen.
Um eine einfache, etwas unbequeme Sache zu sagen: das Chaos gehört auch euch. Der verwirrte Kunde gehört auch euch. Das mehrdeutige Requirement gehört auch euch.
Und vor allem: die Genugtuung, etwas auszuliefern, das wirklich für jemanden funktioniert, gehört auch euch.
Ich hatte mit Widerstand gerechnet. Ich täuschte mich. Sie haben mich überrascht. Vielleicht warteten sie nur auf die Erlaubnis, aus der Blase zu treten.
Ich sage nicht mehr ‚ist sowieso öffentlich’ zur Compliance
Jahrelang war meine Compliance-Haltung typisch für die italienische IT-Branche: das Allernötigste, im letzten Moment, als Kostenposten behandelt, nie als Investition.
DSGVO? Cookie-Banner und kopierte Datenschutzerklärung. Barrierefreiheit? „Sehen wir später.“ Sicherheit? „Wir sind kein Ziel.“
Dann begann ich, EU-Normen wirklich zu lesen. Nicht Artikel über sie, die Texte selbst. Und zwei Dinge wurden klar.
Erstens: der EU-Gesetzgeber meint es ausnahmsweise ernst. Sanktionen sind real, Fristen knapp, die Verantwortungskette reicht bis zum Komponentenlieferanten. Also zu uns.
Zweitens, wichtiger: in einem Markt, in dem alle bis zur letzten Minute warten, hat einen riesigen Vorteil, wer sich früh bewegt. Nicht weil er besser ist. Weil er als Einziger dem Kunden „ja, wir sind bereit“ sagen kann, wenn der Kunde panisch danach fragt.
Irgendwann hörte ich auf, Compliance als Pflicht zu behandeln. Ich begann sie als Produkt zu behandeln.
Und ich frage mich oft, warum wir so lange gebraucht haben, das zu begreifen. Vielleicht weil es bequemer ist zu glauben, das sei nur Papierkram, bis es plötzlich ein Problem mit Frist wird.
Ich stelle nicht mehr nach technischen Skills ein
Frisch und, ehrlich, noch ein bisschen schmerzhaft.
Ich verbrachte Wochen mit der Suche nach einer wichtigen Position. Hervorragende CVs. Jahre Erfahrung. Solide Stacks. Gute Referenzen. Ich lehnte einige ab, nicht weil sie schlecht waren, sondern weil sie KI nutzten wie Stack Overflow vor zehn Jahren. Wie ein Orakel.
Was ich suchte — und Recruitern schwer erklären kann — ist anderes. Ich suchte jemanden, der eine deklarative Spezifikation so präzise schreiben kann, dass ein KI-Agent sie mit minimaler Aufsicht umsetzt.
Kein Prompt-Engineer. Ein Systemdenker, der KI als Runtime nutzt, nicht als Krücke.
Der Unterschied wirkt fein, ist es aber nicht. Es ist der Unterschied zwischen „ich habe ChatGPT gebeten, mir den Code zu schreiben“ und jemandem, der ein claude.md im Repo führt — mit Architekturkonventionen, Patterns, Domänenrestriktionen. Zwischen Konversation und Spezifikation. Zwischen Handwerk und Ingenieurskunst.
Ich höre auf, Entwickler einzustellen, die programmieren können. Ich beginne, Entwickler zu suchen, die spezifizieren können und das, was die KI produziert hat, mit der gleichen Strenge prüfen, wie sie den Code eines Juniors prüfen würden.
Der italienische Markt scheint für diese Unterscheidung leider noch nicht bereit. Aber ich habe das Gefühl, er wird es bald sein. Und wer es nicht rechtzeitig schafft, riskiert Teams, die viel „produzieren“ und wenig verstehen.
Ich spreche nicht mehr Italienisch bei der Arbeit
Klingt klein. Ist es nicht.
Als ein neuer, sehr guter, nicht-italienischer Junior kam, standen wir vor einer Wahl. Untereinander weiter Italienisch sprechen und nur mit ihm Englisch — faktisch ein Zwei-Geschwindigkeiten-Team. Oder den vollständigen Switch.
Wir wählten den vollständigen Switch. Alles auf Englisch. Jira auf Englisch. Chat auf Englisch. Daily auf Englisch. Retro auf Englisch. Für alle.
Nicht nur seinetwegen. Auch unseretwegen.
Denn ein Unternehmen weniger Personen in einer italienischen Stadt, das ausschließlich auf Italienisch arbeitet, bleibt vermutlich ein Unternehmen weniger Personen in dieser Stadt. Daran ist nichts falsch. Nur war das nicht, was wir wollten.
Englisch ist am Ende keine Sprache. Es ist Infrastruktur. Wie Git, wie CI/CD, wie Doku. Du hast es oder du bist abgeschnitten.
Es war unbequem. Manche taten sich schwer. Aber wenn ich heute Pull-Request-Beschreibungen, Nachrichten, Mails lese, denke ich, es hat sich gelohnt.
Ich glaube nicht mehr, dass guter Code für sich spricht
Vielleicht die gefährlichste Lüge der Softwareentwicklung. Die romantische Idee, dass guter, sauberer, getesteter, gut strukturierter Code seinen Wert von selbst zeigt. Dass technische Verdienste sich selbst verteidigen.
So funktioniert das nicht.
Guter Code, den niemand versteht, ist von mittelmäßigem Code nicht zu unterscheiden. Ein Refactoring, das niemand erzählt, wird zur Kostenposition, nicht zur Investition. Eine Architekturmigration ohne schriftliche Begründung wirkt wie eine Tech-Laune.
Ich habe spät gelernt: die Hälfte der Arbeit einer Tech-Führung ist erzählen.
Dem Vorstand erklären, warum eine Migration keine Marotte, sondern Risikoreduktion ist. Dem Kunden erklären, warum die bezahlten automatisierten Tests der Grund sind, dass er ruhig schläft. Dem Team erklären, warum CI/CD keine Bürokratie ist, sondern Freiheit und Bequemlichkeit.
Wenn du den Wert dessen, was du baust, nicht erzählen kannst, wird ihn jemand anderes für dich erzählen. Und schlecht.
Was ich noch nicht aufgegeben habe
Wenn ich ganz ehrlich sein soll, gibt es etwas, das ich aufgeben sollte und noch nicht schaffe.
Zu arbeiten, als wäre ich der einzige, der die Teile zusammenhält.
Zu vieles geht noch über mich. Nicht weil das Team unfähig wäre, im Gegenteil, sondern weil ich die Systeme, die mich in jedem Bereich überflüssig machen würden, noch nicht gebaut habe.
Und das macht mir am meisten Angst.
Denn jeder vorherige Schritt hatte einen klaren Ersatz. Nicht mehr coden? Spezifikationen. Nicht mehr Spezifikationen schreiben? Strategie. Nicht mehr Code-Reviews machen? Ein Tech Lead. Aber aufzuhören, der Konvergenzpunkt von allem zu sein, ist anders.
Der Ersatz ist Vertrauen in Systeme. Und die Systeme, ehrlich gesagt, muss ich noch fertig bauen.
Wir sprechen weiter darüber.
Was du mitnimmst
Hör auf, Code zu schreiben, um zu beweisen, dass du noch tech bist: das ist Identitätsarbeit, kein Engineering.
Hör auf, dem ‚richtigen’ Stack hinterherzulaufen; hör auf, einen zu verteidigen, weil du ihn ausgewählt hast.
Hör auf, das Team vor dem Business abzuschirmen: du nimmst ihm den Kontext, den es zum Wachsen braucht.
Hör auf, E-Mails in Echtzeit zu beantworten — du erziehst die Erwartung, dass du es immer tust.
Was du durchs Verlernen gewinnst, ist kein Rückzug — es ist Zeit und Aufmerksamkeit für langsame Entscheidungen, was fast immer einen müden Senior von einer Führungskraft unterscheidet, die Bestand hat.
Fragen & Antworten
Warum ist Verlernen schwerer als Lernen?
Weil man beim Verlernen das Gefühl hat, etwas zu verlieren — Status, Kontrolle, Identität. Die technischen Gewohnheiten, die zu Beginn der Karriere voranbrachten, werden später zur Bremse. Code zu schreiben, um zu beweisen, dass man noch tech ist, war mit 25 Bestätigung; mit 40 ist es Unsicherheit. Den Übergang zu erkennen ist der schwere Teil, der operative Wechsel ist fast mechanisch.
Welche Gewohnheiten verlernen die meisten in der Karrieremitte?
Beweisen, dass man tech ist, indem man den schwersten Bug nimmt (Unsicherheit). Zu allem ja sagen, weil ‚so vergisst man mich nicht’ (das schafft ein Team, das von dir abhängt und nie wachsen wird). Einen Stack verteidigen, weil du ihn gewählt hast, nicht weil er richtig ist. Mails in Echtzeit beantworten und so die Erwartung erzeugen, immer in Echtzeit zu antworten. Jede hatte einen Grund — der abgelaufen ist.
Wie erkennt man eine ausgediente Gewohnheit?
Drei Anzeichen: du tust sie ohne nachzudenken — sie ist Identität geworden, keine Wahl mehr; sie liefert nicht mehr das Ergebnis, für das du sie übernommen hast; wenn jemand vorschlägt aufzuhören, reagierst du emotional unverhältnismäßig. Diese Reizung zeigt, dass die Gewohnheit konstitutiv für dein Selbstbild geworden ist, kein Werkzeug mehr. Genau dort gehört sie hinterfragt.
Was gewinnt man durch Verlernen?
Zeit und Aufmerksamkeit. Jede besetzte Gewohnheit prägt Kalender und Kopf. Sie freizugeben gibt Raum für Dinge, die in den ersten Jahren nicht möglich waren: ein nicht-technisches Buch pro Woche ernsthaft lesen, langsame Entscheidungen statt reaktiver, Nein sagen ohne sich zu rechtfertigen. Kein Rückzug, sondern Refokussierung — der Unterschied zwischen einem müden Senior und einer Führungskraft, die Bestand hat.
Der Autor
