Der Super-Senior

Alle Entscheidungen landen beim CTO. Bei dir! Welche Datenbank, wie die Architektur aussieht, wer eingestellt wird, wie das Team mit AI umgeht. Du bist der Flaschenhals, und die naheliegende Lösung ist eine neue Stelle - ein Architekt, noch ein Teamlead, ein Spezialist. Meistens ist das die falsche Lösung, und sie ist teuer.

Lange Zeit war ich genau dieser CTO. Alles bei mir und ich dachte das gehört so, weil es mir ja niemand erklärt hatte. Erst ganz langsam habe ich gelernt, viele Themen abzugeben, Dinge nicht selbst zu entscheiden - angefangen bei ImmoScout als Engineering Manager - und abgeschlossen als CTO einer eBay Tochter im Konzern. Je mehr ich abgegeben habe, desto mehr konnte ich mich auf die eigentlichen Aufgaben meiner CTO Rolle konzentrieren - wenn ich eine Firma verlassen habe, war das Feedback der anderen Mitglieder der Geschäftsleitung: Nicht mein technisches Verständnis hatte den Ausschlag gegeben, sondern mein Business Verständnis und Impact.

Wenn aber delegieren, dann an wen? VP of Engineering? Ja! Teamleads? Ja! Techleads? Ja! Done? Nein, delegieren so nahe wie möglich an den Kern des Problems - und am meisten operative Ahnung hat der Senior Engineer.

In vielen Unternehmen ist die Rolle des Senior Engineers falsch definiert. Sie ist zu stark auf technische Programmierung ausgerichtet, was dazu führt, dass entweder Engineering Manager ihre Rolle nicht ausfüllen können, weil sie ins Tagesgeschäft gezogen werden, oder dass unnötigerweise Architekten und andere Hilfsrollen geschaffen werden, die Kosten erzeugen, aber wenig Impact haben. Defizite in einer Rolle lassen sich nur mit viel Geld durch andere Rollen beseitigen.

Der größte Hebel in vielen Engineering Organisationen ist es daher, die Rolle des Senior Engineers optimaler zu definieren.

Die Senior Entwickler Rolle ist sehr unterschiedlich definiert, meist abhängig von der Firmengröße. In kleinen Organisationen mit weniger als zehn Engineers ist der Senior Engineer primär jemand, der guten Code schreibt. CEOs budgetieren einen Senior um Code zu schreiben, der stabiler und wartbarer ist als der Code eines Juniors. Diese Organisationen kranken nicht an der falschen Senior Rolle, sondern daran, dass sie zu wenig Senior Engineers haben. Hier ist der größte Hebel mehr Seniors einzustellen, ein Senior auf zwei andere Entwickler inklusive der Juniors.

In großen Unternehmen mit mehreren hundert Engineers mit vielen ausgeformten Rollen ist der Senior Entwickler ein technischer Spezialist für ein bestimmtes System, Sprache oder Framework.

Zwischen kleinen Firmen und großen Unternehmen ist die Rolle des Seniors oft unklar und der Senior wird falsch eingesetzt. Entweder ist er “nur” der erfahrenste Code-Schreiber oder er ist ein Spezialist mit tiefgehendem Spezialwissen in einem System.

Beides ist nicht optimal.

Hier ist der große Hebel für den Super-Senior verborgen.

Ich plädiere daher dafür die Senior Rolle viel breiter als üblich zu fassen.

Ein Super-Senior ist dabei kein Staff Engineer. Der Staff Engineer, so wie ihn die meisten Firmen definieren, macht am Ende nur noch das Drumherum, er schreibt Dokumente, sitzt in Architektur-Runden, ist über mehrere Teams verteilt und baut keine Features mehr. Der Super-Senior schreibt weiter Code, 80% seiner Zeit, und die fünf Bereiche macht er in den restlichen 20%. Das ist der Unterschied, und er ist wichtig, denn Architekturentscheidungen von jemandem, der jeden Tag in dieser Architektur arbeitet, sind besser, Businesstradeoffs von jemandem, der die Codebase kennt, sind realistischer, und einen Junior mentort man glaubwürdiger, wenn man selbst liefert.

Die 20% sind aber nicht umsonst. Sie gehen von der Feature-Entwicklung ab, und zwar bei dem Entwickler, der am meisten liefert. Man bekommt Architektur, Hiring und Techentscheidungen vom Tisch des CTOs, und man bezahlt dafür mit Delivery. Es kostet kein zusätzliches Gehalt, aber es kostet Features, und das muss man bewusst entscheiden statt es zu übersehen.

