Career framework / Software Engineer
Software Engineer Track

Software Engineer

Ships features, writes quality code, designs systems. Two tracks from L4+: Engineering Management or Individual Contributor (Principal Engineer / Distinguished Engineer).

5levels · 8competencies · Total weight 11.5 · Hire bar L3
The 5 SE levels
L1
Junior SE
Learning the stack. Ships small tasks with senior review.
1.0 – 1.8
L2
Middle SE
Ships features independently. Reviews L1 work.
1.9 – 2.7
L3
Senior SE
Owns a module. Designs at feature level. Mentors juniors.
2.8 – 3.6
L4
Tech Lead · 2 tracks
System design. Mgmt track (Tech Lead) or IC track (Principal Engineer).
3.7 – 4.4
L5
SA · capped seat
0–2 person seat. Solution Architect or Distinguished Engineer (IC).
4.5 – 5.0
Competency matrix — at a glance
Competency
W
L1
L2
L3
L4
L5
Technical Mastery
×2
2
3
4
5
5
Code Quality
×1.5
1
3
3
4
5
System Design
×1.5
1
2
3
4
5
AI Tools & Modern Eng
×1.5
1
2
3
4
4
Problem Solving
×1.5
1
2
3
4
5
Communication
×1.5
1
2
3
4
4
English Proficiency
×1
1
2
3
4
4
Mentoring & Tech Leadership
×1
1
2
3
4
4
1 Aware2 Developing3 Proficient · hire bar4 Senior5 Expert
Competency deep-dive
Technical Mastery
Weight ×2
L1
1
L2
2
L3 · hire bar
3
L4
4
L5
5
L1
Junior SE
Fresher or intern with under 1 year of professional coding experience. IT/SE degree or equivalent.
"I learn by doing. I ask for help when stuck."
Knows one programming language well enough to follow patterns. Can complete small, well-defined tasks given to them. Needs guidance on anything non-trivial.
Observable behaviors
  • 1Writes code that follows existing patterns in the codebase.
  • 2Completes well-scoped tasks (CRUD, small features) given clear instructions.
  • 3Asks the Tech Lead or L3 mentor when stuck (several times per day in the first 3 months).
  • 4Reads code more than writes it in the first 3 months.
  • 5Knows basic data structures and language syntax solidly.
  • 6Limited debugging — relies on stack traces and Google.
Expected outputs
  • Pull requests for small, well-defined tasks (CRUD endpoints, UI components).
  • Unit tests for own code (when explicitly required).
  • Daily report on work-in-progress.
  • Questions and notes documented to the mentor.
What you would see
In code review, the L1 PR shows correct logic but inconsistent with codebase patterns. The L3 reviewer comments on naming, style, and one missed edge case. The L1 fixes them and asks two follow-up questions.
Common traps
  • Does not ask for help and silently produces wrong work for a week.
  • Copy-pastes from Stack Overflow or AI without understanding why it works.
L2
Middle SE
3–5 years of professional engineering experience. Comfortable in one stack, picking up second.
"I own my features. I deliver the majority of the team work."
Independently delivers most features in the sprint. Understands the whole codebase at a structural level. Writes code others can read and maintain.
Observable behaviors
  • 1Independently delivers medium-complexity features (a full screen + backend + tests).
  • 2Reads and modifies code across the full stack of the project.
  • 3Debugs production issues using logs, traces, and step-through.
  • 4Refactors small areas of the code without supervision.
  • 5Reviews L1 code; gives constructive comments.
  • 6Comfortable with the team primary stack; can pick up a second framework in 2-4 weeks.
Expected outputs
  • Pull requests for medium-complexity features (most of the sprint stories).
  • Unit tests and integration tests for own work.
  • Code review comments on L1 PRs (5+ per week).
  • Bug fixes traced to root cause, not just symptom.
  • Daily and weekly reports.
What you would see
Given a new story, the L2 reads the AC, looks at the existing code, asks the BA one clarifying question, then ships a working PR within the sprint without check-ins.
Common traps
  • Comfortable on the rails — struggles when a problem requires deviating from the existing pattern.
  • Treats code review as a formality — accepts L1 PRs without challenging.
L3
Senior SE (the technical anchor)HIRE BAR
5–8 years of experience. Has delivered hard features, recovered hard bugs, mentored juniors.
"I deliver the hard parts. I guide the team. I represent the engineering quality of the team to the client."
Takes on the hardest technical work of the project. Designs solutions at the feature level. Mentors L1 and L2. Communicates directly with the client Tech Lead.
Observable behaviors
  • 1Delivers the hardest, most complex features (integrations, performance, security-sensitive).
  • 2Designs solutions at the feature level — picks the right libraries, patterns, data structures.
  • 3Reviews PRs from L1 and L2 — provides design-level feedback, not just style.
  • 4Pair-programs with L1 and L2 to teach, not just to deliver.
  • 5Owns at least one non-trivial subsystem end-to-end.
  • 6Engages directly with the client Tech Lead on technical decisions.
  • 7Spots architectural inconsistencies and proposes fixes.
Expected outputs
  • Pull requests for high-complexity features.
  • Technical design notes for medium-large features.
  • Code review feedback on L1 and L2 PRs (10+ per week with at least 3 design-level comments).
  • Bug investigation write-ups with root cause analysis.
  • Sprint and feature-level technical reports.
What you would see
When the team hits a complex production issue, the L3 drops into a debug session, identifies the root cause within hours (not days), and writes up the fix plan that the team executes.
Common traps
  • Becomes the bottleneck — every hard problem routes through them, juniors do not grow.
  • Refuses to delegate; takes on too much; quality dips from overload.
L4
Tech Lead
5–8+ years. Similar to L3 but at larger scope (ODC-wide or multi-project). Adds responsibility for engineering hiring, evaluation, and team capacity decisions.
"I am responsible for the team technical quality and growth — not just my own code."
Like L3 but with broader scope. Sets the technical direction for a sub-team or small ODC. Decides hiring and replacement. Evaluates L1-L3 engineers. Owns backlog control and sprint quality.
Observable behaviors
  • 1Sets the technical direction (stack choices, patterns, conventions) for the team or ODC.
  • 2Reviews and evaluates L1, L2, L3 engineers (formal performance assessment).
  • 3Participates in technical interviews; recommends hire or no-hire with rationale.
  • 4Recommends replacements when engineers are not performing or wrong-fit.
  • 5Owns backlog technical control — splits stories, sizes correctly, flags hidden risk.
  • 6Owns sprint quality gate — no PR ships without their or a designated reviewer approval.
  • 7Coaches L3 engineers toward becoming Tech Leads themselves.
  • 8Coordinates with multiple sub-team Tech Leads (cross-team patterns, shared infrastructure).
Expected outputs
  • Technical direction documents for the team (stack choices, key decisions).
  • Engineering performance assessments for L1, L2, L3 reports.
  • Hiring scorecards and recommendations.
  • Replacement recommendations with replacement plan.
  • Backlog technical reviews — sizing notes, splits, risk callouts.
  • Sprint quality reports.
  • Monthly engineering reports to ODC Lead.
What you would see
When a team member is underperforming, the L4 has already had structured 1:1s, set a 30-day improvement plan with the engineer, and brings a clear recommendation (improve / pip / replace) to the ODC Lead — not waiting for HR to ask.
Common traps
  • Loses individual contributor edge — stops coding entirely and becomes irrelevant on technical debates.
  • Overcorrects the other way — keeps coding so much that hiring, evaluation, and coaching get neglected.
