Vorlage für eine Karriereleiter

Karriereleiter für Software Engineers: Vorlage

Fünf Level von Junior bis Principal und sechs Kompetenzen – vom Ausliefern von Code bis zur Entwicklung des Teams.

Kostenloser Plan · Keine Kreditkarte nötig

Diese Karriereleiter ist für Produktunternehmen mit etwa 20 bis 200 Mitarbeitenden geschrieben: Engineers bringen Features von Anfang bis Ende selbst live, die Teams sind klein, und niemand in der Personalabteilung entwirft eine Stellenarchitektur. Sie beschreibt fünf Level – von jemandem am Anfang der Karriere bis zu jemandem, der die technische Richtung des ganzen Unternehmens prägt. Das oberste Level, Principal Engineer, ist ein Fach-Level; die Führung von Engineers beschreibt die separate Karriereleiter für Engineering Manager.

Jedes Level ist darüber definiert, was eine Person tut, nicht über Berufsjahre. Lies eine Zeile der Kompetenzmatrix von links nach rechts, um zu sehen, wie eine Erwartung wächst; lies den Abschnitt eines Levels, um alles auf einen Blick zu sehen, was auf diesem Level erwartet wird. Nutze sie, um zu erklären, was das nächste Level bedeutet, um Selbsteinschätzungen und Check-ins zu strukturieren und um Beförderungsfälle teamübergreifend vergleichbar zu machen.

Betrachte sie als Ausgangspunkt. Benenne die Level nach euren Titeln um, führe Kompetenzen zusammen oder streiche sie, wenn sie nicht zu deinem Unternehmen passen, und formuliere die Erwartungen in deinen eigenen Worten, bevor du die Karriereleiter im Team veröffentlichst.

Die Level im Überblick

Junior Engineer
Lernt die Codebasis kennen und erledigt klar umrissene Aufgaben mit Anleitung.
Verantwortungsbereich
Einzelne Aufgaben in einem Bereich des Produkts, meist von einer erfahreneren Person heruntergebrochen.
Engineer
Liefert Features selbstständig aus und ist ein verlässliches Mitglied des Teams.
Verantwortungsbereich
Kleine und mittlere Features im Bereich eines Teams – von einer kurzen Designnotiz bis in die Produktion.
Senior Engineer
Leitet größere Arbeitspakete und hebt den Standard des Teams um sich herum.
Verantwortungsbereich
Projekte über mehrere Services oder mehrere Personen hinweg und die technischen Entscheidungen eines Teams.
Staff Engineer
Löst Probleme über Teamgrenzen hinweg und lenkt technische Entscheidungen über das eigene Team hinaus.
Verantwortungsbereich
Mehrere Teams oder ein ganzer Produktbereich, einschließlich Problemen, für die kein einzelnes Team zuständig ist.
Principal Engineer
Gibt die technische Richtung des Unternehmens vor und verantwortet seine langfristige technische Gesundheit.
Verantwortungsbereich
Die gesamte Engineering-Organisation und die technische Strategie des Unternehmens für die nächsten Jahre.

Kompetenzmatrix

Jede Zeile ist eine Kompetenz, jede Spalte ein Level. Lies eine Zeile von links nach rechts, um zu sehen, wie die Erwartung wächst.

Was jede Kompetenz bedeutet

Entwicklung und Auslieferung: Anforderungen in funktionierende, wartbare Software verwandeln und sie zu den Nutzern bringen.
Systemdesign: Strukturen, Schnittstellen und Abwägungen wählen, die tragen, wenn das Produkt wächst.
Qualität und Zuverlässigkeit: Das Produkt korrekt, beobachtbar und verfügbar halten und aus Ausfällen lernen.
Zusammenarbeit und Kommunikation: Wirksam mit anderen Engineers, mit Produkt und Design und dem Rest des Unternehmens zusammenarbeiten.
Verantwortung und Produktwirkung: Verstehen, warum die Arbeit zählt, und Verantwortung für Ergebnisse übernehmen, nicht nur für Aufgaben.
Mentoring und Teamentwicklung: Anderen helfen, besser zu werden, und das Team stärker machen als jede einzelne Person darin.

