Eine Engineering-Kompetenzmatrix beschreibt pro Karrierelevel und Kompetenzbereich, welches Verhalten beobachtbar sein muss. Dieser Beitrag liefert keine leere Hülle, sondern eine ausgefüllte Vorlage: 4 Level (Junior bis Staff) × 7 Engineering-Bereiche mit konkreten Ankern, eine IC-/Manager-Doppelleiter und die DACH-Pflichten (Betriebsrat, DSGVO, AI-Act).

Den allgemeinen Aufbau-Prozess – Skala wählen, Anker formulieren, kalibrieren – behandeln wir hier bewusst kurz und verweisen auf den ultimativen Guide für erfolgreiches Skill-Management. Dieser Post beantwortet die eine Frage, die generische Vorlagen offenlassen: Was steht konkret in einer Engineering-Matrix – ausgefüllt, mit Sprache aus dem Entwickleralltag (PRs, RFCs, On-Call, Postmortems)?

Welche Kompetenzfamilien in eine Engineering-Matrix gehören

Eine gute Matrix misst mehr als Coding-Geschwindigkeit. Die öffentlich dokumentierten Leveling-Frameworks großer Tech-Firmen decken durchweg vier bis sechs Dimensionen ab. Das Dropbox Engineering Career Framework arbeitet mit Results, Direction, Talent, Culture und Craft; die CircleCI Competency Matrix mit Technical Skills, Quality & Testing, Debugging & Observability, Understanding Code, Communication und Leadership. Daraus lassen sich sieben Bereiche ableiten, die für die meisten Software-Teams tragen:

Eine Engineering-Matrix sollte sich auf diese fachnahen Bereiche konzentrieren. Allgemeine überfachliche Skills (Selbstorganisation, generische Kommunikation) gehören eher in eine separate Soft-Skills-Matrix. Wie viele Bereiche sinnvoll sind und wie Sie Anker formulieren, behandelt der Bereich Skill- und Kompetenzmanagement – hier geht es um die Engineering-Inhalte.

Die ausgefüllte IC-Matrix: 4 Level × 7 Kompetenzfamilien

Das ist der Kern dieses Beitrags. Die folgende Matrix zeigt für jeden der sieben Bereiche, was sich von Junior (L1) über Mid (L2) und Senior (L3) bis Staff (L4) konkret ändert. Die Anker orientieren sich an öffentlich dokumentierten Leveln: Im Dropbox-IC1-Profil nimmt ein Junior an On-Call-Rotationen teil und navigiert unbekannte Codebasen, im Dropbox-IC3-Profil reagiert ein Engineer mit Dringlichkeit auf SEV-Incidents und etabliert Code-Review-Standards. In der Wise Engineering Career Map übernimmt ab IC3 eine führende Rolle im Post-Incident-Prozess.

Drei Prinzipien machen diese Matrix belastbar. Erstens: Jeder Anker beschreibt beobachtbares Verhalten, nicht Eigenschaften – „führt den Post-Incident-Prozess“ statt „ist verantwortungsbewusst“. Zweitens: Scope wächst mit dem Level, nicht nur die Tiefe. Die aggregierte Level-Systematik von Levels.fyi beschreibt diesen Sprung als wachsenden Impact-Radius und steigende Fähigkeit, mit Ambiguität umzugehen. Drittens: L4/Staff ist als Multiplier definiert, nicht als „Super-Senior“ – Staff Engineers sind laut Levels.fyi typischerweise weniger als 10 % der Engineering-Population.

Wer L5/L6 (Principal, Distinguished) ergänzt, verschiebt den Scope von „mehrere Teams“ zu „org-weit bis extern“: Im Dropbox-Framework reicht der IC-Track bis IC7, in der Wise-Map bis IC6. Mehr Level sind nur sinnvoll, wenn jede Stufe einen realen Scope-Unterschied hat – sonst existiert L6 nur auf dem Papier.

IC-Track vs. Manager-Track: die Doppelleiter