L5
Solution Architect (SA)
8+ years experience. Master degree preferred. Architecture-level thinker who controls technology across an entire ODC department.
"I control the technology and architecture across all projects in the department. I think in systems, not in tickets."
Designs systems used across multiple ODCs. Consults on technology upgrades. Interviews and evaluates senior candidates. Leads presale technical conversations. Reports to the Delivery Manager.
Observable behaviors
  • 1Designs systems for one or more ODCs (architecture, integration patterns, NFRs).
  • 2Consults on partial or full system upgrades (migrations, modernizations).
  • 3Interviews and evaluates senior engineering candidates (L3+).
  • 4Owns presale technical conversations — proposes solutions, defends architecture choices to prospects.
  • 5Files quarterly reports on department technology health.
  • 6Contributes to department planning direction.
  • 7Joins specific projects when requested (selective deep-dive).
  • 8Syncs regularly with ODC Leads and Tech Leads (no formal reports but high coordination).
Expected outputs
  • Architecture documents for ODC systems.
  • Modernization and upgrade consultation reports.
  • Senior interview evaluations.
  • Presale technical proposals.
  • Quarterly department technology report.
  • Planning direction inputs.
What you would see
Called into a presale meeting with a Fortune-500 prospect. The SA listens to the client pain points for 20 minutes, asks 5 sharp questions, and sketches an architecture on the whiteboard that the client signs off on the same day.
Common traps
  • Becomes too theoretical — loses ground truth on what actually ships.
  • Imposes architecture choices on teams without buy-in.
Measurement matrix 4-of-6 majority
Dimension
L1 · Aware
L2 · Familiar
L3 · Proficient
L4 · Advanced
L5 · Expert
Language & stack
1 language basic. Syntax solid. Reads more than writes first 3 months.
1 language fluent. Type system, async, common patterns confident.
2+ languages fluent. Comfortable across multiple paradigms.
Sets stack choices, patterns, conventions for team/ODC.
Language/stack strategy across ODCs. Migrations + modernizations.
Frameworks
Follows tutorials + existing codebase patterns. Can run, not modify.
Fluent in 1 primary framework. Picks up 2nd in 2–4 weeks.
Multi-framework. Knows when (and when not) to use which.
Sets framework conventions + shared infrastructure across team.
Designs integration patterns + NFRs for cross-ODC systems.
Codebase fluency
Reads more than writes (first 3 months). Follows existing patterns.
Reads + modifies across full stack. Refactors small areas solo.
Owns subsystem end-to-end. Spots architectural inconsistencies.
Audits codebases across team. Reviews technical debt for ODC.
Consults on system upgrades — migrations, modernizations, integrations.
Debugging
Reads stack trace. Googles errors. Asks senior when stuck.
Debugs production using logs, traces, step-through debugger.
Root cause within hours (not days). Writes fix plan team executes.
Distributed system tracing. Race conditions, memory leaks, cross-service bugs.
NFR diagnosis (performance, scale, reliability) at architecture level.
Tooling
IDE basic features. Git commit/push/pull. AI assistant for syntax help.
Git workflow fluent (branch, rebase, merge). AI for boilerplate + tests.
Custom AI prompts + skills. Advanced refactoring. High tool productivity.
Curates team AI workflow (Skills + Constitution). Owns CI quality gates.
Sets D3 tooling/AI philosophy. AI workflow used as Techvify template.
CS & systems foundations
Knows arrays/maps/lists. Limited complexity awareness.
Big-O basics. Picks right DS for routine tasks. OS/network awareness.
Picks DS&A for novel problems. OS/network/DB internals fluent.
Reasons complexity at system level. DB internals deep. Mentors L3 on foundations.
Sets depth bar for unit. Reads RFCs/papers. Coaches L4 on systems thinking.
Anti-signal · auto-disqualifies the level
Rejects
Copy-pastes from Stack Overflow or AI without understanding.
Treats code review as formality. Accepts L1 PRs without challenge.
Bottleneck — every hard problem routes through them. Juniors don't grow.
Stops coding entirely. Loses IC edge, irrelevant in technical debates.
Too theoretical. Imposes architecture without team buy-in.
Scoring rule: You are at Level N if you hit Level N in at least 4 of 6 dimensions, AND no dimension is below Level (N−1). Sort dimension levels descending — the 4th value is your overall level. If the lowest dimension drops more than 1 below that value, demote 1 level.
Code Quality & Engineering Discipline
Weight ×1.5
L1
1
L2
2
L3 · hire bar
3
L4
4
L5
5
L1
Junior SE
Learning quality habits.
"Quality is what passes review."
Writes unit tests when explicitly required. Follows the team style guide. Quality is whatever the reviewer says it is.
Observable behaviors
  • 1Writes unit tests for own code when asked.
  • 2Follows team coding conventions (with reminders).
  • 3Fixes review comments on second or third try.
  • 4Does not yet think about edge cases proactively.
Expected outputs
  • Unit tests for own features.
  • Code that passes review (eventually).
What you would see
PR ships with 60% test coverage on the new code. Reviewer flags 2 missing edge cases — L1 adds them.
Common traps
  • Treats tests as a checkbox, not a safety net.
  • Believes “it works on my machine” is enough.
L2
Middle SE
Quality habits forming.
"I test as I write. I review my own PR before requesting review."
Writes unit and integration tests as part of the work, not after. Self-reviews every PR before submitting. Defects on their code are rare.
Observable behaviors
  • 1Writes unit and integration tests as part of the feature, not bolted on after.
  • 2Self-reviews own PR before requesting reviewers.
  • 3Achieves 80%+ test coverage on new code by default.
  • 4Catches their own bugs in self-review (visible from squashed commits).
  • 5Reviews L1 PRs for both correctness and style.
Expected outputs
  • Unit and integration tests with each PR.
  • Self-review comments on own PRs (proof of discipline).
  • Reviews of L1 PRs (multiple per week).
What you would see
PR has 85% test coverage, the author has self-reviewed and left two comments fixing minor issues before requesting review.
Common traps
  • Reviews L1 code superficially (typo-spotting only).
  • Skips integration tests when time is tight.
L3
Senior SEHIRE BAR
Quality steward for the team.
"Quality is engineered into the design, not added at the end."
Drives the team quality bar. Writes test strategies, not just tests. Reviews PRs at design level. Owns defect investigation.
Observable behaviors
  • 1Designs the test strategy for a new feature (unit / integration / e2e mix).
  • 2Reviews PRs at design level — catches over-engineering, missed abstractions, hidden coupling.
  • 3Investigates production defects to root cause; writes postmortem.
  • 4Maintains the team quality gates (definition of done, CI requirements).
  • 5Refactors aggressively when seeing tech debt.
Expected outputs
  • Test strategy documents for major features.
  • Design-level review feedback on L1 and L2 PRs.
  • Postmortem documents for production defects.
  • Refactoring PRs that reduce code complexity (visible in metrics).
What you would see
After a production incident, the L3 produces a 2-page postmortem within 48 hours: timeline, root cause, fix, prevention measures, and a follow-up PR adding a test to prevent regression.
Common traps
  • Quality religion — refactors at the expense of shipping.
  • Reviews become so deep that PRs sit waiting for days.