Software Engineer: Erwartungen nach Kompetenz und Level
Kompetenz	Junior Engineer	Engineer	Senior Engineer	Staff Engineer	Principal Engineer
Entwicklung und Auslieferung	Erledigt klar abgegrenzte Aufgaben mit lesbarem Code und Tests, bittet nach ein paar Stunden Feststecken um Hilfe statt erst nach ein paar Tagen und arbeitet Review-Kommentare vor dem Merge ein.	Bringt ein Feature ohne enge Begleitung von einer kurzen Designnotiz bis in die Produktion, teilt es in gut reviewbare Pull Requests auf und schätzt vertraute Arbeit realistisch.	Liefert Projekte über mehrere Services oder Beteiligte hinweg aus, plant die Reihenfolge so, dass früh etwas Nützliches live geht, und räumt Risiken aus, bevor sie das Team blockieren.	Löst Blockaden in der Auslieferung über Teams hinweg: entwirrt gemeinsame Abhängigkeiten, baut das Tooling oder führt die Migrationen durch, die mehrere Teams brauchen, und hält teamübergreifende Projekte auf Kurs.	Prägt, wie die ganze Organisation ausliefert – Release-Praktiken, Plattformentscheidungen, Build- und Deploy-Tooling –, damit jedes Team schneller und sicherer ausliefert.
Systemdesign	Folgt den bestehenden Mustern der Codebasis und kann erklären, warum der geänderte Code so aufgebaut ist, wie er ist.	Entwirft Komponenten innerhalb eines bestehenden Services, schreibt für nicht triviale Änderungen eine kurze Designnotiz und vergleicht vor jeder Entscheidung mindestens zwei Optionen.	Leitet das Design von Features über mehrere Services hinweg, hält die Abwägungen schriftlich fest, damit andere sie prüfen können, und reviewt die Designs anderer Engineers konstruktiv.	Definiert Architektur über Teamgrenzen hinweg – gemeinsame Datenmodelle, Service-Verträge, Make-or-Buy-Entscheidungen – und sieht voraus, wie sich das System in den nächsten ein, zwei Jahren verändern muss.	Verantwortet die technische Strategie des Unternehmens: auf welche Technologien es setzt, welche es ablöst und wie sich die Architektur über mehrere Jahre mit dem Geschäft weiterentwickeln soll.
Qualität und Zuverlässigkeit	Schreibt Tests für die eigenen Änderungen, prüft die eigene Arbeit vor dem Release und behebt Bugs in Code, den er oder sie geändert hat.	Richtet Monitoring und Alerts für die selbst gebauten Features ein, nimmt an der Rufbereitschaft teil und bearbeitet Routine-Incidents anhand des Runbooks.	Leitet die Incident-Response für die Systeme des Teams, schreibt Post-Mortems ohne Schuldzuweisung und sorgt dafür, dass die Folgemaßnahmen tatsächlich umgesetzt werden.	Erkennt systemübergreifende Zuverlässigkeits- und Sicherheitsrisiken, setzt Standards wie die Teststrategie und Service-Level-Objectives und treibt die Behebung über Teams hinweg voran.	Definiert, was Zuverlässigkeit, Sicherheit und Qualität für das Unternehmen bedeuten, wägt sie mit dem Führungsteam gegen Geschwindigkeit ab und ist die letzte Eskalationsstufe bei den schwierigsten Incidents.
Zusammenarbeit und Kommunikation	Teilt Fortschritt und Blocker offen und stellt klare Fragen, wenn eine Anforderung unklar ist.	Klärt Anforderungen direkt mit Produkt und Design, erklärt technische Einschränkungen in einfachen Worten und schreibt Pull-Request-Beschreibungen, denen Reviewer folgen können.	Vertritt das Team in der Planung, verhandelt Umfang und Abwägungen mit dem Produktmanagement und schreibt Dokumente, die auch Menschen außerhalb des Engineerings verstehen.	Bringt mehrere Teams und Funktionen hinter einem technischen Plan zusammen, löst Meinungsverschiedenheiten zwischen Teams und erklärt der Führungsebene technische Risiken.	Hat bei unternehmensweiten Entscheidungen eine Stimme, der man vertraut, übersetzt die Geschäftsstrategie in technische Richtung und zurück und vertritt das Engineering bei Bedarf gegenüber Kunden, Partnern oder Investoren.
Verantwortung und Produktwirkung	Versteht den Zweck der eigenen Aufgaben, prüft, ob das Ausgelieferte für die Nutzer funktioniert, und bleibt dran, bis es das tut.	Verantwortet ein Feature auch nach dem Launch: beobachtet Nutzung und Fehler, behebt, was schiefgeht, und schlägt auf Basis der Erkenntnisse Verbesserungen vor.	Verantwortet einen Produktbereich von Anfang bis Ende, hinterfragt Anforderungen, die den Nutzern nicht dienen, und schlägt Arbeit vor, die die Ziele des Teams voranbringt.	Findet die Probleme mit der größten Hebelwirkung in einem Produktbereich – auch solche, die noch kein Team übernommen hat – und sorgt dafür, dass sie gelöst werden.	Verknüpft Investitionen ins Engineering mit den Ergebnissen des Unternehmens und argumentiert anhand ihrer technischen und geschäftlichen Wirkung für oder gegen große Richtungsentscheidungen.
Mentoring und Teamentwicklung	Bittet um Feedback und setzt es um und schreibt Gelerntes auf, damit die nächste neue Person leichter startet.	Macht sorgfältige Code-Reviews, hilft beim Onboarding neuer Teammitglieder und arbeitet im Pairing mit Junior Engineers an unbekannten Teilen des Codes.	Begleitet ein oder zwei Engineers gezielt im Mentoring, gibt Feedback, das ihnen zum nächsten Level verhilft, und führt Bewerbungsgespräche mit.	Entwickelt Senior Engineers über Teams hinweg weiter, prägt den Interviewprozess und die Engineering-Praktiken und ist für andere eine gefragte Ansprechperson.	Baut die technische Kultur des Unternehmens auf – wie Entscheidungen fallen und wie Wissen geteilt wird – und entwickelt die nächste Generation von Staff Engineers.

