An engineering skills matrix defines, for each career level and competency, the observable behavior an engineer must show. This post skips the empty shell and gives you a filled-in template: 4 levels (Junior to Staff) × 7 engineering-specific areas with concrete anchors, an IC/manager dual ladder, and the EU compliance details (works council, GDPR, AI Act) that generic templates ignore.

We keep the generic build process — pick a scale, write anchors, calibrate — deliberately short and point to the ultimate guide to successful skill management for it. This article answers the one question most templates leave open: what actually goes into an engineering matrix — filled in, using the language engineers live in (PRs, RFCs, on-call, postmortems)?

Which competency families belong in an engineering matrix

A good matrix measures more than coding speed. The publicly documented leveling frameworks of large tech companies consistently span four to six dimensions. The Dropbox Engineering Career Framework uses Results, Direction, Talent, Culture and Craft; the CircleCI competency matrix uses Technical Skills, Quality & Testing, Debugging & Observability, Understanding Code, Communication and Leadership. From these you can derive seven areas that hold up for most software teams:

An engineering matrix should focus on these craft-adjacent areas. Generic soft skills (self-organization, broad communication) belong in a separate soft-skills matrix. How many areas make sense and how to phrase anchors is covered under skills and competency management — here we focus on the engineering content.

The filled-in IC matrix: 4 levels × 7 competency families

This is the core of the post. The matrix below shows, for each of the seven areas, what concretely changes from Junior (L1) through Mid (L2) and Senior (L3) to Staff (L4). The anchors follow publicly documented levels: in the Dropbox IC1 profile, a junior participates in on-call rotations and navigates unfamiliar codebases; in the Dropbox IC3 profile, an engineer responds with urgency to SEV incidents and establishes code-review best practices. In the Wise Engineering Career Map, an engineer takes a leading role in the post-incident process from IC3 onward.

Three principles make this matrix hold up. First: every anchor describes observable behavior, not traits — "runs the post-incident process," not "is responsible." Second: scope grows with the level, not just depth. The aggregated level framework from Levels.fyi frames this jump as a widening impact radius and increasing ability to handle ambiguity. Third: L4/Staff is defined as a multiplier, not a "super senior" — staff engineers are typically less than 10% of the engineering population, per Levels.fyi.

If you add L5/L6 (Principal, Distinguished), the scope shifts from "multiple teams" to "org-wide and external": the IC track runs to IC7 in the Dropbox framework and to IC6 in the Wise map. More levels only make sense if each step carries a real difference in scope — otherwise L6 exists only on paper.

IC track vs. manager track: the dual ladder

The most common leveling mistake is the false forcing function: engineers get pushed into management because it's the only visible way up. A clean matrix separates two equal ladders. CircleCI deliberately released its IC matrix first and announced a separate management matrix; Wise runs IC1–IC6 and an Engineering Lead track EL1–EL4 as parallel, equally valued tracks. In the Dropbox framework, the manager track runs from M3 to M7 alongside the IC track.

An L4/Staff and an M2/Engineering Manager are both senior — but the competency weighting and evidence differ:

Practical effect: once an IC track with real scope is visible, more engineers choose the technical path instead of moving into management for lack of an alternative. The key is that both ladders carry the same compensation logic — otherwise the dual ladder stays theoretical.

Evidence: how to actually recognize a level

An assessment is only as good as its proof. In engineering teams, evidence types are specific and easy to document:

As a rule of thumb, use two to three evidence items per assessed area from the last six to twelve months (as the Practica leveling framework recommends). "Good communicator" with no proof doesn't count; "wrote the RFC for the database migration that three teams adopted" does. Which rating scale (0–4 or 1–5) sits behind it, and how to calibrate across backend, frontend and platform, is covered in the skill management guide.

AI-assisted development as a new competency row

AI coding tools (GitHub Copilot, Cursor, LLM-assisted code generation) are reshaping day-to-day engineering — and they now carry regulatory weight too. Article 4 of the EU AI Act requires providers and deployers of AI systems to ensure a sufficient level of "AI literacy" among their staff. The obligation has applied since 2 February 2025. Teams using AI tools for code generation fall under it as "deployers" — and a competency matrix is a natural place to document that literacy.

Concretely, you can add "AI-Assisted Development" as an eighth row:

Legal & compliance: works council, GDPR, AI Act (Germany)

This layer is missing from virtually every international template — but in Germany it is mandatory.

Works council co-determination (§ 94 BetrVG)

If you introduce an engineering skills matrix as a uniform, company-wide assessment standard, co-determination applies. Section 94(2) of the German Works Constitution Act (BetrVG) gives the works council (Betriebsrat) an approval right over general assessment principles. An org-wide binding matrix standardizes performance assessment and falls under that term — under the settled case law of the German Federal Labour Court, co-determination also extends to the software that implements the assessment. If no agreement is reached, a conciliation board decides. Practical advice: involve the works council from the start rather than presenting a finished matrix for sign-off.

GDPR and § 26 BDSG for skill data

Skill ratings are personal employee data. Under Section 26(1) of the German Federal Data Protection Act (BDSG), skill data necessary for the employment relationship (such as the programming languages of a software engineer) may be processed without separate consent. Three points matter in practice (a thorough write-up is available from the German datenschutz-notizen on introducing a skill matrix):

Engineering-specific pitfalls

Frequently asked questions

What sets an engineering skills matrix apart from a generic skills matrix?

A generic matrix lists arbitrary competencies for arbitrary roles. An engineering matrix uses craft-adjacent areas (system design, code review, on-call/incident) and evidence types from daily engineering work (PRs, RFCs, postmortems). It also captures the IC/manager dual ladder common in technical organizations.

How many levels should an engineering career ladder have?

Four to six IC levels are common. Dropbox uses IC1–IC7, Wise IC1–IC6, CircleCI E1–E6. What matters is not the count but that each step carries a real difference in scope. Smaller teams do fine with four levels (Junior, Mid, Senior, Staff); more steps pay off only when org-wide and external impact need to be differentiated.

What is the difference between the IC track and the manager track?

The IC track grows through technical depth, scope and influence by expertise. The manager track grows through people leadership, team development and process. An L4 Staff Engineer and an M2 Engineering Manager are equally senior, but their competency weighting and evidence differ. The key is that both ladders are compensated equally.

What evidence should an engineer provide per rating?

Solid evidence includes PRs (execution), RFCs (architecture), postmortems (reliability), runbooks (on-call) and tech talks (mentoring). Aim for two to three items per assessed area from the last six to twelve months. Claims without proof don't count.

Does our works council (Germany: Betriebsrat) need to approve an engineering skills matrix?

If the matrix serves as a uniform, company-wide assessment standard, yes: under Section 94(2) BetrVG the works council has a co-determination right over general assessment principles. Involve them early to avoid a conciliation board.

Should AI coding skills be in the matrix?

Yes. AI tools are part of daily engineering, and Article 4 of the EU AI Act has required a sufficient level of AI literacy from deployers of AI systems since February 2025. A row for "AI-Assisted Development" with anchors (check output, spot hallucinations, assess security/privacy risk) documents that competency.

Conclusion

An engineering skills matrix only works when it's filled in and engineering-native: seven craft-adjacent areas, four levels with observable anchors, a real IC/manager dual ladder, and evidence from PRs, RFCs and postmortems. If you roll out in Germany, plan for the works council (§ 94 BetrVG) and GDPR from the start. The process behind it — scale, anchor phrasing, calibration — is covered in the skill management guide; for tooling, see the 2025 skill management software comparison.