L4
Tech Lead
Quality culture owner.
"The team quality is mine. I set the bar and the standards."
Defines the team engineering standards. Owns the CI/CD pipeline quality gates. Measures and reports defect trends. Coaches L3s on quality leadership.
Observable behaviors
  • 1Defines engineering standards (code style, review checklist, definition of done, CI gates).
  • 2Owns the CI/CD pipeline quality (test coverage thresholds, security scans, deployment gates).
  • 3Tracks and reports defect escape rate, MTTR, deploy frequency.
  • 4Coaches L3 engineers on quality leadership.
  • 5Drives quality improvement initiatives (testing automation, observability, SRE practices).
Expected outputs
  • Engineering standards documents.
  • Quality dashboard (defect escape rate, MTTR, coverage trends).
  • Quality improvement RFCs.
  • Coaching notes for L3 engineers.
What you would see
Monthly engineering report shows defect escape rate trending down for 3 months because the L4 introduced contract testing for the most-failed integration.
Common traps
  • Standards become bureaucracy — team slows down.
  • Quality dashboard becomes a vanity exercise without action.
L5
Solution Architect
Quality at the architecture and department level.
"Quality is a property of the system design, the team capability, and the operational practices combined."
Sets quality standards at the department level. Designs systems with quality built in (testability, observability, NFR baselines).
Observable behaviors
  • 1Sets department-wide engineering standards.
  • 2Designs systems with testability, observability, and NFR baselines.
  • 3Reviews architecture proposals from L4s for quality and resilience.
  • 4Brings industry quality practices (SRE, chaos engineering, etc.) into the department.
Expected outputs
  • Department engineering standards.
  • System architecture reviews focused on quality.
  • Quality practice proposals.
What you would see
Designs the new payments service with explicit MTTR and availability SLOs baked into the architecture document, with a test strategy aligned to the SLOs.
Common traps
  • Quality theater — beautiful standards, no operational reality check.
Measurement matrix 3-of-5 majority
Dimension
L1 · Aware
L2 · Familiar
L3 · Proficient
L4 · Advanced
L5 · Expert
Testing discipline
Writes unit tests when asked. Coverage ~60% on new code.
Tests as part of feature, not bolted on. 80%+ coverage by default.
Designs test strategy (unit/integration/e2e mix). Picks test type for risk.
Sets coverage thresholds. Owns CI test gates + automation infra.
Designs systems with testability built-in. NFR-aligned strategy at department level.
Review discipline
Fixes review comments on 2nd–3rd try. No self-review yet.
Self-reviews PR before requesting. Reviews L1 PRs for correctness + style.
Reviews at design level — catches over-engineering, missed abstractions, coupling.
Sets review checklist. Coaches L3 on design-level reviewing.
Reviews L4 architecture proposals for quality + resilience.
Defect & root cause
Fixes bugs flagged by reviewer or QA. No RCA capability yet.
Catches own bugs in self-review. Fixes defects with regression test.
Investigates production defects to root cause. 2-page postmortem within 48h.
Tracks defect escape rate + MTTR. Drives systemic fix initiatives.
Sets resilience standards at architecture level. Brings SRE + chaos eng practices.
Tech debt mgmt
Adds to tech debt unknowingly. Cannot identify it independently.
Refactors small areas during own feature work without supervision.
Refactors aggressively for tech debt. Files PRs that reduce complexity (measurable).
Maintains team tech debt backlog. Allocates sprint capacity for systematic reduction.
Drives modernization across department. Migrates legacy systems.
Standards & gates
Follows team conventions with reminders. Does not challenge them yet.
Internalizes team standards. Applies them without reminders.
Maintains team quality gates — DoD, CI requirements, Definition of Ready.
Defines engineering standards: style, review checklist, DoD, CI gates, security scans.
Sets department-wide standards. Aligns with industry best practices.
Anti-signal · auto-disqualifies the level
Rejects
Tests as checkbox not safety net · 'works on my machine' mindset.
Superficial L1 reviews (typos only) · skips integration tests when busy.
Quality religion — refactors at expense of shipping · reviews so deep PRs sit for days.
Standards become bureaucracy · quality dashboard becomes vanity exercise.
Quality theater — beautiful standards, no operational reality check.
Scoring rule: You are at Level N if you hit Level N in at least 3 of 5 dimensions, AND no dimension is below Level (N−1). Sort dimension levels descending — the 3rd value is your overall level. If the lowest dimension drops more than 1 below that value, demote 1 level.
System Design & Architecture
Weight ×1.5
L1
1
L2
2
L3 · hire bar
3
L4
4
L5
5
L1
Junior SE
Learning to read existing architecture.
"Architecture is what the senior engineers decided."
Reads architecture diagrams. Understands what each component does at a name level. Does not yet design.
Observable behaviors
  • 1Reads existing architecture diagrams and follows them.
  • 2Knows what each major component in the system does.
  • 3Asks before changing anything beyond their feature.
Expected outputs
  • Code that fits within the existing architecture.
What you would see
Asked to add a new API endpoint, L1 finds the right service, copies the pattern, and ships.
Common traps
  • Treats architecture as someone else's job; does not try to understand it.
L2
Middle SE
Comfortable navigating, starting to design at feature level.
"I design within a feature. I follow the bigger pattern."
Designs feature-level architecture (class structure, module boundaries, data flow within a feature). Understands NFR concepts.
Observable behaviors
  • 1Designs class structure and module boundaries for a feature.
  • 2Discusses feasibility and approach with L3 before writing.
  • 3Understands NFRs (performance, security, scalability) at a conceptual level.
  • 4Reads architecture decision records (ADRs) for context.
Expected outputs
  • Feature-level design notes (a paragraph or a diagram).
  • Approach proposals reviewed by L3 before coding.
What you would see
Before starting a 1-week feature, L2 writes a half-page design note and gets a sanity check from L3.
Common traps
  • Over-designs small features.
  • Or skips design and refactors twice.
L3
Senior SEHIRE BAR
Module-level architect.
"I design systems at module and service level. I think about coupling, testability, evolution."
Designs modules and small services. Picks the right patterns. Considers evolution and operability.
Observable behaviors
  • 1Designs new modules and small services end-to-end.
  • 2Picks appropriate patterns (events, queues, sync vs async, stateful vs stateless).
  • 3Considers evolution — how will this change in 12 months?
  • 4Writes architecture decision records (ADRs) for non-trivial choices.
  • 5Reviews L2 designs and gives feedback.
Expected outputs
  • Module and service design documents.
  • ADRs for non-trivial decisions.
  • Reviews of L2 designs.
What you would see
When asked to add a new feature that touches 3 services, L3 produces a sequence diagram + ADR identifying the trade-off between consistency and latency, recommends the option, and the team executes.
Common traps
  • Over-applies favorite patterns (everything becomes microservices).
  • Does not validate design with the team — gets pushback late.
L4
Tech Lead
System-level architect for the ODC.
"I own the technical direction for this ODC or sub-team. Cross-component decisions are mine."
Designs at system level for a sub-team or ODC. Cross-cuts services and components. Drives architecture evolution.
Observable behaviors
  • 1Designs system-level architecture (multiple services + data flow + deployment).
  • 2Cross-component decisions (consistency, eventual consistency, transaction boundaries).
  • 3Drives architecture evolution — what is being deprecated, what is new, why.
  • 4Coordinates with other Tech Leads on shared infrastructure.
  • 5Reviews L3 architecture proposals and challenges constructively.
Expected outputs
  • System architecture documents.
  • Architecture evolution roadmap.
  • Cross-team coordination notes on shared platforms.