Scrolle die Tabelle seitwärts, um alle Level zu sehen.

Als CSV herunterladen Lässt sich in Excel, Google Sheets oder Numbers öffnen.

Junior Engineer: Was erwartet wird

Lernt die Codebasis kennen und erledigt klar umrissene Aufgaben mit Anleitung. Einzelne Aufgaben in einem Bereich des Produkts, meist von einer erfahreneren Person heruntergebrochen.

Entwicklung und Auslieferung: Erledigt klar abgegrenzte Aufgaben mit lesbarem Code und Tests, bittet nach ein paar Stunden Feststecken um Hilfe statt erst nach ein paar Tagen und arbeitet Review-Kommentare vor dem Merge ein.
Systemdesign: Folgt den bestehenden Mustern der Codebasis und kann erklären, warum der geänderte Code so aufgebaut ist, wie er ist.
Qualität und Zuverlässigkeit: Schreibt Tests für die eigenen Änderungen, prüft die eigene Arbeit vor dem Release und behebt Bugs in Code, den er oder sie geändert hat.
Zusammenarbeit und Kommunikation: Teilt Fortschritt und Blocker offen und stellt klare Fragen, wenn eine Anforderung unklar ist.
Verantwortung und Produktwirkung: Versteht den Zweck der eigenen Aufgaben, prüft, ob das Ausgelieferte für die Nutzer funktioniert, und bleibt dran, bis es das tut.
Mentoring und Teamentwicklung: Bittet um Feedback und setzt es um und schreibt Gelerntes auf, damit die nächste neue Person leichter startet.

Engineer: Was erwartet wird

Liefert Features selbstständig aus und ist ein verlässliches Mitglied des Teams. Kleine und mittlere Features im Bereich eines Teams – von einer kurzen Designnotiz bis in die Produktion.

Entwicklung und Auslieferung: Bringt ein Feature ohne enge Begleitung von einer kurzen Designnotiz bis in die Produktion, teilt es in gut reviewbare Pull Requests auf und schätzt vertraute Arbeit realistisch.
Systemdesign: Entwirft Komponenten innerhalb eines bestehenden Services, schreibt für nicht triviale Änderungen eine kurze Designnotiz und vergleicht vor jeder Entscheidung mindestens zwei Optionen.
Qualität und Zuverlässigkeit: Richtet Monitoring und Alerts für die selbst gebauten Features ein, nimmt an der Rufbereitschaft teil und bearbeitet Routine-Incidents anhand des Runbooks.
Zusammenarbeit und Kommunikation: Klärt Anforderungen direkt mit Produkt und Design, erklärt technische Einschränkungen in einfachen Worten und schreibt Pull-Request-Beschreibungen, denen Reviewer folgen können.
Verantwortung und Produktwirkung: Verantwortet ein Feature auch nach dem Launch: beobachtet Nutzung und Fehler, behebt, was schiefgeht, und schlägt auf Basis der Erkenntnisse Verbesserungen vor.
Mentoring und Teamentwicklung: Macht sorgfältige Code-Reviews, hilft beim Onboarding neuer Teammitglieder und arbeitet im Pairing mit Junior Engineers an unbekannten Teilen des Codes.

Senior Engineer: Was erwartet wird