Der häufigste Leveling-Fehler ist die false forcing function: Engineers werden in Management gedrängt, weil das der einzig sichtbare Weg nach oben ist. Eine saubere Matrix trennt deshalb zwei gleichwertige Leitern. CircleCI veröffentlichte seine IC-Matrix bewusst zuerst und kündigte eine separate Management-Matrix an; Wise führt IC1–IC6 und einen Engineering-Lead-Track EL1–EL4 als parallele, gleichwertige Tracks. Im Dropbox-Framework läuft der Manager-Track von M3 bis M7 neben dem IC-Track.

Ein L4/Staff und ein M2/Engineering Manager sind beide senior – aber Kompetenzgewichtung und Evidenz unterscheiden sich:

Praxis-Effekt: Sobald ein IC-Track mit echtem Scope sichtbar ist, wählen mehr Engineers den technischen Weg statt aus Mangel an Alternativen ins Management zu wechseln. Wichtig ist, dass beide Leitern dieselbe Vergütungslogik tragen – sonst bleibt die Doppelleiter Theorie.

Evidenz: woran Sie ein Level wirklich erkennen

Eine Bewertung ist nur so gut wie ihr Beleg. In Engineering-Teams sind die Evidenztypen spezifisch und gut dokumentierbar:

Als Faustregel gelten zwei bis drei Evidenz-Items pro bewertetem Bereich aus den letzten sechs bis zwölf Monaten (so empfiehlt es das Practica-Leveling-Framework). „Ist ein guter Kommunikator“ ohne Beleg reicht nicht; „hat den RFC zur Datenbank-Migration geschrieben, den drei Teams übernommen haben“ schon. Welche Bewertungsskala (0–4 oder 1–5) dahinterliegt und wie Sie zwischen Backend, Frontend und Platform kalibrieren, behandelt der Skill-Management-Guide.

AI-Assisted Development als neue Kompetenz-Zeile

KI-Coding-Tools (GitHub Copilot, Cursor, LLM-gestützte Code-Generierung) verändern den Engineering-Alltag – und sind inzwischen auch regulatorisch relevant. Artikel 4 des EU AI Act verpflichtet Anbieter und Betreiber von KI-Systemen, ein ausreichendes Maß an „AI Literacy“ ihres Personals sicherzustellen. Die Pflicht gilt seit dem 2. Februar 2025. Teams, die KI-Tools zur Code-Generierung einsetzen, fallen als „deployer“ darunter – eine Kompetenzmatrix ist ein naheliegender Ort, diese Literacy zu dokumentieren.

Konkret lässt sich „AI-Assisted Development“ als achte Zeile aufnehmen:

DACH-spezifisch: Betriebsrat und Datenschutz

Diese Ebene fehlt in praktisch allen internationalen Vorlagen – ist in Deutschland aber Pflicht.

Mitbestimmung des Betriebsrats (§ 94 BetrVG)

Führen Sie eine Engineering-Kompetenzmatrix als einheitlichen, unternehmensweiten Bewertungsstandard ein, greift die Mitbestimmung. § 94 Abs. 2 BetrVG gibt dem Betriebsrat ein Zustimmungsrecht bei der Aufstellung allgemeiner Beurteilungsgrundsätze. Eine org-weit verbindliche Matrix standardisiert Leistungsbewertung und fällt damit unter diesen Begriff – nach ständiger Rechtsprechung des Bundesarbeitsgerichts erstreckt sich die Mitbestimmung auch auf die Software, die die Bewertung abbildet. Kommt keine Einigung zustande, entscheidet die Einigungsstelle. Praktischer Rat: Beziehen Sie den Betriebsrat von Anfang an ein, statt eine fertige Matrix zur Zustimmung vorzulegen.

DSGVO und § 26 BDSG bei Skill-Daten