What you would see
When the team needs to add multi-region support, L4 produces a 4-page system design covering data replication, failover, observability, and cost — with two options and a recommendation.
Common traps
  • Architecture astronaut — designs for problems the team does not have.
  • Does not update designs when reality diverges.
L5
Solution Architect
Cross-ODC architect.
"I design systems used across the department. Architecture is a strategic lever, not a technical detail."
Designs at department level. Cross-ODC patterns, shared services, technology choices. Influences department strategy through architecture.
Observable behaviors
  • 1Designs systems and reference architectures used across ODCs.
  • 2Defines shared services (auth, observability, data platform) for the department.
  • 3Sets technology standards (allowed languages, frameworks, cloud services).
  • 4Consults on architecture decisions for major projects across the department.
  • 5Drives technology modernization strategy (e.g., move from monolith to services, AI integration).
Expected outputs
  • Reference architectures for the department.
  • Shared service designs.
  • Technology standard documents.
  • Modernization roadmaps.
What you would see
Designs the department reference architecture for new AI-integrated systems and gets buy-in from 4 ODC Leads and the Delivery Manager within 6 weeks.
Common traps
  • Standards become dogma; ODCs lose flexibility.
  • Reference architecture does not match actual system needs.
Measurement matrix 3-of-5 majority
Dimension
L1 · Aware
L2 · Familiar
L3 · Proficient
L4 · Advanced
L5 · Expert
Scope of design
Reads diagrams · follows existing architecture · does not design.
Designs feature-level class structure and module boundaries.
Designs new modules and small services end-to-end.
Designs system-level architecture across services for an ODC.
Designs reference architectures used across multiple ODCs.
Pattern selection
Copies the pattern next door · does not yet choose.
Follows the bigger pattern · checks approach with L3.
Picks events vs queues, sync vs async, stateful vs stateless.
Cross-component decisions on consistency + transaction boundaries.
Sets allowed languages, frameworks, cloud services for the department.
NFR awareness
Knows components by name · does not reason about NFRs.
Understands performance, security, scalability at conceptual level.
Considers operability + 12-month evolution of the design.
Handles multi-region, failover, observability, cost trade-offs.
Defines shared services (auth, observability, data platform).
ADR & documentation
None · just code that fits.
Half-page feature design note before a 1-week feature.
Writes ADRs for non-trivial choices · sequence diagrams.
System architecture docs · evolution roadmap · cross-team coordination notes.
Reference architectures · technology standards · modernization roadmaps.
Design review & evolution
Asks before changing anything beyond own feature.
Reads ADRs for context · gets sanity check from L3.
Reviews L2 designs and gives feedback.
Reviews L3 proposals · drives what is deprecated and what is new.
Consults on architecture for major projects across the department.
Anti-signal · auto-disqualifies the level
Rejects
Treats architecture as someone else's job; does not try to understand it.
Over-designs small features. Or skips design and refactors twice.
Over-applies favorite patterns (everything becomes microservices). Validates design too late.
Architecture astronaut — designs for problems the team does not have.
Standards become dogma; ODCs lose flexibility.
Scoring rule: You are at Level N if you hit Level N in at least 3 of 5 dimensions, AND no dimension is below Level (N−1). Sort dimension levels descending — the 3rd value is your overall level. If the lowest dimension drops more than 1 below that value, demote 1 level.
AI Tools & Modern Engineering
Weight ×1.5
L1
1
L2
2
L3 · hire bar
3
L4
4
L5
5
L1
Junior SE
Uses AI heavily but does not yet review the output critically.
"AI writes code for me. I check if it runs."
Uses AI tools extensively to generate code — the bulk of L1 productivity comes from this. But often accepts AI output without deeply understanding why.
Observable behaviors
  • 1Uses GitHub Copilot or Claude Code for the majority of code generation.
  • 2Accepts AI suggestions and tests if the code runs.
  • 3Does not yet have strong AI-review skills.
  • 4Sometimes commits AI-generated code that is verbose or non-idiomatic.
Expected outputs
  • AI-generated code that passes basic tests.
What you would see
PR has a 200-line function generated by AI when the team's idiomatic pattern would use 50 lines. L3 reviewer flags it.
Common traps
  • Trusts AI output without critical review.
  • Generates code that works but does not match the codebase style.
L2
Middle SE
Uses AI heavily and reviews output critically.
"AI is a fast junior pair-programmer. I direct it and review its output."
Uses AI for the bulk of routine code. Has strong review skills — catches AI mistakes, hallucinations, and over-engineering before committing.
Observable behaviors
  • 1Uses AI for generation but reviews critically before commit.
  • 2Catches AI hallucinations (functions that do not exist, wrong API signatures).
  • 3Uses AI for boilerplate, tests, refactoring — not for design decisions.
  • 4Crafts good prompts (specifies constraints, context, desired output format).
Expected outputs
  • AI-assisted code that matches the codebase style.
  • Self-correcting prompts when first output is wrong.
What you would see
L2 asks AI to write a function, scans the output, notices a missed edge case in the AI's logic, asks AI to revise with the edge case in mind, then ships.
Common traps
  • Over-relies on AI for things AI is bad at (architecture, debugging complex issues).
  • Spends time fixing AI output that would have been faster to write by hand.
L3
Senior SEHIRE BAR
Uses AI for design and review, not just generation.
"AI helps me think — I use it to challenge my designs, generate test cases, and review my own code."
Uses AI not just to generate code but to design solutions at the functional level and review the team's code.
Observable behaviors
  • 1Uses AI to explore design alternatives before coding.
  • 2Uses AI to generate edge cases and test scenarios.
  • 3Uses AI to review own code and team PRs.
  • 4Coaches L1 and L2 on effective AI usage (prompt patterns, review discipline).
  • 5Knows the limits of AI — when not to use it.
Expected outputs
  • AI-assisted design explorations.
  • AI-generated test scenarios for own and others' code.
  • AI-assisted code reviews with high-quality feedback.
What you would see
Before designing a new module, L3 asks Claude: "here is the requirement; give me 3 architectural options with trade-offs." Picks one, refines with team, then proceeds.
Common traps
  • Becomes dependent on AI for thinking; original ideas atrophy.
L4
Tech Lead
Uses AI across the entire software production pipeline.
"AI is part of the team. I control how it is used, how much it costs, and what it produces."
Uses AI across the full pipeline — design, code, review, testing, documentation. Controls AI costs (token usage). Sets team AI standards.
Observable behaviors
  • 1Uses AI tools across all stages: design, code, review, test, docs.
  • 2Tracks and controls AI cost (token usage, subscription cost) per project.
  • 3Sets team standards for AI usage — when to use, what prompts work, what to never trust.
  • 4Reviews team AI-generated PRs for over-reliance or quality issues.
  • 5Evaluates new AI tools and recommends adoption.
Expected outputs
  • Team AI usage standards.
  • AI cost reports per project.
  • AI tool evaluations and recommendations.
What you would see
Monthly engineering report includes AI cost per developer, AI-assisted PR rate, and an item like “moved test generation from Cursor to local Claude Code, saved $200/month, same quality.”
Common traps
  • Lets AI cost run unchecked.
  • Mandates AI usage to a degree that creates resentment in the team.
L5
Solution Architect
AI strategy at the department level.
"AI is changing how software is built. I lead how the department adapts."
Like L4 but at the department level. Researches new AI capabilities. Guides team adoption. Influences hiring profile and training.
Observable behaviors
  • 1Researches new AI tools and capabilities as they emerge.
  • 2Guides department adoption of new tools.
  • 3Trains other engineers on advanced AI usage.
  • 4Influences hiring profile — what AI skills do we look for at each level?
  • 5Shapes department-level AI cost strategy.
