Vom Backend-Entwickler zum technischen Leiter
Was sich tatsächlich änderte, als ich nicht mehr derjenige war, der den Code schrieb – und was ich mir gewünscht hätte, dass mir jemand im vierten Jahr gesagt hätte.
Der schwierigste Teil des Wechsels von einem Senior IC zu einem technischen Leiter war nicht die Delegation. Es war das Lernen, dass sich mein Job von Code ausliefern zu Klarheit ausliefern verändert hatte.
Der Wandel
Acht Jahre lang wurde mein Wert daran gemessen, was ich bauen konnte. PRs gemerged, Vorfälle gelöst, Systeme entworfen. Der Feedback-Zyklus war eng. Du hast geliefert, es hat funktioniert, Dopamin.
In dem Moment, als ich anfing zu führen, brach der Zyklus. Die Arbeit, die ich am Montag erledigte, könnte sich in einem Monat auszahlen, wenn überhaupt. Wenn ich meinen Tag an PRs maß, fühlte sich jeder Tag wie ein Verlust an.
Was ich stattdessen zu schätzen lernte
- Eine klare Entscheidung, die niedergeschrieben ist. Ein einseitiges ADR, das drei Ingenieure freischaltet, ist mehr wert als eine Woche meiner eigenen Commits.
- Ein Teamkollege, der wächst. Wenn die Person, mit der ich am Dienstag zusammengearbeitet habe, die nächste Version am Freitag ohne mich ausliefert, ist das mein PR.
- Ein Team, das gut "nein" sagen kann. Widerstand mit Begründung ist ein Zeichen dafür, dass das Team Handlungsspielraum hat. Stille ist eine Warnung.
Was ich falsch gemacht habe
Ich habe versucht, im gleichen Tempo weiter zu coden. Es hat nicht funktioniert. Mein Code wurde schlechter – kontextwechselnd, hastig, um 22 Uhr erledigt. Es hat auch die Arbeit verdrängt, die nur ich erledigen konnte.
Die Lektion: Wenn du der Einzige bist, der es tun kann, solltest du es tun. Wenn zwei andere Personen im Team es tun könnten, solltest du es wahrscheinlich nicht tun.
Was ich meinem Ich vor vier Jahren sagen würde
- Der Titel wird kommen. Die zwischenmenschlichen Fähigkeiten, wenn du sie überspringst, werden es nicht.
- Schreib mehr. Liefere ein Quartal lang mehr Dokumente als Code und schau, was passiert.
- Fang an, Dinge zu delegieren, in denen du schlecht bist, bevor du die Dinge delegierst, in denen du gut bist. Die guten sind leichter loszulassen, wenn das Team bereits Vertrauen in die schwierigen aufgebaut hat.
Weiter geht's
Wohin als Nächstes?
Stöbere durch weitere technische Texte, sieh dir die Engineering Case Studies an oder melde dich direkt.