Dieser Tradeoff ist heute leichter zu tragen als noch vor drei Jahren. Wenn ein Senior mit GenAI in der gleichen Zeit deutlich mehr Code schreibt, dann kostet ein Fünftel seiner Zeit eben auch weniger Delivery als früher. Die AI Transformation ist einer der Gründe, warum die breitere Senior Rolle jetzt nötig ist, und gleichzeitig der Grund, warum sie sich jetzt rechnet.

Denn am meisten Nutzen für eine Firma und den verantwortlichen Engineering Manager ist der Senior genau dann, wenn er mehr Verantwortung übernimmt. Wenn er Verantwortung über das Delivery von Features hinaus zugestanden bekommt.

Fünf Kernbereiche für eine Senior Rolle neben der Feature-Entwicklung:

1. Mitarbeiterverantwortung, z.B. Hiring, Mentoring
2. Architekturverantwortung, z.B. Planung und Implementierung von Systemarchitekturen
3. Businessverständnis um die besten Tradeoffs zwischen Tech und Business zu treffen
4. Techentscheidungen, z.B. Datenbankauswahl, Framework, Techstacks
5. Product Engineering im Rahmen der AI Transformation

Diese fünf Bereiche werden oft von anderen Mitarbeitern abgedeckt, was Kosten verursacht, oder von niemandem abgedeckt, was dazu führt, dass der Engineering Manager eingreifen muss, oder der Engineering Manager macht die Sache gleich selbst.

1. Mitarbeiterverantwortung

Eine Senior Entwicklerin kann bereits Mitarbeiterverantwortung übernehmen. Sei es indem sie einen Praktikanten führt, ihm zeigt wie er arbeitet, ihn entwickelt so dass er als Entwickler beginnen kann, oder einen Junior Entwickler mentort, indem sie ihm zeigt wie ein Entwickler arbeitet und wie er selbst zum Senior werden kann. Dadurch reduziert sich die People Bandbreite des Teamleads und die Senior-Entwicklerin kann selbst prüfen, ob sie eine Management oder Staff Karriere einschlagen will. Sollte ihr das Management liegen, ist es leicht in Zukunft Teamleads zu finden.

Manche Senior Entwickler wollen keine Mitarbeiterverantwortung, sie wollen Code schreiben und sonst nichts. Das ist in Ordnung, aber ein Minimum bleibt: Einen Junior auf das eigene Level ziehen, so wie ein Meister einen Lehrling ausbildet, muss ein Senior können. Wer das nicht will oder nicht kann, den behält man, wenn er fachlich sehr gut ist. Wenn er das nicht ist, ist die Firma vermutlich zu klein für einen Entwickler, der nur Code schreibt - das können sich große Unternehmen leisten, eine Firma mit dreißig Engineers nicht.

2. Architekturverantwortung

Oft trifft der CTO langfristige Architektur und Systementscheidungen. Oder, falls der CTO überlastet ist oder die Bandbreite zu groß wird, ein neu eingestellter Architekt. Dabei ist ein guter Senior durchaus in der Lage, Architekturentscheidungen zu treffen. Selbst oder in der Gruppe. Architektur als Vereinfachung der Entwicklung wird am besten von denen entschieden, die auch mit der Architektur leben müssen. Oft bedarf es nur Vertrauen in den Entwickler, ein präzises Alignment mit der Vorstellung des CTOs und der Firma und eine Perspektive. Dadurch werden oft bessere Entscheidungen getroffen und der Engineering Manager ist entlastet - und das Geld für einen Architekten hat man sich gespart. Es kostet zwar Mühe aber keinen Euro mehr.

3. Businessverständnis

Ein Senior Entwickler versteht, dass es keine beste Lösung gibt, sondern jede Entscheidung ein Tradeoff ist. SQLite vs. Postgres. Svelte vs. React. TS vs. Python. Ein sehr guter Senior Entwickler versteht, dass die großen Tradeoffs zwischen Technik und Business liegen - schneller liefern, oder länger bauen? Flexibel sein oder festverdrahtet? Hochskalierbar oder so dass es die aktuellen Kundenzahlen trägt? Um sein Potential voll zu entfalten muss ein Senior Entwickler das Business verstehen, mit Business reden (Marketing, Sales, CFO) und die beste Entscheidung für die Firma treffen können. Die Entscheidungen sind dann langfristig besser. Und wenn Tech besser mit Business aligned ist, hat der CTO weniger Eskalationen zu managen.

4. Techentscheidungen