Expected outputs
  • Department AI strategy.
  • Training materials on new AI tools.
  • Hiring profile updates reflecting AI requirements.
What you would see
Hosts a monthly internal session: "what is new in AI engineering this month" — demonstrates a new capability, recommends adoption or pass.
Common traps
  • Chases every new AI tool — burns team time on experimentation.
Measurement matrix 3-of-5 majority
Dimension
L1 · Aware
L2 · Familiar
L3 · Proficient
L4 · Advanced
L5 · Expert
AI for code generation
Uses Copilot/Claude Code for majority of code generation.
Uses AI for boilerplate, tests, refactoring · crafts good prompts.
Uses AI across coding workflow with high prompt fluency.
Uses AI across all stages: design, code, review, test, docs.
Demonstrates new AI capabilities to the department monthly.
AI output review
Accepts AI suggestions if code runs · weak review skills.
Catches AI hallucinations · spots wrong API signatures before commit.
Knows the limits of AI — when not to use it.
Reviews team AI-generated PRs for over-reliance + quality issues.
Defines what 'good AI usage' looks like at each level.
AI for design & test
Does not use AI for design — just generation.
Uses AI for boilerplate, not for design decisions.
Uses AI to explore design alternatives · generate edge cases · review own code.
Sets team-wide AI prompt patterns for design and review.
Trains other engineers on advanced AI usage.
Cost & standards governance
None · just uses the tool the team gave them.
None — focus is on individual prompt craft.
Coaches L1/L2 on prompt patterns and review discipline.
Tracks token cost per project · sets team AI standards.
Shapes department-level AI cost strategy and hiring profile.
Tool evaluation & strategy
Uses whatever the team uses.
Switches between tools as task demands.
Recommends prompt patterns to peers.
Evaluates new AI tools · recommends adoption with cost data.
Researches emerging AI capabilities · guides department adoption.
Anti-signal · auto-disqualifies the level
Rejects
Trusts AI output without critical review. Code works but does not match codebase style.
Over-relies on AI for things AI is bad at (architecture, complex debugging).
Becomes dependent on AI for thinking; original ideas atrophy.
Lets AI cost run unchecked · mandates AI usage to a degree that creates resentment.
Chases every new AI tool — burns team time on experimentation.
Scoring rule: You are at Level N if you hit Level N in at least 3 of 5 dimensions, AND no dimension is below Level (N−1). Sort dimension levels descending — the 3rd value is your overall level. If the lowest dimension drops more than 1 below that value, demote 1 level.
Problem Solving & Complexity
Weight ×1.5
L1
1
L2
2
L3 · hire bar
3
L4
4
L5
5
L1
Junior SE
Solves problems with clear processes.
"There is a process; I follow it."
Handles problems with clear procedures. When asked something off-process, asks for guidance.
Observable behaviors
  • 1Follows clear processes — "here is how we handle this kind of bug."
  • 2Asks the L3 mentor when the problem does not fit any process.
  • 3Limited problem decomposition — sees problem as one big thing.
Expected outputs
  • Process-following solutions.
What you would see
When the build is broken in CI, L1 looks for similar past failures, finds the doc, follows the steps.
Common traps
  • Stalls when no clear process exists; does not try to figure it out.
L2
Middle SE
Judges which process applies.
"There are multiple approaches; I pick the right one."
Recognizes that a problem can be solved several ways and chooses one. Decomposes medium-complex problems.
Observable behaviors
  • 1Recognizes that multiple approaches exist for the same problem.
  • 2Picks the most appropriate approach based on context.
  • 3Decomposes medium-complex problems into subtasks.
  • 4Researches solutions independently (docs, blog posts, Stack Overflow, AI).
Expected outputs
  • Working solutions with brief rationale for the approach.
What you would see
Given a performance problem, L2 considers caching, indexing, query optimization, then picks one based on the data access pattern and runs an experiment.
Common traps
  • Picks the first plausible solution; does not weigh alternatives.
L3
Senior SEHIRE BAR
Handles ambiguous, multi-faceted problems.
"Most real problems are ambiguous. I analyze before I act."
Handles ambiguous problems where the path is not clear. Decomposes complex problems into solvable parts. Identifies the actual question to answer.
Observable behaviors
  • 1Handles ambiguous problems — talks to stakeholders to clarify before acting.
  • 2Identifies the actual question vs the surface question.
  • 3Decomposes complex problems systematically.
  • 4Runs experiments to validate assumptions before committing to a solution.
  • 5Spots hidden complexity early (e.g., "this looks like 1 sprint but the data migration is 3 sprints").
Expected outputs
  • Problem decomposition documents.
  • Experiment plans with hypothesis and results.
  • Estimates that account for hidden complexity.
What you would see
Given a vague client request like "make the app faster," L3 instruments first to find the actual bottleneck, identifies 3 candidate fixes, presents trade-offs, and the team picks one.
Common traps
  • Over-analyzes — paralysis by analysis.
L4
Tech Lead
Handles complex, multi-team, multi-system problems.
"I orchestrate problem-solving across teams and systems."
Handles problems spanning multiple teams, services, or domains. Coordinates cross-team solutions.
Observable behaviors
  • 1Handles problems that span multiple teams, services, or domains.
  • 2Orchestrates cross-team problem solving (joint debugging sessions, shared task forces).
  • 3Identifies systemic issues vs one-off issues.
  • 4Mentors L3s on complex problem decomposition.
  • 5Brings in outside expertise (other Tech Leads, SAs) when domain calls for it.
Expected outputs
  • Cross-team problem-solving plans.
  • Systemic issue write-ups with proposed fixes.
  • Coaching notes on complex problem-solving.
What you would see
When 3 services in the system are sporadically failing, L4 sets up a joint debugging session with the 3 service owners, captures the shared root cause (a downstream dependency timing out), and drives the fix across all 3 services.
Common traps
  • Tries to solve cross-team problems alone instead of coordinating.
L5
Solution Architect
Handles strategic problems with department-wide impact.
"I solve problems at the level where one good decision saves the department a year of work."
Handles strategic problems — technology choices, system rewrites, capability builds. Decisions impact the whole department.
Observable behaviors
  • 1Handles problems at strategic level (build vs buy, monolith vs services, cloud strategy).
  • 2Frames problems for executive-level decisions.
  • 3Considers second-order effects (talent, hiring, training, ecosystem).
  • 4Drives consensus across multiple stakeholders.
Expected outputs
  • Strategic decision documents with options, trade-offs, recommendation.
  • Cross-stakeholder alignment notes.
What you would see
When the department considers migrating from on-prem to cloud, L5 writes a 6-page analysis covering cost, talent, risk, and timeline, presents to Delivery Manager, and gets a decision in 2 meetings.
Common traps
  • Strategic decisions drift without enforcement.
