Werde ein Teil von 5000 CTOs und Engineering Managern für ungefilterte Insights Abonnieren

Vom Entwickler zum Manager

Gestern hast du Code geschrieben. Heute sitzt du in Meetings. Du bist dir nicht sicher, ob es die richtige Entscheidung war.


My personal story

Mein Wechsel vom Entwickler zum Manager war einerseits einfach - es ist einfach passiert. Andererseits habe ich lange damit gekämpft, das Coden loszulassen. Einmal als Engineering Manager hatte das Team eine sehr knappe Deadline. Wir arbeiteten nachts - ein klassischer Death March. Ich wollte helfen und fragte den verantwortlichen Senior Developer, was ich coden könnte - ich war schließlich ein Entwickler mit jahrzehntelanger Erfahrung! Mein Direct Report konnte nicht nein sagen (wegen meiner schlechten Management-Skills) und ich schrieb Code. Der Senior gab mir Frontend-JS in dem Glauben, ich könnte das nicht vermasseln. Aber ich kannte die Edge Cases des hauseigenen Web-Frameworks auf IE6 nicht. Nach dem Release gab es wegen meinem Code eine Site-Outage (Millionen User) - mit JavaScript, eine Meisterleistung. Ich hätte offensichtlich keinen Code schreiben sollen, denn obwohl ich ein sehr erfahrener Entwickler war, gab es Unknown Unknowns für mich.

Die Trauer, über die niemand spricht

Ich spreche mit vielen First-Time Engineering Managern. Die Situation ist immer dieselbe: Sie waren großartige Entwickler. Sie haben Features geshippt, schwere Probleme gelöst, Flow States erlebt. Das fühlte sich gut an. Deswegen sind sie Programmierer geworden.

Und jetzt? Meetings ohne Ende. Seit Wochen kein richtiger Code mehr. Am Ende des Tages nichts vorzuweisen. Nichts gemacht. Und niemand hat dich davor gewarnt :-)

Die meisten neuen Engineering Manager durchleben das. Die Guten geben es zu. Der Rest tut so, als wäre alles okay, während er sich heimlich fragt, ob er einen schrecklichen Fehler gemacht hat. Ich weiß, viele gehören gerade zu dieser zweiten Gruppe.

Was du wirklich verlierst

Lass uns ehrlich sein.

Erstens: das Dopamin. Code schreiben gibt dir sofortiges Feedback. Tests laufen, ein Feature funktioniert. Du wusstest, ob du gute Arbeit gemacht hast. Diese Feedback-Loop ist jetzt weg. War das One-on-One gut? Wurde das Feedback verstanden? Du wirst es erst in Monaten wissen. Vielleicht aber auch nie.

Dann der Flow State. Deep Work mit echten Arbeitsergebnissen mit denen man zufrieden ist, erfordert Arbeiten ohne Unterbrechung. Manager bekommen das nicht - keinen Block für Arbeit (wenn du dir keinen Blocker in den Kalender einstellst). Dein Job sind Unterbrechungen. Das ist kein Fehler, das ist die Job Beschreibung (obwohl dir das vorher niemand sagt).

Du verlierst auch den Experte-Status. Du warst der beste Entwickler im Team - deswegen hat man dich befördert. Jetzt bist du wieder ein Anfänger. Kein Stack Overflow für “wie gebe ich schwieriges Feedback an einen Senior Developer, der länger hier ist als ich.” Ich hab gesucht. Und obwohl die AI hilft, fühlt es sich trotzdem fremd an.

Diese Veränderung ist real. So zu tun als wäre es nicht so, hilft dir nicht.

Was du gewinnst (irgendwann)

Die Sache, die dir niemand sagt: Die positiven Effekte brauchen länger zum Erscheinen als die negativen.

Die negativen Effekte treffen dich am ersten Tag. Du vermisst das Coden sofort. Das Positive? Sechs Monate bis ein Jahr wenn du durchhältst.

Der große Gewinn ist dein großer Hebel. Ich argumentiere, dass das eigentlich der gesamte Punkt ist, Manager zu werden - zumindest für mich, aber die meisten Leute framen es nicht so. Ein großartiger Entwickler kann die Arbeit von vielleicht zwei oder drei durchschnittlichen Entwicklern machen. Ein großartiger Manager kann ein ganzes Team besser machen. Das ist 5x, 10x, 20x mehr Impact. Aber du wirst nichts davon sehen, bis dein Team Dinge shippt, die du alleine nie hättest bauen können. Das braucht Zeit. Und Glauben. Und Vertrauen.