Von all den Themen, die ich abgegeben habe, habe ich die Techentscheidungen am längsten festgehalten. Wenn ich schon verantwortlich für das Ergebnis von Entscheidungen war, dann wollte ich die Entscheidungen wenigstens selbst treffen. Im Rückblick nach ein paar Jahren habe ich festgestellt, dass meine Entscheidungen zwar nicht schlecht waren, ein gut angeleiteter Senior diese aber auch hätte treffen können - mit dem Ergebnis, dass der Senior sich entwickelt und ich gleichzeitig nicht das Bottleneck in der Organisation bin. Power to the seniors!

5. Product Engineering

Aktuell befinden sich alle Engineering Organisationen in der Migration zu AI. Wie verwenden wir AI? Was ist nun die Rolle der Entwicklung? Wie bringen wir den Prototype live, den der CEO mit Claude abends zuhause “programmiert” hat? Zu viele CTOs betrachten das Problem top-down. Ohne Spieler im Feld, die den Wandel zum Product Engineer tragen und vorleben, ist der Erfolg schwer zu erreichen. Seniors müssen das neue Kernstück des Product Engineering werden, sie haben das notwendige technische Verständnis und die Erfahrung, AI generierten Code erfolgreich in Produktion zu bringen und über Jahre zu betreiben.

Product Engineering erfordert mehrere neue Skills. Zum einen Hardening und Gardening, um GenAI Code sicher in Produktion zu bekommen (Hardening) und um den Code trotz hunderter neuer Features zu betreiben (Gardening).

Product Engineering braucht auch weitere PM Skills, und vor allem Intent und Taste. Was will ich bauen als Product Engineer, wenn ich mehr Produkt owne, und was ist gutes und schlechtes Produkt (Taste) - beides kann eine AI einem nicht geben.

Diese fünf Bereiche stehen in kaum einer Rollenbeschreibung für Senior Entwickler. Deshalb passieren sie auch nicht.

Nicht jeder Senior kann alle fünf Bereiche, und das muss auch nicht sein. Drei von fünf sind vollkommen in Ordnung, und welche drei es sind, hängt vom Menschen und vom Team ab. Wenn ein Senior dagegen keinen einzigen der fünf Bereiche abdeckt, dann hat man zu viel bezahlt, und man hat zusätzlich zu eng eingestellt, weil im Hiring nur auf Technik geschaut wurde und nicht auf die Breite der Rolle. Aus meiner Erfahrung aber ist nicht der Senior das Problem, der durchaus in der Lage ist mehr abzudecken, sondern der CTO, der die Rolle zu klein gefasst hat.

Wie fängt man nun an?

Nun stellt sich die Frage, wo fange ich mit meinen Senior Entwicklern an?

Am besten fängt man mit einer neuen Rollenbeschreibung an. Rollenbeschreibungen können ganz unterschiedlich aussehen, wichtig sind zwei Dinge. Erstens, dass sie knapp genug ist, damit sich der Manager und der Mitarbeiter alle Punkte merken können, nur wenn man sich die Punkte einer Rollenbeschreibung merken kann, kann man sich daran halten und Mitarbeiter anhalten, die Rolle zu erfüllen. Zweitens muss die Rollenbeschreibung ein tägliches Werkzeug sein, kein Dokument, das irgendwo liegt. Die Rollenbeschreibung muss dem Mitarbeiter helfen zu entscheiden, was und wie er arbeitet, und ein Werkzeug in 1:1s, Beförderungs- und Leistungsgesprächen sein und als Grundlage in Gehaltsdiskussionen dienen - aber auch in jedem Meeting.

Mein Format für Rollenbeschreibungen erfüllt diese Anforderungen. Meine Rollenbeschreibungen umfassen vier Bereiche:

1. Why
2. Responsibilities
3. Ownerships
4. Success

Das Why erklärt in zwei kurzen Sätzen, warum die Rolle existiert, warum der CEO für die Rolle Geld ausgibt, warum die Firma die Rolle braucht.

Responsibilities erklärt, wofür die Rolle sorgen muss, dass etwas passiert, etwas eingehalten wird, etwas gemacht wird, etwas erledigt wird.

Ownerships ist, was die Rolle entscheiden darf. Wer etwas owned, darf über die Sache entscheiden. Responsible for Code Quality heißt, dass die Rolle dafür sorgt, dass die Code Qualität eingehalten wird. Code Quality Ownership bedeutet, die Rolle entscheidet, was Code Quality ist, mit welchen Werkzeugen sie festgestellt wird, was gemacht werden muss um Code Quality einzuhalten und welche Metriken und Werte sagen: Gut oder schlecht.

Success bedeutet: Wonach wird der Erfolg des Mitarbeiters bewertet? Was muss der Mitarbeiter machen um als erfolgreich zu gelten - in den Augen des Chefs und der Firma, was muss er erreichen für eine Gehaltserhöhung? Die wenigsten Mitarbeiter wissen, woran und wie ihr Chef ihren Erfolg misst.