Measurement matrix 3-of-5 majority
Dimension
L1 · Aware
L2 · Familiar
L3 · Proficient
L4 · Advanced
L5 · Expert
Ambiguity handling
Stalls when no clear process exists · asks mentor.
Recognizes multiple approaches exist for the same problem.
Talks to stakeholders to clarify before acting · identifies actual vs surface question.
Identifies systemic issues vs one-off issues across domains.
Frames problems for executive-level decisions.
Problem decomposition
Sees problem as one big thing · limited decomposition.
Decomposes medium-complex problems into subtasks.
Decomposes complex problems systematically · spots hidden complexity.
Mentors L3s on complex problem decomposition.
Considers second-order effects (talent, hiring, training, ecosystem).
Approach selection
Follows the documented process for that bug class.
Picks the most appropriate approach based on context.
Presents 3 candidate fixes with trade-offs to the team.
Brings in outside Tech Leads or SAs when domain calls for it.
Build vs buy, monolith vs services, cloud strategy decisions.
Experimentation & validation
None · follows the steps.
Researches solutions independently (docs, SO, AI).
Runs experiments to validate assumptions before committing.
Sets up joint debugging sessions across service owners.
Writes multi-page analyses covering cost, talent, risk, timeline.
Scope of impact
One bug at a time within own feature.
Single medium-complex feature.
Ambiguous problems within own module or service.
Problems spanning multiple teams, services, or domains.
Strategic problems with department-wide impact.
Anti-signal · auto-disqualifies the level
Rejects
Stalls when no clear process exists; does not try to figure it out.
Picks the first plausible solution; does not weigh alternatives.
Over-analyzes — paralysis by analysis.
Tries to solve cross-team problems alone instead of coordinating.
Strategic decisions drift without enforcement.
Scoring rule: You are at Level N if you hit Level N in at least 3 of 5 dimensions, AND no dimension is below Level (N−1). Sort dimension levels descending — the 3rd value is your overall level. If the lowest dimension drops more than 1 below that value, demote 1 level.
Communication & Collaboration
Weight ×1.5
L1
1
L2
2
L3 · hire bar
3
L4
4
L5
5
L1
Junior SE
Communicates mostly within the team (90%).
"I ask for what I need and report what I did."
Basic communication. Asks for information, provides updates, mostly within own team.
Observable behaviors
  • 1Daily report on work-in-progress to the team.
  • 2Asks the mentor or L3 when stuck.
  • 3Participates in standup; speaks when called on.
  • 4Limited interaction with partner devs (around 10% time).
Expected outputs
  • Daily and weekly reports.
  • Clarifying questions to mentor.
What you would see
In standup, L1 reports yesterday/today/blockers in 30 seconds. Asks one question in Slack per day.
Common traps
  • Stays silent when stuck for too long.
L2
Middle SE
Communicates within team (50%) and with partner devs (50%).
"I work with partner devs daily. I keep the team informed."
Comfortable in cross-team and partner conversations. Writes clear emails and PR descriptions.
Observable behaviors
  • 1Engages with partner devs daily (Slack, PR reviews, standups).
  • 2Writes clear PR descriptions explaining what changed and why.
  • 3Participates actively in design discussions.
  • 4Asks clarifying questions on requirements with BA.
  • 5Daily and weekly reports include context, not just task list.
Expected outputs
  • Clear PR descriptions.
  • Cross-team Slack discussions.
  • Design discussion contributions.
What you would see
When the partner dev posts a vague API spec, L2 responds with 3 specific clarifying questions and proposes a struct that fits both sides.
Common traps
  • Tone-deaf in writing — comes across blunt to international partners.
L3
Senior SEHIRE BAR
Communicates with team (50%), cross-team (20%), and partner devs (30%).
"I influence technical decisions through clear logic and data, not just preference."
Persuades with logic and data. Communicates technical decisions to non-engineers. Engages directly with client Tech Lead.
Observable behaviors
  • 1Persuades technical decisions using data, not opinion.
  • 2Communicates technical trade-offs to BA, PM, client.
  • 3Runs technical discussions with the client Tech Lead.
  • 4Writes design docs that get adopted.
  • 5Gives structured PR review feedback (not just nitpicks).
  • 6Active in cross-team architecture discussions.
Expected outputs
  • Design documents adopted by the team.
  • Technical briefings to non-engineering stakeholders.
  • Structured PR review feedback.
What you would see
In a 4-way discussion (client Tech Lead, our Tech Lead, BA, L3), the L3 frames a contentious technical decision with data, proposes 2 options, and gets alignment in 30 minutes.
Common traps
  • Wins arguments but loses relationships.
L4
Tech Lead
Communicates with team (20%), cross-team (30%), other departments (20%), partner managers (30%).
"Most of my day is alignment work. I broker decisions across teams."
Brokers technical alignment across multiple teams and departments. Negotiates with partner managers. Drives consensus.
Observable behaviors
  • 1Coordinates with multiple sub-team Tech Leads.
  • 2Negotiates with partner manager on technical scope and timeline.
  • 3Drives technical consensus across teams.
  • 4Communicates with non-technical stakeholders effectively.
  • 5Mentors L3s on stakeholder communication.
Expected outputs
  • Cross-team alignment notes.
  • Negotiation outcomes with partners.
  • Stakeholder briefings.
What you would see
When 2 sub-teams disagree on a shared API design, L4 runs a 1-hour resolution session, captures the decision in writing, and both teams execute.
Common traps
  • Becomes a meeting machine; loses time to think.
L5
Solution Architect
Communicates across department (25% in-dept, 25% other-dept, 50% partners and new opportunities).
"I represent the technology of the department to the outside world."
Represents the department externally — to partners, prospects, and other departments. Influences strategy through communication.
Observable behaviors
  • 1Represents the department to prospects in presales.
  • 2Communicates technology direction to other departments.
  • 3Negotiates with partners on technology strategy.
  • 4Speaks at internal and external events.
Expected outputs
  • Presales technical proposals.
  • Technology direction briefings.
  • External-facing talks and writing.
What you would see
In a 3-way conversation between the client CTO, Delivery Manager, and the SA, the SA mediates a hard architecture trade-off with neither side feeling overruled.
Common traps
  • Loses contact with engineers; becomes a salesperson.
Measurement matrix 3-of-5 majority
Dimension
L1 · Aware
L2 · Familiar
L3 · Proficient
L4 · Advanced
L5 · Expert
Audience reach
90% within team · limited partner-dev interaction (~10%).
50% team · 50% partner devs daily.
50% team · 20% cross-team · 30% partner devs.
20% team · 30% cross-team · 20% other depts · 30% partner managers.
25% in-dept · 25% other-dept · 50% partners and new opportunities.
Written communication
Daily/weekly reports · clarifying questions to mentor.
Clear PR descriptions explaining what changed and why · context-rich reports.
Design docs that get adopted · structured PR review feedback.
Cross-team alignment notes · stakeholder briefings.
Presales technical proposals · external-facing talks and writing.
Technical persuasion
Asks for what they need · reports what they did.
Active in design discussions · proposes structures that fit both sides.
Persuades technical decisions using data, not opinion.
Drives technical consensus across multiple teams.
Mediates hard architecture trade-offs without either side feeling overruled.
Stakeholder & negotiation
Speaks when called on in standup.
Asks clarifying questions on requirements with BA.
Communicates trade-offs to BA, PM, client · runs discussions with client Tech Lead.
Negotiates technical scope + timeline with partner managers.
Negotiates technology strategy with partners · represents dept to prospects.
Meeting & forum facilitation
Participates in standup · reports yes/today/blockers in 30 sec.
Engages in cross-team Slack and PR review threads.
Frames contentious decisions and gets alignment in 30 min.
Runs 1-hour resolution sessions between disagreeing sub-teams.
Chairs steering committees and external presentations.
Anti-signal · auto-disqualifies the level
Rejects
Stays silent when stuck for too long.
Tone-deaf in writing — comes across blunt to international partners.
Wins arguments but loses relationships.
Becomes a meeting machine; loses time to think.
Loses contact with engineers; becomes a salesperson.
Scoring rule: You are at Level N if you hit Level N in at least 3 of 5 dimensions, AND no dimension is below Level (N−1). Sort dimension levels descending — the 3rd value is your overall level. If the lowest dimension drops more than 1 below that value, demote 1 level.
English Proficiency
Weight ×1
L1
1
L2
2
L3 · hire bar
3
L4
4
L5
5
L1
Junior SE
CEFR B1 (intermediate): can write emails, internal reports, attend internal meetings.
"I write what I need to write. Speaking is harder."
Can read technical docs in English. Writes basic emails, internal reports. Internal meetings OK; client meetings supervised.
Observable behaviors
  • 1Reads technical documentation in English.
  • 2Writes basic emails and reports.
  • 3Attends internal meetings in English.
  • 4May not yet handle direct client conversation.