Du bekommst auch größere Probleme auf den Tisch. Als Entwickler hast du technische Probleme gelöst. Als Manager löst du People-Probleme, Strategie-Probleme, organisatorische Probleme. Diese sind schwerer. Mehrdeutiger. Auch impactvoller. Ob das ein guter Trade ist hängt von dir ab. Manche Leute hassen es - es ist gut das früh herauszufinden. Das ist okay.

Es gibt auch Compound Impact. Der Entwickler, den du gementort hast, wird andere mentoren. Der Prozess, den du gefixt hast, wird dich überleben. Die Kultur, die du baust, multipliziert sich über jeden, der dazukommt. Dieser Impact ist Tag für Tag unsichtbar, aber enorm über Jahre. Ich habe das nicht verstanden, bis ich Leute, die ich als Mitarbeiter gecoacht hatte, selbst CTOs wurden.

Der Trade ist nicht schlecht.

Ehemalige Peers managen

Eine Herausforderung, der viele begegnen beim Wechsel vom Entwickler zum Manager: Montag waren alle Mitarbeiter, haben sich über dieselben Dinge beim Mittagessen beschwert - das Management war der Feind, wenn sie einen nur arbeiten lassen würden. Dienstag bist du ihr Chef. Die Beziehung ändert sich, ob du willst oder nicht. Und plötzlich bist du einsam.

Erkenne die Veränderung an
Tu nicht so, als hätte sich nichts geändert. Alles hat sich geändert. Ich habe neue Manager gesehen, die so tun, als wäre “nichts anders, wir sind immer noch Freunde!” - es funktioniert ganz selten. Besser, es direkt anzuerkennen: “Das ist seltsam für uns beide. Lass es uns herausfinden”. Diese Ehrlichkeit hilft mehr als so zu tun.
Distanz ist notwendig
Du kannst nicht mehr auf dieselbe Weise ihr Freund sein. Nicht weil du sie nicht magst. Aber du hast jetzt Informationen, die du nicht teilen kannst. Du wirst Entscheidungen treffen, mit denen sie nicht einverstanden sind. Schließlich bist du derjenige mit der Aufgabe, sie zu feuern wenn es sein muss - und du musst es vieleicht wirklich tun. Du brauchst etwas Distanz, um deinen Job zu machen. Unangenehm? Ja. Notwendig? Auch ja.
Manche Beziehungen werden es nicht überleben
Ein paar Leute werden dir die Beförderung übel nehmen. Das ist ihr Problem, nicht deins. Fokussiere dich auf die Leute, die mit dir arbeiten wollen. Ich habe zu viel Energie auf die Nachtragenden verschwendet früh in meiner Karriere.
Keine Bevorzugung
Die Versuchung ist stark. Dein früherer Lunch-Kumpel sollte keine Sonderbehandlung bekommen. Alle schauen zu. Handle entsprechend. Du bist jetzt das Vorbild.
Beschwerden handhaben
Der schwierigste Teil: Du wirst Beschwerden über Management-Entscheidungen hören. Manchmal sind diese Beschwerden über dich. Und du kannst dich nicht verteidigen wie früher. Du musst es einfach hinnehmen. Das wird mit der Zeit leichter. Nicht sicher, ob es je einfach wird. Und je mehr Leute in deiner Abteilung, desto mehr Beschwerden wirst du hören - und von Leuten, die dich nicht kennen! In einem kleinen Team kennt jeder deine Geschichte, ihr seid gemeinsam durch schwierige Zeiten (All-Nighter!) gegangen. In einem großen Team weiß der neue Junior Developer das nicht, wie du und das Team nachts um 2 zusammen den Incident gefixed habt, denkt aber, der CTO hat keine Ahnung.

Die Coding-Falle

Hör nicht auf zu coden.

Ich hab’s gemacht. Du wirst es machen. Es fühlt sich produktiv an. Es ist komfortabel. Du bist gut darin. Du springst ein und füllst die Lücke die du in deinem Team siehst. Dein Team ist eh schon überlastet, was kannst du tun? CODEN!

Aber es macht dich auch schlechter in deinem neuen Job.

Jede Stunde, die du codest, ist eine Stunde, die du nicht managst. Keine One-on-Ones. Kein Nachdenken über Team-Dynamik. Kein Blocker-Entfernen. Keine Arbeit an Strategie und Vision. Keine Unterstützung des CEO mit technischer Expertise. Du versteckst dich in der Sache, die du schon kannst. Ich verstehe es. Ich hab’s zu lange selbst gemacht.

Ich sage nicht, dass du nie wieder Code schreiben sollst. Aber ganz ehrlich: “Das Team braucht mich zum Coden” bedeutet meistens “Ich weiß noch nicht, wie ich anders beitragen kann.” Das ist okay zuzugeben. Die meisten neuen Manager fühlen das. Lass es dich nur nicht leiten. Ab und zu zu coden, weil es dir Spaß macht, ist okay - und es ist deine Verantwortung, ein Umfeld zu schaffen, in dem das keine Probleme für das Team verursacht.