Rollout

Wie bei jedem Change-Management braucht die Veränderung Zeit. Eine neue Richtung und Rolle nur zu verkünden ist von wenig bis keinem Erfolg gekrönt. Der Rollout beginnt mit Gesprächen über die Richtung, die Motivation, warum diese Änderung notwendig ist und wie sie die Arbeit besser macht. Die Veränderung beginnt mit einer neuen positiven Perspektive und der Vision einer goldenen Zukunft.

Alle Mitarbeiter haben eine Meinung und Feedback und müssen gehört werden. Oft ist das Gehört-Werden wichtiger als das Mitbestimmen. In Workshops und 1:1s wird dann die neue Rolle diskutiert, das Verständnis der Rolle und was sie genau im täglichen Arbeiten bedeutet und welche Änderungen konkret notwendig sind.

Ab einem Stichtag X gilt die neue Rolle und ab dann muss die Rolle gelebt werden.

Fast alle (Engineering) Manager, die ich getroffen habe, denken, dass es ihre Aufgabe ist einen Plan zu erstellen und dann zu verkünden. Das ist der schwierige Teil, was ist der perfekte Plan? Was sind die perfekten Rollenbeschreibungen? Wochen vergehen bis ein Manager glaubt, mit seinem Plan fertig zu sein. Dann wird der Plan verkündet - die neuen Rollen - und der Manager denkt, die Arbeit sei getan.

Falsch.

Der wirklich schwierige Teil aus meiner Erfahrung ist es dagegen den Plan auszurollen. Und zum Fliegen zu bekommen. Die Strategie erstellen ist der einfache Teil, 10% der Arbeit. Die Strategie zum Fliegen zu bekommen, ist 90% der Manager Arbeit und der mühsame, aufwendige Teil, der Monate dauert.

Die meisten CTOs, die ich kenne, haben nicht genug Zeit (neben meiner Erfahrung auch ein Grund, warum viele CTOs den Rollout z.B. mir übergeben). Aber wegen Zeitmangels verwenden sie nicht genug Zeit darauf, ihren Plan erfolgreich zu machen (Setup for Success).

Wie macht man es richtig? Indem man den Rollout als die eigentliche Arbeit plant und nicht als das, was nach der Ankündigung noch übrig ist.

Ein Rollout einer neuen Rolle dauert mindestens sechs Monate und erfordert viel Wiederholung - durch den Manager, Hinweise auf die Einhaltung - durch den Manager, Lob bei richtigem Verhalten - durch den Manager - und Unterstützung in der Veränderung, und dauernder Verweis auf die Rolle im täglichen Arbeiten (Verhalten in Meetings, Verantwortung übernehmen, “Wer macht das?”). Das ist sehr mühsam, aber nur so wird das Problem gelöst und die Zukunft erfolgreicher.

Viele geben hier auf. Viele meiner Kunden hören mit dem Veränderungsprozess auf, weil sie keine Zeit haben. Viele Senior Entwickler fallen unter Druck oder in einer Krise wieder auf ihr altes Verhalten zurück.

Grit - Durchhalten ist gefragt. Und viel viel Zeit Investment.

Der Erfolg, den man dann mit der richtigen Senior Rolle als Engineering Manager oder CTO hat, hilft einem dann aber das beste aus der Abteilung zurückzubekommen - einerseits - und dass man sich mit vielen Details nicht mehr beschäftigen muss andererseits. Erst mit einer starken, breiten Senior Rolle können Engineering Manager und CTOs ihre eigene Rolle richtig ausfüllen und werden nicht immer wieder ins Tagesgeschäft gezogen.

Denn es gibt Aufgaben, die nur der CTO machen kann, nicht weil er sie besser kann als seine Entwickler, sondern wegen seines Titels und seiner Position in der Firmenstruktur. Strategie und Vision für die Technik, über die nächsten Quartale hinaus. Den CEO mit Tech-Input unterstützen, damit dieser Entscheidungen für die Firma trifft, die technisch auch tragen. Und Innovation von der Tech-Seite treiben, so wie sie der CEO von der Business-Seite treibt und der CPO von der Produktseite. Diese drei Dinge kann kein Senior übernehmen, egal wie gut er ist, und genau diese drei Dinge bleiben liegen, wenn der CTO seine Tage mit Datenbankauswahl, Architekturfragen und Hiring verbringt.

Wenn du aber nicht in die Zukunft investierst, dann wird die Zukunft genau so sein wie heute.