Leitet größere Arbeitspakete und hebt den Standard des Teams um sich herum. Projekte über mehrere Services oder mehrere Personen hinweg und die technischen Entscheidungen eines Teams.

Entwicklung und Auslieferung: Liefert Projekte über mehrere Services oder Beteiligte hinweg aus, plant die Reihenfolge so, dass früh etwas Nützliches live geht, und räumt Risiken aus, bevor sie das Team blockieren.
Systemdesign: Leitet das Design von Features über mehrere Services hinweg, hält die Abwägungen schriftlich fest, damit andere sie prüfen können, und reviewt die Designs anderer Engineers konstruktiv.
Qualität und Zuverlässigkeit: Leitet die Incident-Response für die Systeme des Teams, schreibt Post-Mortems ohne Schuldzuweisung und sorgt dafür, dass die Folgemaßnahmen tatsächlich umgesetzt werden.
Zusammenarbeit und Kommunikation: Vertritt das Team in der Planung, verhandelt Umfang und Abwägungen mit dem Produktmanagement und schreibt Dokumente, die auch Menschen außerhalb des Engineerings verstehen.
Verantwortung und Produktwirkung: Verantwortet einen Produktbereich von Anfang bis Ende, hinterfragt Anforderungen, die den Nutzern nicht dienen, und schlägt Arbeit vor, die die Ziele des Teams voranbringt.
Mentoring und Teamentwicklung: Begleitet ein oder zwei Engineers gezielt im Mentoring, gibt Feedback, das ihnen zum nächsten Level verhilft, und führt Bewerbungsgespräche mit.

Staff Engineer: Was erwartet wird

Löst Probleme über Teamgrenzen hinweg und lenkt technische Entscheidungen über das eigene Team hinaus. Mehrere Teams oder ein ganzer Produktbereich, einschließlich Problemen, für die kein einzelnes Team zuständig ist.

Entwicklung und Auslieferung: Löst Blockaden in der Auslieferung über Teams hinweg: entwirrt gemeinsame Abhängigkeiten, baut das Tooling oder führt die Migrationen durch, die mehrere Teams brauchen, und hält teamübergreifende Projekte auf Kurs.
Systemdesign: Definiert Architektur über Teamgrenzen hinweg – gemeinsame Datenmodelle, Service-Verträge, Make-or-Buy-Entscheidungen – und sieht voraus, wie sich das System in den nächsten ein, zwei Jahren verändern muss.
Qualität und Zuverlässigkeit: Erkennt systemübergreifende Zuverlässigkeits- und Sicherheitsrisiken, setzt Standards wie die Teststrategie und Service-Level-Objectives und treibt die Behebung über Teams hinweg voran.
Zusammenarbeit und Kommunikation: Bringt mehrere Teams und Funktionen hinter einem technischen Plan zusammen, löst Meinungsverschiedenheiten zwischen Teams und erklärt der Führungsebene technische Risiken.
Verantwortung und Produktwirkung: Findet die Probleme mit der größten Hebelwirkung in einem Produktbereich – auch solche, die noch kein Team übernommen hat – und sorgt dafür, dass sie gelöst werden.
Mentoring und Teamentwicklung: Entwickelt Senior Engineers über Teams hinweg weiter, prägt den Interviewprozess und die Engineering-Praktiken und ist für andere eine gefragte Ansprechperson.

Principal Engineer: Was erwartet wird

Gibt die technische Richtung des Unternehmens vor und verantwortet seine langfristige technische Gesundheit. Die gesamte Engineering-Organisation und die technische Strategie des Unternehmens für die nächsten Jahre.

Entwicklung und Auslieferung: Prägt, wie die ganze Organisation ausliefert – Release-Praktiken, Plattformentscheidungen, Build- und Deploy-Tooling –, damit jedes Team schneller und sicherer ausliefert.
Systemdesign: Verantwortet die technische Strategie des Unternehmens: auf welche Technologien es setzt, welche es ablöst und wie sich die Architektur über mehrere Jahre mit dem Geschäft weiterentwickeln soll.
Qualität und Zuverlässigkeit: Definiert, was Zuverlässigkeit, Sicherheit und Qualität für das Unternehmen bedeuten, wägt sie mit dem Führungsteam gegen Geschwindigkeit ab und ist die letzte Eskalationsstufe bei den schwierigsten Incidents.
Zusammenarbeit und Kommunikation: Hat bei unternehmensweiten Entscheidungen eine Stimme, der man vertraut, übersetzt die Geschäftsstrategie in technische Richtung und zurück und vertritt das Engineering bei Bedarf gegenüber Kunden, Partnern oder Investoren.
Verantwortung und Produktwirkung: Verknüpft Investitionen ins Engineering mit den Ergebnissen des Unternehmens und argumentiert anhand ihrer technischen und geschäftlichen Wirkung für oder gegen große Richtungsentscheidungen.
Mentoring und Teamentwicklung: Baut die technische Kultur des Unternehmens auf – wie Entscheidungen fallen und wie Wissen geteilt wird – und entwickelt die nächste Generation von Staff Engineers.