Skill-Bewertungen sind personenbezogene Arbeitnehmerdaten. Nach § 26 Abs. 1 BDSG dürfen Skill-Daten, die für das Arbeitsverhältnis erforderlich sind (etwa die Programmiersprachen eines Software Engineers), ohne gesonderte Einwilligung verarbeitet werden. Drei Punkte sind in der Praxis entscheidend (eine fundierte Aufbereitung findet sich bei den datenschutz-notizen zur Einführung einer Skill-Matrix):

Engineering-spezifische Stolperfallen

Häufig gestellte Fragen

Was unterscheidet eine Engineering-Kompetenzmatrix von einer generischen Skills-Matrix?

Eine generische Skills-Matrix listet beliebige Kompetenzen für beliebige Rollen. Eine Engineering-Matrix nutzt fachnahe Bereiche (System Design, Code Review, On-Call/Incident) und Evidenztypen aus dem Entwickleralltag (PRs, RFCs, Postmortems). Sie bildet außerdem die Doppelleiter aus IC- und Manager-Track ab, die in technischen Organisationen üblich ist.

Wie viele Level sollte eine Engineering-Karriereleiter haben?

Üblich sind vier bis sechs IC-Level. Dropbox nutzt IC1–IC7, Wise IC1–IC6, CircleCI E1–E6. Entscheidend ist nicht die Anzahl, sondern dass jede Stufe einen realen Unterschied im Scope hat. Kleinere Teams fahren mit vier Leveln (Junior, Mid, Senior, Staff) gut; mehr Stufen lohnen sich erst, wenn org-weiter und externer Impact differenziert werden muss.

Was ist der Unterschied zwischen IC-Track und Manager-Track?

Der IC-Track wächst über technische Tiefe, Scope und Einfluss durch Expertise. Der Manager-Track wächst über People Leadership, Team-Entwicklung und Prozesse. Ein L4 Staff Engineer und ein M2 Engineering Manager sind gleich senior, aber ihre Kompetenzgewichtung und Evidenz unterscheiden sich. Wichtig ist, dass beide Leitern gleichwertig vergütet werden.

Welche Evidenz sollte ein Engineer pro Bewertung liefern?

Belastbar sind PRs (Umsetzung), RFCs (Architektur), Postmortems (Reliability), Runbooks (On-Call) und Tech-Talks (Mentoring). Als Richtwert gelten zwei bis drei Items pro bewertetem Bereich aus den letzten sechs bis zwölf Monaten. Aussagen ohne Beleg zählen nicht.

Muss der Betriebsrat einer Engineering-Kompetenzmatrix zustimmen?

Wenn die Matrix als einheitlicher, unternehmensweiter Bewertungsstandard dient, ja: Nach § 94 Abs. 2 BetrVG hat der Betriebsrat ein Mitbestimmungsrecht bei allgemeinen Beurteilungsgrundsätzen. Beziehen Sie ihn früh ein, um die Einigungsstelle zu vermeiden.

Sollten KI-Coding-Skills in die Matrix?

Ja. KI-Tools gehören zum Engineering-Alltag, und Artikel 4 des EU AI Act verlangt seit Februar 2025 ein ausreichendes Maß an AI Literacy bei Betreibern von KI-Systemen. Eine Zeile „AI-Assisted Development“ mit Ankern (Output prüfen, Halluzinationen erkennen, Sicherheits-/Datenschutzrisiken bewerten) dokumentiert diese Kompetenz.

Fazit

Eine Engineering-Kompetenzmatrix wirkt erst, wenn sie ausgefüllt und engineering-nativ ist: sieben fachnahe Bereiche, vier Level mit beobachtbaren Ankern, eine echte IC-/Manager-Doppelleiter und Evidenz aus PRs, RFCs und Postmortems. Wer in DACH einführt, plant Betriebsrat (§ 94 BetrVG) und DSGVO von Anfang an mit ein. Den Prozess dahinter – Skala, Anker-Formulierung, Kalibrierung – vertieft der Guide zum Skill-Management; passende Tools vergleicht die Übersicht zur Skill-Management-Software 2025.