Wenn dein Code das Release blockiert, hast du als Manager versagt. Du bist der Flaschenhals. Dein Job ist es, das Team ohne dich funktionieren zu lassen, nicht dich unentbehrlich zu machen. Das ist kontraintuitiv, wenn du deine ganze Karriere damit verbracht hast, durch technische Skills unentbehrlich zu werden.

Der Übergang ist hart. Härter als dir jemand sagt. Erst kürzlich hatte ich einen neuen CTO-Klienten fürs Coaching, der als neuer CTO blockiert ist, weil er zu viel codet. Die Manager, die es schaffen, sind die, die ihre alte Identität loslassen und eine neue für sich finden. Das ist was ich über 25 Jahre beobachtet habe.

Häufige Fehler

Ich habe alle diese Fehler gemacht. Du auch?

Mein größter Fehler: Probleme lösen statt zu coachen. Ein Entwickler kommt mit einem Bug zu dir. Du kennst die Antwort. Es ist schneller, wenn du es ihm einfach sagst. Aber wenn du immer die Antwort gibst, werden sie dich immer brauchen. Stell stattdessen Fragen. Wenn mich jemand fragt, “Stephan was soll ich machen?” sage ich “Was würdest du machen?” Lass sie strugglen. So wachsen sie. Das war schwer für mich - ich mochte es, der mit den Antworten zu sein - ganz ehrlich.

Du musst dir die Zeit nehmen, um dein Team zu trainieren. Training bedeutet in eine bessere Zukunft zu investieren. Wenn du nicht viel Zeit ins Training deines Teams investierst, wird die Zukunft nicht besser, sondern gleich. Jede Minute Feedback, jede Minute die du einem Entwickler hilfst zu wachsen, machen deine Zukunft leichter.

Neue Manager vermeiden auch schwierige Gespräche. Als Entwickler konntest du einen schwierigen Kollegen einfach ignorieren. Als Manager bist du für die Team-Dynamik verantwortlich. Die Person, vor der alle Angst haben wegen der zynischen Kommentare? Dein Problem. Du kannst nicht so tun, als würde es sich von selbst lösen. Wird es nicht.

Hör auf zu fragen “was habe ich heute gemacht?” Fang an zu fragen “was habe ich heute ermöglicht?” Andere Frage. Andere Antwort.

Wenn du das Gefühl brauchst etwas geschaffen zu haben: One Thing a Day - mach eine große Sache am Tag und es fühlt sich wieder an, als hättest du was geschafft.

Dann noch: zu lange warten, das Coden zu lassen. Es gibt keinen perfekten Moment. Du wirst dich nie bereit fühlen. Aber je länger du im Code bleibst, desto länger wartet dein Team auf einen echten Manager.

Du musst das nicht alleine herausfinden

Der Wechsel vom Entwickler zum Manager - oder vom Engineer zum Manager, manche sind da pingelig, ich nicht ;-) - ist einer der härtesten in Tech. Du lernst einen komplett neuen Job, während du um den alten trauerst. Vom selber etwas schaffen als Entwickler zu einer Rolle deren Aufgabe es ist, dass andere etwas schaffen. Kein Wunder, dass es überwältigend ist.

Die meisten neuen Manager kämpfen in Stille. Sie denken, alle anderen finden das einfach. Tun sie nicht. Ich habe mit Hunderten gesprochen. Der Übergang ist für fast jeden schwer.

Wenn du dich fragst, ob du die richtige Wahl getroffen hast - das ist normal. Heißt nicht, dass du versagst. Heißt, dass du aufpasst.

Bereit für Unterstützung?

Ich habe diesen Übergang selbst durchgemacht. Die Fehler gemacht. Es irgendwann herausgefunden. Jetzt coache ich Engineering Manager und CTOs durch genau das. Wenn du jemanden in deiner Ecke willst, der das durchgemacht hat - lass uns reden.

Mehr über Coaching

TL;DR: Der Übergang vom Entwickler zum Manager bringt echte Trauer mit sich, vor der niemand warnt. Du verlierst das Dopamin vom Code-Shippen, den Flow-State der Deep Work, und Experte im Raum zu sein. Die Gewinne zeigen sich erst nach 6-12 Monaten: Leverage (ein ganzes Team besser machen ist 10-20x Impact), größere Probleme, Compound-Wirkung durch Leute die du entwickelst. Ehemalige Peers zu managen erfordert die Beziehungsänderung anzuerkennen, notwendige Distanz zu akzeptieren, keine Favoriten zu haben. Die Coding-Falle ist real - jede Stunde die du codest ist eine Stunde die du nicht managest.