Expected outputs
  • English-language daily/weekly reports.
  • Basic English code comments and PR descriptions.
What you would see
L1 writes a report with mostly correct grammar but occasional awkward phrasing.
Common traps
  • Avoids English speaking entirely; misses learning opportunities.
L2
Middle SE
CEFR B2 (upper intermediate): can converse frequently with clients and stakeholders.
"I can talk to partner devs daily without help."
Comfortable in daily English conversations with partner devs and stakeholders. Writes clear technical communication.
Observable behaviors
  • 1Daily English conversations with partner devs.
  • 2Writes clear PR descriptions, design notes, emails.
  • 3Asks and answers questions in client standups.
Expected outputs
  • Clear English written communication.
  • Confident verbal communication on technical topics.
What you would see
L2 in a client standup explains a bug fix in 30 seconds in clear English.
Common traps
  • Comfortable on technical topics, struggles when conversation goes personal or strategic.
L3
Senior SEHIRE BAR
CEFR B2 to C1 (upper intermediate to advanced): can frequently interact with clients and stakeholders.
"Language is no longer a barrier for me."
Same as L2 plus handles complex technical conversations with clients confidently.
Observable behaviors
  • 1Handles complex technical conversations with clients.
  • 2Writes design docs in clear English.
  • 3Participates in cross-team discussions effectively.
Expected outputs
  • Clear English design docs and technical briefings.
  • Confident client-facing technical conversations.
What you would see
In a heated technical discussion with the client Tech Lead, L3 holds ground and explains the trade-off without losing clarity.
Common traps
  • Plateaus at "good enough" without pushing toward C1.
L4
Tech Lead
CEFR C1 (proficient): can chair meetings, negotiate, present to clients and stakeholders.
"I chair the room. I negotiate. I present."
Chairs client meetings. Negotiates technical scope. Presents to senior client stakeholders. Coaches juniors on English communication.
Observable behaviors
  • 1Chairs client meetings end-to-end.
  • 2Negotiates technical scope and timeline with partner managers.
  • 3Presents to senior client stakeholders.
  • 4Coaches juniors on writing and speaking.
Expected outputs
  • Chaired meeting outcomes.
  • Negotiated agreements with partners.
  • Presentations to senior stakeholders.
What you would see
L4 runs a client steering committee for an hour, balancing technical and business topics, with the client signing off on the recommendations.
Common traps
  • Speaks confidently but writing still has rough edges.
L5
Solution Architect
CEFR C1+ (proficient to native-like): chairs strategic meetings, presents in presales, writes department-level documents.
"I represent the department in English. My language is part of our brand."
Department-level English. Presales presentations. Strategic writing. Sets language standards.
Observable behaviors
  • 1Presales presentations to prospects.
  • 2Strategic writing for department-level docs.
  • 3Sets English-writing standards for the department.
Expected outputs
  • Presales proposals and presentations.
  • Department-level documents.
What you would see
L5 presents the department capability to a Fortune-500 prospect in a 45-minute talk and Q\&A; prospect signs LOI within 2 weeks.
Common traps
  • Polished English but jargon-heavy; loses non-native audiences.
Measurement matrix 3-of-5 majority
Dimension
L1 · Aware
L2 · Familiar
L3 · Proficient
L4 · Advanced
L5 · Expert
CEFR band
CEFR B1 (intermediate).
CEFR B2 (upper intermediate).
CEFR B2 to C1 (upper int. to advanced).
CEFR C1 (proficient).
CEFR C1+ (proficient to native-like).
Reading & technical comprehension
Reads technical documentation in English.
Comfortable across technical threads and specs.
Handles complex technical conversations in writing.
Reads + synthesizes business and technical material together.
Reads strategic and commercial material across the department.
Writing
Basic emails, code comments, daily/weekly reports · occasional awkward phrasing.
Clear PR descriptions, design notes, emails.
Clear design docs and technical briefings.
Negotiated agreements · presentations to senior stakeholders.
Presales proposals · department-level documents · sets writing standards.
Spoken interaction
Attends internal meetings · may not handle direct client conversation.
Daily conversations with partner devs · explains bug fix in client standup.
Holds ground in heated technical discussion with client Tech Lead.
Chairs client meetings end-to-end · presents to senior stakeholders.
Presales presentations to Fortune-500 prospects · 45-min talks + Q&A.
Audience reach in English
Internal meetings only; client-facing supervised.
Partner devs and client standups daily.
Cross-team and client Tech Lead conversations.
Senior client stakeholders and partner managers.
Prospects, external events, other departments.
Anti-signal · auto-disqualifies the level
Rejects
Avoids English speaking entirely; misses learning opportunities.
Comfortable on technical topics, struggles when conversation goes personal or strategic.
Plateaus at 'good enough' without pushing toward C1.
Speaks confidently but writing still has rough edges.
Polished English but jargon-heavy; loses non-native audiences.
Scoring rule: You are at Level N if you hit Level N in at least 3 of 5 dimensions, AND no dimension is below Level (N−1). Sort dimension levels descending — the 3rd value is your overall level. If the lowest dimension drops more than 1 below that value, demote 1 level.
Mentoring & Technical Leadership
Weight ×1
L1
1
L2
2
L3 · hire bar
3
L4
4
L5
5
L1
Junior SE
Personal contributor only.
"I am still being mentored. I do not mentor."
Contributes own work. Does not yet mentor.
Observable behaviors
  • 1Receives mentoring from L3 or L4.
  • 2Asks questions, learns.
Expected outputs
  • Personal work output.
What you would see
In the team channel, L1 is mostly asking questions and being answered.
Common traps
  • Does not document learnings for future juniors.
L2
Middle SE
Personal contributor; occasional mentor.
"I help L1s when asked."
Mentors 1-2 L1s informally. Reviews their PRs. Answers questions.
Observable behaviors
  • 1Mentors 1-2 L1s informally (a few hours per week).
  • 2Reviews L1 PRs constructively.
  • 3Answers L1 questions in Slack or in person.
Expected outputs
  • L1 PR reviews.
  • Mentoring notes (informal).
What you would see
Friday afternoon, L2 spends 1 hour walking an L1 through a tricky debugging session.
Common traps
  • Mentors only on technical topics; ignores career or behavioral aspects.
L3
Senior SEHIRE BAR
Leads a team of 3-10 people technically.
"I am the technical anchor of the team. My job is to make the team succeed, not just me."
Mentors L1 and L2 actively. Sets the technical bar. Reviews everyone's PRs. Coaches on design and quality.
Observable behaviors
  • 1Actively mentors L1 and L2 (regular 1:1s, structured feedback).
  • 2Sets the technical bar — what 'good' looks like in this team.
  • 3Reviews everyone's PRs systematically.
  • 4Coaches on design, quality, and career.
  • 5Develops at least one engineer toward the next level.