So passt du diese Karriereleiter an

Gleiche die Level mit euren Titeln ab
Wenn eure Titel Developer I, II und III lauten, benenne die Level um, aber behalte für jeden echten Sprung im Verantwortungsbereich ein eigenes Level. Die meisten Unternehmen mit weniger als 100 Engineers brauchen noch kein Principal-Level: Lass es weg, bis tatsächlich jemand diese Arbeit macht.
Bleib bei fünf bis sieben Kompetenzen
Bei mehr als sieben liest sie niemand; bei weniger als vier sehen sehr unterschiedliche Menschen gleich aus. Führe Kompetenzen zusammen, die du immer gemeinsam bewertest, und füge nur dann eine hinzu, wenn sie eine echte Entscheidung verändern würde.
Formuliere Erwartungen als sichtbares Verhalten
Frag dich bei jeder Zelle, ob eine Führungskraft auf ein Beispiel aus den letzten sechs Monaten zeigen könnte. Ersetze Wörter wie „stark“ oder „tief“ durch das, was die Person tatsächlich tut, etwa „leitet die Incident-Response für die Services des Teams“.
Teste sie an echten Menschen, bevor du sie veröffentlichst
Bitte zwei oder drei Führungskräfte, ihre Teammitglieder im Entwurf einzuordnen. Wo sie sich nicht einig sind, ist die Formulierung mehrdeutig: Korrigiere sie, veröffentliche die Karriereleiter und plane fest ein, sie in sechs Monaten erneut zu prüfen.

FAQ

Fragen zu dieser Karriereleiter

Wie viele Level sollte eine Karriereleiter für Software Engineers haben?

Vier bis sechs sind für ein Unternehmen mit 20 bis 200 Mitarbeitenden üblich. Mit weniger werden Beförderungen selten und riesig; mit mehr ist der Unterschied zwischen zwei Leveln zu klein, um ihn zu beschreiben. Diese Vorlage nutzt fünf: Junior Engineer, Engineer, Senior, Staff und Principal.

Müssen Engineers Führungskraft werden, um sich weiterzuentwickeln?

Nein. Dies ist eine Karriereleiter für die Fachlaufbahn: Staff und Principal Engineers wachsen in Verantwortungsbereich und Einfluss, ohne Menschen zu führen. Nutze sie zusammen mit der Karriereleiter für Engineering Manager, damit der Schritt ins Management ein Wechsel der Laufbahn ist und keine Beförderung.

Wie nutzen wir die Karriereleiter für Beförderungsentscheidungen?

Befördere Menschen, die bereits durchgehend auf dem nächsten Level arbeiten, nicht solche, die es vielleicht könnten. Bitte die Person und ihre Führungskraft, für jede Kompetenz des Ziel-Levels konkrete Beispiele zu sammeln, und vergleiche jeden Fall mit derselben Matrix, damit Entscheidungen über Teams hinweg einheitlich bleiben.

Wie passt die Karriereleiter zu Check-ins und 1:1-Gesprächen?

Nutze sie als Agenda regelmäßiger Check-ins: Die Person schätzt sich selbst anhand ihres aktuellen Levels ein, die Führungskraft tut dasselbe, und aus den Abweichungen zwischen beiden werden einige konkrete Entwicklungsmaßnahmen für die kommenden Monate.

Wie oft sollten wir die Karriereleiter aktualisieren?

Überprüfe sie ein- bis zweimal im Jahr und immer dann, wenn sich die Struktur des Unternehmens ändert – etwa wenn ihr ein Plattform-Team gründet oder anfangt, Staff Engineers einzustellen. Formuliere eine Zelle neu, sobald Einschätzungen immer wieder an ihr hängen bleiben.

Baue diese Karriereleiter in LadderKit – kostenlos

Richte ihre Level und Skills für dein Team ein, bewerte Personen in Check-ins daran und triff Beförderungsentscheidungen nach einheitlichem Maßstab.

Kostenlos starten Live-Demo ansehen Ohne Registrierung