Expected outputs
  • Mentoring notes per mentee.
  • Coaching feedback after key reviews.
  • Promotion recommendations to ODC Lead or Tech Lead.
What you would see
L3 has a weekly 30-min 1:1 with each L1/L2, focused on growth not just status. Junior engineers visibly improve quarter over quarter.
Common traps
  • Hero engineer — fixes everything personally instead of teaching.
L4
Tech Lead
Manages multiple teams or projects simultaneously.
"I evaluate and grow engineers. I make hire/replace decisions. I shape the team."
Manages 3-10 people across teams. Formal performance evaluation. Hiring and replacement decisions. Develops L3s into Tech Leads.
Observable behaviors
  • 1Formal performance evaluation for L1, L2, L3 reports.
  • 2Hiring decisions and replacement recommendations.
  • 3Develops L3s toward L4 (Tech Lead).
  • 4Builds team culture and norms.
  • 5Coaches across multiple teams.
Expected outputs
  • Performance evaluations.
  • Hiring recommendations.
  • Succession plans.
  • Team culture artifacts (rituals, norms).
What you would see
L4 has a clear bench of L3 engineers who could step into Tech Lead role within 12 months; one is already shadowing.
Common traps
  • Plays favorites; calibration becomes biased.
L5
Solution Architect
Department-level technical influence.
"I shape the technical capability of the entire department."
Influences department-level hiring, training, technology choices. Mentors L4 Tech Leads. Sets engineering culture.
Observable behaviors
  • 1Interviews senior candidates.
  • 2Mentors L4 Tech Leads.
  • 3Sets engineering culture and standards.
  • 4Influences department hiring profile and training.
Expected outputs
  • Senior interview evaluations.
  • Tech Lead mentoring notes.
  • Department engineering culture artifacts.
What you would see
Hosts a quarterly Tech Lead forum where L4s present hard problems and get peer review from each other and the SA.
Common traps
  • Loses touch with daily engineering reality.
Measurement matrix 3-of-5 majority
Dimension
L1 · Aware
L2 · Familiar
L3 · Proficient
L4 · Advanced
L5 · Expert
Mentoring scope
Receives mentoring from L3/L4 · does not mentor.
Mentors 1–2 L1s informally a few hours per week.
Actively mentors L1 and L2 with regular 1:1s and structured feedback.
Manages 3–10 across teams · develops L3s into Tech Leads.
Mentors L4 Tech Leads · hosts quarterly Tech Lead peer forum.
Setting the technical bar
None · learns the bar from others.
Reviews L1 PRs constructively.
Sets the technical bar — what 'good' looks like in this team.
Builds team culture and norms across multiple teams.
Sets engineering culture and standards for the department.
Coaching breadth
Asks questions, learns.
Answers L1 questions in Slack or in person.
Coaches on design, quality, AND career — develops one engineer toward next level.
Coaches across multiple teams on technical and behavioral aspects.
Influences department training and capability building.
Performance & hiring decisions
None.
None · informal mentoring notes.
Promotion recommendations to ODC Lead or Tech Lead.
Formal performance evaluations · hiring decisions · succession plans.
Interviews senior candidates · influences department hiring profile.
Culture & influence
Mostly asks questions in team channel.
Walks juniors through tricky sessions on a Friday.
Junior engineers visibly improve quarter over quarter.
Clear bench of L3s ready for Tech Lead within 12 months.
Shapes the technical capability of the entire department.
Anti-signal · auto-disqualifies the level
Rejects
Does not document learnings for future juniors.
Mentors only on technical topics; ignores career or behavioral aspects.
Hero engineer — fixes everything personally instead of teaching.
Plays favorites; calibration becomes biased.
Loses touch with daily engineering reality.
Scoring rule: You are at Level N if you hit Level N in at least 3 of 5 dimensions, AND no dimension is below Level (N−1). Sort dimension levels descending — the 3rd value is your overall level. If the lowest dimension drops more than 1 below that value, demote 1 level.
How to advance — promotion criteria
L1L2
Typical 12–18 months
What to demonstrate
  • L2 in all 8 competencies
  • L3 in Tech Mastery AND Code Quality
  • Ships features independently in primary stack
Portfolio (CORE)
  • 5 merged PRs with substantive scope
  • Stack declaration (primary + secondary)
  • 1 self-debugged production issue
Verification path
1Self-assess + Tech Lead review
2Submit portfolio
3Annual review sign-off
L2L3
Typical 18–24 months
What to demonstrate
  • L3 in all 8 competencies
  • L4 in Technical Mastery
  • L3+ in System Design AND demonstrated mentoring readiness
  • Owns a module in the codebase
Portfolio (CORE)
  • 1 ADR or design doc for non-trivial feature
  • 1 module ownership record (6+ months)
  • Postmortem from a P1 in their module
  • Mentoring evidence (onboarded junior OR PR review at scale)
Verification path
1Self-assess + Tech Lead calibration
2Submit portfolio
3Tech Lead + ODC Lead sign-off
L3L4
Choose Tech Lead or Principal Engineer track
What to demonstrate
  • Tech Lead: L4 all 8 + L5 Tech Mastery OR System Design + people leadership
  • Principal Eng: L5 Tech Mastery + L4+ System Design + technical leadership without people management
  • Track-specific evidence per sub-track
Portfolio (CORE)
  • System design adopted by team or project
  • Tech Lead: hiring panel participation + IDP for 1 report
  • Principal: technical RFC adopted by another team
Verification path
1Declare preferred track
2Multi-reviewer calibration
3ODC Lead + Head of D3 sign-off
L4L5
0–2 person seat at current org scale
What to demonstrate
  • L5 in System Design AND Tech Mastery
  • Cross-team or cross-ODC technical influence
  • Justified org need for an L5 seat
Portfolio (CORE)
  • System designed adopted across multiple projects
  • Reference architecture published
Verification path
1Department-level review
2Submit portfolio
3Head of D3 + Delivery Director sign-off
Alternative IC tracks at L4 / L5
L4 · Principal Engineer (IC)
Drives technical direction through code, architecture, and influence — not through team management.
When to consider
  • You're a brilliant IC who doesn't want to manage people
  • You'd rather influence through code reviews and design than 1-on-1s
  • You want to grow technical depth without hitting a management ceiling
Profile fit
Strong: Tech Mastery (L5), System Design (L4+), Problem Solving (L4+)
Relaxed: Mentoring (L3 OK), Communication (L3 OK for internal)
Comp parity
Same as Tech Lead
Reversible
Yes, 1×/18mo
L5 · Distinguished Engineer (IC)
Capped 0–2 person seat. Created only when justified by org need. Sets technical standards across multiple projects.
When to consider
  • You've grown into broader technical influence across the unit
  • You mentor Tech Leads on technical depth
  • You represent D3's engineering maturity to clients
Profile fit
Strong: Tech Mastery (L5), System Design (L5), Problem Solving (L5)
Comp parity
Same as Solution Architect
Seat count
0–2 only
How to move between tracks
1. Declare interest2. 1-on-1 with Tech Lead + ODC Lead3. 1-cycle trial4. Confirm next quarter
FAQ for SE role
FAQ items will be added as questions surface from the team.
Self-assessment
Self-assess your SE level
Score yourself on each dimension and get a live radar chart of your competency profile. Scores stay in your browser — never saved or shared.